I have first hand experience of painfully slow C# compile times. Sprinkle in a few extra slow things like EDMX generated files (not C# but part of the MS ecosystem) and it has no business being in a list of fast compiling languages.
> ...I keep trying because I'm hoping theres patterns I don't see.
Python's popularity is an accident of timing. If you're digging deep for wisdom and gold nuggets you're not going to find any. The gold of python is the surface level stuff. Easy to type for hunt-n-pec typers. Press tab to indent is easier than {}.
That's all it took for an army of noobs who wanted to be "hackers" to choose Python. Then they grew up, got real jobs and brought Python with them.
It's not literally the age that's the issue, it's just a correlation. Some employers want people they can squeeze more easily and get the most juice out of.
Younger people are more likely to accept orders without push back. Accept lower pay. Work 60+ hr/week for crunch time, etc.
Depends on the employer of course. Google employs an 80+ year old Ken Thompson.
Same but from a C vs Go perspective. Didn't like GC or bundling dependencies into the final binary. But at the end of the day it's still small compared to most other languages deployment artifacts. Despite being a GC language, GO still puts you in the driver seat for how memory is allocated (ie avoid GC in the first place). And goroutines are really nice to use, without introducing colored functions like most other languages do. To top it all off Go keeps the C tradition that error handling should be a first class part of the algorithm, not something hidden off to the side.
So I'm reaching for Go for pretty much everything now days.
I was coming here to say: "grep as IDE". It's dynamic language tooling 101.
Find defs and refs. Master a little bit of regex and you will reduce false positives.
Grep serves as a rudimentary autocomplete. find the definition, open in a buffer, observe fields. This is analogous to an autocomplete popup displayed inline. The buffer can now power your contextual completions, similar to an inline popup.
Web based UI's (javascript baked in) are the only cross platform GUI all the major tech players endorse. Companies like Apple are hostile to alternative GUI frameworks, except web browser. Flash? that threatens the walled gardens so the big tech cartel came together to squash it out. Java graphics? we will not ship a JVM becuase "security". The web was already ubiquitous so the big tech couldn't squash it without squashing their own foot.
Typescript let's you start with a cross platform GUI right out of the gate. Text based HTML GUI is screen reader friendly, battle hardened for many years to get accessibility right.
Type system is advanced and allows for that sweet IDE experience.
And.... the Javascript ecosystem is the only game in town that gets close to the Lisp immediate feedback experience. (no Javascript is not as good as a lisp image, but it's better than nothing). Change a function, see the result instantly in the browser while you're app is still running. I'm not 100% sure this is true for Typescript as it must compile to javascript first, but compiling the TypeScript for 1 modified file with an on-save-hook could still be a pretty quick feedback loop.
Do these reasons have anything to do with AI agents? no but it would explain why people are already using Typescirpt, and thus use it for AI agents.
That's sort of the problem with C#. It couples the type (struct vs class) with allocation. C# started life by copying 1990's Java "everything-is-a-reference". So it's in a weird place where things were bolted on later to give more control but still needs to support the all-objects-are-refs style. C# is just not ergonomic if you need to care about data layout in memory.
Go uses a C-like model. Everything is a value type. Real pointers are in the language. Now you can write a function that inputs pointers and does not care whether they point to stack, heap, or static area. That function can be used for all 3 types, no fuss.
True, but running errcheck will catch cases where you accidentally ignore the error. Maybe not as good as having it built-in to the language like Rust, but the goal of error check safety is achieved either way.
And there's a few cases like Print() where errors are so commonly ignored you don't even want to use the "_" ignore syntax. Go gives you the poetic license to avoid spamming underscores everywhere. error linters can be configured to handle a variety of strictness. For non-critical software, it's OK to YOLO your Print(). For human-death-on-failure software you may enforce 100% handling, not even allowing explicit ignore "_" (ie become even stricter than Rust language default)
Yes I think there is a bubble. I think AI may become extremely impressive but still be limited.
A lot of tasks involve having context to produce a correct solution. AI can whip up algorithms in a vacuum. But doesn't know about the custom data format you have to import. It doesn't understand how to map that to the target schema and will blindly import in a way that is subtly wrong. It doesn't have the context provided by chit/chat and vague statements made in an email.
No matter how impressive AI works in a vacuum, the "context" heavy problems are going to be an issue. Someone mentioned "last mile", that's where things fall apart. Same with self driving, it is impressive at first, until a road is blocked and there's some poorly marked detour signs routing you through non-standard paths.
Same with a plumber. You might make a robot that can fix many plumbing problems. But there's always custom nooks and crannies you have to contort yourself into and saw off a pipe in a very specific way that only having a tons of context would let you even know where to begin.
So until AI can consume context the way humans can, it's going to be limited to a "auto completion on steroids". Which is valuable, but not the end of human developers. Only time will tell.
That's a pretty good take. Would make sense for a whole range of apps focused on 1 user or client. Accounting software is personal, company A doesn't need to query/join with data of company B.
line 1: short description. fit on 1 line. put effort into making it as short as possible while still giving the gist of what was done. maybe a github/lab issue #.
line 2: blank
line 3+: long description, paragraphs, details, context for decisions made, rambling
> we get customer data exports from legacy systems as CSV or XLSX
Convert the xlsx to csv. Every database system out there has blazing fast import of csv files.
As a sql wizard, I prefer to use sql to clean and re-shape data. So my first goal is to get the data into a sql DB as quickly as possible, no cleaning, no re-shaping. Just a raw dump. Now the data is in my house. I clean and re-shape the data with batch update/insert statements. Finally I batch insert to the target tables.
> what’s the most frustrating
Every import job is a custom scenario. I feel special tools don't give you much. You have to understand both the source and destination data to clean and re-shape it. Tools don't have that understanding. AI is less than worthless. At the end of the day you have to roll up your sleeves and start shaping data.
> I find it hard to judge when things are in a good enough state to commit
Work in a feature branch. Commit often. Squash away the junk commits at the end.
> ...and especially good enough to have a title.
Who needs a title? It's perfectly fine to rapid-fire commits with no comment, to create quick save points as you work. Bind to a key in your editor.
I treat commits in a private branch the same as the undo log of the text editor. No one cares about the undo log of your editor as they never see it. The same should be true of your private feature branch commits. They are squashed away never to be seen by human eyes again.
iterm2 has some options to fix key bind issues that hamper emacs in the terminal.