[Zigurd]

If you look at the volume of software that needs to be produced, and at the trend to include software in more products, and at the entrepreneurial imperative that risk capital is the most expensive resource, it looks very unlikely that handcrafted machine instructions will play a greater role in the future.

Cloud computing and SaaS have extended the deadline for coming up with an answer to "What comes after Moore's Law." But it is much more likely to not be based on every coder learning what us olds learned 40 years ago. Instead, optimization is more likely to get automated. Even what we call "architecture" will become automated. People don't scale well, and the problem is larger than un-automated people can solve.

[thedevelopnik]

I don’t think that handcrafted machine instructions are what is necessary. Even switching from languages like Ruby or JS (Node) to languages like Go or Elixir yields tremendous efficiency improvements.

Beyond that, developers being conscientious of what they send over the wire, and being just a bit critical of what the framework or ORM produces also can yield substantial gains.

I say this as a “DevOps” guy who is responsible for budget at a mid-size startup, where we’re hitting scale where this becomes important. We save about 8 production cores per service that we convert from Rails to Go. Devs lose some convenience, yes, but they’re still happy with the language, and they’re far from writing hyper-optimized, close to the metal code.

[pdimitar]

You mentioned it yourself early in your comment but IMO going from Rails to Go is a bit weird. Rails to Phoenix (Elixir) is much easier and productive for many devs, it turned out.

Elixir itself is almost completely staying-out-of-your-way language as well -- meaning that if your request takes 10ms to do everything it needs then it's almost guaranteed that 9.95ms of those 10 are spent in the DB and receiving the request and sending the response; Elixir almost doesn't take CPU resources.

I worked with a lot of languages, Go/JS/Ruby/PHP/Elixir included. Elixir so far has hit the best balance between programmer productivity and DevOps happiness. (Although I can't deny that the single binary outputs of Go and Rust are definitely the ideal pieces to maintain from a sysadmin's perspective.)

[Zigurd]

I was going to say that the more performant language thing was likely to disappoint. As you point out, database access is going to be roughly constant. But Rails -> Go would be an exception.

[pdimitar]

Well, yeah. Still, Rails is much slower than Phoenix by the mere fact that its templating and ORM facilities are extremely inefficient.

It's not that Ruby is 100x slower than Elixir (of course it's not). It's just that Rails is so inefficient compared to Phoenix.

Sinatra, Phoenix, Rocket.RS, and a ton of others are specially crafted to stay out of your way and utilise the CPU as less as possible. And yep, as we both agree, in these cases the 3rd party I/O is the bottleneck.

[thedevelopnik]

Although I guess we could consider more performant, but still easy to use, languages to be a form of automation.

[pdimitar]

Rust, [partially] OCaml and [partially] Elixir come to mind. Elixir is much slower than those two but for the value it brings to the table, is quite fast.

Out of everything I worked with in the last 15 years I'd heartily recommend Rust for uber-performant-yet-mostly-easy-to-use language.