They could add stacked diffs, large monorepo features (allow user to view a slice of a repo), better submodule support (why can’t I PR multiple repos at once?). A good desktop app that is faster than the slow web client.
Stacked diffs is a huge one, and also where improving git would also improve LLM workflows. The bottleneck after code generation is PR reviews, and stacked diffs help break down large PRs into more digest-able pieces.
If you help humans collaborate better, you help LLMs collaborate better.
Because i can produce 5 clean, properly sized commits in the time it takes to do one round of reviews, so they have to be stacked. It's important that the CI run independently on each commit, and each commit builds on the work of the previous one.
but it could still be better for the truly gargantuan of code bases. Might not be worth it? Idk. Maybe with llm generated code churn, suddenly it becomes worth it? haha.
My immediate thought was hmm, that's weird but pretty nice. The indentation problem indeed sucks and with a halfway decent syntax highlighter you can probably de-emphasize the `//` and make it less visually cluttered.
Everyone agrees that "syntax doesn't matter", but implicit in that is "syntax doesn't matter, so let's do what I prefer". So really, syntax does matter. Personally I prefer the Rust/Zig/Go syntax of vaguely C inspired with some nice fixes, as detailed in the post. Judging by the general success of that style, I do wonder if more functional languages should consider an alternative syntax in that style. The Haskell/OCaml concatenative currying style with whitespace is elegant, but sufficiently unfamiliar that I do think it hurts adoption.
After all, Rust's big success is hiding the spinach of functional programming in the brownie of a systems programming language. Why not imitate that?
That saying never made any sense to me either. After all syntax is your main interface to a language. Anything you do has to go through the syntax.
Some people say the syntax just kind of disappears for them after some time. That never seems to happen with me. When I am reading any code the syntax gets even more highlighted.
I always thought that languages (or at least editors) should allow the user to use whatever syntax they want!
It's possible. Just look at Kotlin and Java... you can write the exact same code in both, even if you discount the actual differences in the languages. It's not hard to see how you could use Haskell, or Python syntax, to write the exact same thing. People don't like the idea too much because they think that makes it sharing code and reading code together harder, but I don't buy that because at least I myself, read code by myself 99% of the time, and the few times I read code with someone else, I can imagine we can just agree quite easily on which syntax to use - or just agree to always use the "default" syntax to avoid disagreements.
I dream to one day get the time to write an editor plugin that lets you read and write in any syntax... then commit the code in the "standard" syntax. How hard would that be?!
People who do a lot of deep work on code, particularly debugging and rearchitecting, tend to have opinions about syntax and code style that are more exacting. As one of those people I’ve always felt that the people working the code the hardest deserve to have an outsized vote on how to organize the code.
Would that potentially reduce throughput a bit? Probably. But here’s the thing: most management notice how the bad situations go more than the happiest path. They will kick you when you’re down. So tuning the project a bit for the stressful days is like Safety. Sure it would be great to put a shelf here but that’s where the fire extinguishers need to go. And sure it would be great not interrupting the workday for fire safety drills, but you won’t be around to complain about it if we don’t have them. It’s one of those counterintuitive things, like mise en place is for a lot of people. Discipline is a bit more work now for less stress later.
You get more predictable throughput from a system by making the fastest things a little slower to make the slow things a lot faster. And management needs predictability.
If you like C-like syntax and want a functional language that uses it, try Gleam: https://gleam.run/
Quite lovely looking code.
fn spawn_greeter(i: Int) {
process.spawn(fn() {
let n = int.to_string(i)
io.println("Hello from " <> n)
})
}
There's also Reason, which is basically OCaml (also compiles to JS - funnily enough, Gleam does that too.. but the default is the Erlang VM) with C-like syntax: https://reasonml.github.io/
Check out this video: [1]. It's one of my favorite videos on YouTube. It covers instructional design from a YouTube perspective in a thorough, thoughtful manner.
The rationale is probably that it’s better for C++ devs to write non idiomatic Rust than to keep writing unsafe C++. Like unless they use unsafe and completely circumvent the borrow checker, it’s still gonna be safer. Not letting perfect be the enemy of good and all.
Plus idiomatic rust isn’t that strict a definition. Clippy will guide you for most of the simple stuff and the rest isn’t always worth following. Like people who try to do stuff “correctly” with traits often end up with way more complexity than it’s worth.
People underestimate how much of software engineering is subjective touchy feely decisions. But really it's just a nature of being in a field with so many possible options and so few hard constraints. You can write your web app/cli in Java, Go, Rust, JavaScript, Ruby, Python, etc, each of them with reasonable justifications. You can deploy to AWS, Vercel, GCP, Azure, Cloudflare, etc. You can use Postgres, Mongo, SQLite, MySQL, etc. Is there any actual evidence that one stack is better than another? No, not really. It's ultimately up to what your brain decides it likes, and then it fills in the arguments post-facto.
It's just that software engineers like to pretend they're fully rational beings and don't go off of subjective reasons like the rest of society.
>It's just that software engineers like to pretend they're fully rational beings
So much this. There are some rational factors to consider, but in the end gut feeling and UX is a much bigger factor than what people like to admit.
IME the people that espouse "facts over feelings" often have a lot of badly expressed feelings disguised as rational opinion. I prefer discussing with people that are at least aware of their own feelings and can admit that.
> Is there any actual evidence that one stack is better than another? No, not really.
It is not controversial to say that any two stacks will have advantages and disadvantages over each other. There is absolutely evidence that Go compiles code faster than C++, or that C++ can call C code with less overhead, or that Rust eliminates certain classes of bugs, or that Postgres supports LISTEN/NOTIFY and SQLite doesn't, or that SQLite excels at storing a database in a single file.
Choosing a given stack means picking which particular advantages you want and/or need. I agree that there's no evidence that one stack is always "better", but this is like asking for evidence that a hacksaw is better than a table saw: they don't do the same thing! You can probably use either of them to cut through a skinny tree branch, though.
I think there are definitely objective reasons why you would pick certain stacks for specific projects. They all have strengths and weaknesses. You can technically achieve a lot of the same tasks regardless of your stack choice, but the timeframe, elegance, available ecosystem, cost, and ability to hire for your stack may vary quite a bit.
That said, if I’m not spending someone else’s money, I’ll pick the stack I enjoy or feel most productive in. I use Elixir for my own projects, but it’s generally a bad option for the startups I work for. Tough to hire for, limited ecosystem, unusual and sometimes polarizing concepts. It’s a business risk compared to, say, TypeScript or Go. Great concurrency model and cool pipeline capabilities though. :)
there are objective strengths and weaknesses. However for any set there is another option that has very similar pros and cons with just one - often minor point different.
I feel like Elixir has such a small amount of jobs that it would be a lightning rod for those who have skills in it. I appreciate Elixir, I like it. But it's weird to see an expectation of experience in it when the marketplace is so small.
You could always target scala/akka engineers with it. Theres a lot of crossover there.
there are definite differences but in most cases we do not have the ability to make an actual rational choice (verging between a lack of hard numbers and an inability to predict the future).
Software development is not engineering, but it's also not completely arbitrary. It's a craft, and like all other craftspeople, you build intuition through experience, which guides decision-making.
It's a little controversial to say that it isn't engineering, but compare what we do to things like building bridges or constructing dams. The level of rigor in those fields is galaxies apart from almost all of software development. You _could_ apply it, and some organizations do, especially when lives are on the line, but the cost/benefit ratio is impossible to justify in almost all software development.
This isn't to say that "real" engineers don't also build intuition, but they have enormously higher accountability requirements. In some areas I would argue that software development _should_ have much higher accountability, but this also means a significantly higher cost. I think governments around the world are coming to realize that the money would be well spent.
I think software engineers would benefit from talking a bit more with actual engineer peers at real companies and hear them vent and rant, to see that "real engineering" isn't the idealized utopia we imagine it to be either.
I've worked in backend infrastructure teams for ~6 years in a couple PHP shops, and you know what, dynamic languages absolutely suck when you want to do any kind of refactoring :). That made me really appreciate compiled languages like Go, since they don't feel too heavy and have a feeling close to a dynamic language, but do allow for painless refactoring.
Modern PHP shops don't really do dynamic PHP anymore. Ever since it got types and runtime type validation. Refactoring is also proven to be very easy as a result, and especially with something like Rector (https://github.com/rectorphp/rector).
Yes, you also know this in modern PHP. https://www.php.net/manual/en/language.types.declarations.ph.... You add type declarations just like any other statically typed language, and you can get your static analysis by your editor out of the box. But in addition to that, you ALSO get runtime type validation, something that most languages won't give you, and something that to me at least is amazing since code correctness is one thing, but data correctness is even more important in my opinion, and runtime type validation gives you data correctness, built in, no need to mess around with external libraries.
I wouldn't want to refactor anything other than Ruby. If you have the intuitive understanding about how its object model and scoping semantics works, refactoring is really fun.
The issue with dynamic languages mostly is that it's sometimes next to impossible to find all references to the code you're refactoring, so you can't just rely on a compiler & tests to ensure that nothing breaks after a change in some core library that everyone uses. Instead you almost have to add some logging into a function you're refactoring, make sure it's not used after you've made the change to a new API, and ideally do that a couple times. It's not too bad when you're the sole developer in a repository, but in the presence of hundreds of feature branches that sometimes can be weeks old, you can't be sure that nothing breaks after your change in the future too. So unless your code can be statically analysed reliably (like in compiled languages) large scale refactoring is a huge pain
> You can deploy to AWS, Vercel, GCP, Azure, Cloudflare, etc.
It's interesting that this is now and has been the default for quite sometime. I'm still waiting for the pinch to hit where people realize running on these platforms is either really expensive (EC2/RDS), or platform specific ("serverless", Cloudflare workers, lambda, etc).
TBF it's only expensive if you know how much the alternative costs, and have a reasonable path to switch to it. So for most small shops, it's just a cost of doing business, and they're small enough it doesn't cost astronomical sums yet.
Running an on-premise cluster requires enough expertise that it will mostly be for mature companies, and they'll have completely different priorities when choosing technologies.
Ultimately code is written for humans first, otherwise we’d all be using assembler. So how readable the code is written matters, and how frictionless it can be managed. A lot of opinions form around that. As Usually “it depends”.
Note I’m not disagreeing with the core of the comment but presenting this as pretence when this is simply the craft until we manage a layer that manages code for us and have opinions on that instead, seems harsh. My 2c anyway.
There are happy paths to follow for many projects. For instance if I was starting a macOS or iOS project I'd need a really good reason not to use Swift.
I'd disagree about syntax. It really does matter. So much of Rust's success is tricking people into writing a functional style while having it look like an imperative language. OCaml syntax isn't bad per se but it's unfamiliar and that's enough to discourage users.
I think you're right, and I hate it. Just look at Gleam as an example where adopting a more C like syntax got them a ton more adoption almost over night.
I love Ocaml (and Haskell-esque) syntax, but I must admit it can be detrimental to getting adopted.
I think another issue was bad tooling for a long time. Now with Dune it's great though, with very fast compile speeds.
Hopefully OCaml slowly gets the recognition it deserves, because it really is a great language.
Rust refs are not OCaml refs though. Rust just places more guardrails around update-in-place model, instead of using controlled references to immutable data like OCaml (and Clojure).
12 years is an eternity in China. I went in 2008-2010 and it was completely unrecognizable compared to 2018. I imagine 2025 is completely different too
If performance is not ultra critical, I'd use Go. It's simple and a small-ish language. Otherwise there's not many options. Not to belittle your question, because it's a good one, but it's a little like asking if there's a simpler aircraft. There can be, but there's a certain amount of required machinery to keep it in the air. Rust's memory safety rules are as simple as we can get it for now. Maybe in a few years it'll be different!
With most tech career advice on the internet, I would check to see if it was written before 2022. If so, I'd take it with a grain of salt. I wrote tech advice in the ZIRP times. It was a very different market. Negotiation is still a valid tactic but there's a lot more to lose and a lot fewer offers than in 2021.
Depends on your position. I was employed but the company was going down the tubes when I got my last job through a connection. I didn't really negotiate and the one thing I would have liked to have negotiated (paid time off) was made clear was not on the table even before I said anything. And the offer was not FAANG levels but was incredibly good relative to what I was making.
reply