Language comparison

Came across this pros/cons table recently (some un-named company, when deciding on micro-service language-of-choice):

Mostly agree, except that

  • We do have generics in Go (as of 1.18) and “… unfamiliar with the language” is true for any language
  • The Python cons will remain as they are (though they should matter much less when not doing cpu-intensive tasks)
  • The Rust cons will reduce as (1) it becomes less ‘new‘, and (2) the ecosystem becomes more ‘strong‘, and (3) async/await has been standardized now, but yes, the memory model will always take time to learn.

Given this, and admitting a lack of Kotlin knowledge, IMO Go seems like a safe default choice (or Rust/Python where appropriate).

Flexibility vs consistency

The “tragic tradeoff” in programming languages:

I still remember a wonderful presentation by Damian Conway a number of years ago about all of the great ways Perl 6 could turn into whatever domain specific language you needed it to be. It was beautiful, I was awestruck. I’ve always enjoyed Perl as a language. But I walked out of that presentation thinking “That was so beautiful, and I don’t want it anywhere near my business.” Because the last thing I need is software written in a language I can’t hire anyone else to maintain.

At some level that’s what I think has happened to Perl in general. I never liked Python much, until I got forced to use it on a new team. Now I’m convinced that it has a really distinct advantage — there aren’t too many ways to write Python, so an experienced Python developer can figure out code pretty quickly. But Perl programs are frequently art pieces that take a lot of effort to truly grok.

From HN, “What happened to Perl 7

“Jets” are the proverbial “Sufficiently Smart Compiler.” The seal between a core of Maxwellian purity and the world of filthy expedient compromises which lies outside must be absolutely perfect – like the seal on the airlock of a multi-generational starship. In fact, building the airlock at all is a terrible idea. Anyone who whines about being welded into the hull doesn’t belong on the journey.

Think of every high level language with a C FFI you’ve used. Having the FFI is not harmless. It colors the programmer’s thoughts. It destroys the Master-Of-All-I-Survey majesty of the entire system. Another way must be found.

Only in the mid-nineties when the number of transistors on a single chip ceased to be the true bottleneck, the “von Neumann bottleneck” may have ceased to be the optimal solution. For the first time after fifty years of progress at break-neck speed, there was a glut of switching elements. This may have made it practical to consider architectures customized to high level languages. But it would only be competitive at the expense of investments that only those firms can afford that are committed to the von Neumann bottleneck. So now, instead of a single such bottleneck, my next computer, with it quadcore chip, will have four of them. And I will be able to have my OCaml programs run wondrously fast. Will all those millions transistors be used efficiently? Of course not: the famed “Road Ahead” is paved with waste.