Why engineers can't be rational about programming languages • Hacker News Board

Re: Why engineers can't be rational about programming languages

#201

Post by pdimitar » Thu, Nov 06, 2025, 4:16 PM UTC

hshdhdhehd wrote: post #47

bri3d wrote: post #20

I think the author almost contradicts themselves; they reach the salient-but-obvious conclusion that rewriting a product is almost always a bad idea and that rewriting a product only to change programming language is _always_ a bad idea, that tribalism is a poor decisionmaking framework, and that leadership by arbitrary decree is stupid. Great! These are age-old lessons that people somehow seem to forget, so seeing t…

Language choices does make a decent difference to time spent, bugs, extensibility. Id guess a 20-100% tax for choosing the wrong language. However most of the time the best language is the one the team knows well. Caveat to that is if the threading model or performance doesnt suit. Or company platform engineering reasons (e.g. availability of platform libraries).

> Caveat to that is if the threading model or performance doesnt suit.

So, this goes for ~70% of all projects ever and ~95% PLs ever?

I would have been a staff Golang engineer, if not a VP of Eng even, somewhere at this point if I didn't fall in love with Erlang's concurrency & parallelism implementation.

I am kind of still offended by the entire IT area that we have multicore CPUs for what, 20 years now, and we still don't make true physical parallelism a first-class citizen in all of our mainstream PLs. Looking at you, Python, and looking at you, Golang, with your ability to crash the program for sending to a closed channel, and looking at you Rust for making async needlessly complex.

(RE: Python, yeah yeah, "GIL is going away next release" and stuff. With that tempo they'll catch up with Golang by 2050.)

Re: Why engineers can't be rational about programming languages

#202

Post by pdimitar » Thu, Nov 06, 2025, 4:21 PM UTC

roguecoder wrote: post #176

hshdhdhehd wrote: post #47

Earlier quoted context omitted.

Language choices does make a decent difference to time spent, bugs, extensibility. Id guess a 20-100% tax for choosing the wrong language. However most of the time the best language is the one the team knows well. Caveat to that is if the threading model or performance doesnt suit. Or company platform engineering reasons (e.g. availability of platform libraries).

Frameworks are a major contributor to these dynamics, which is a little unfair to blame on the language, but I've seen orders of magnitude difference. I had one time it was faster for the three of us to rewrite a web app in Rails than to make the Play framework accomplish what we wanted it to accomplish, even though none of the three of us had ever worked in Ruby before. Rewriting four months of work took two weeks b…

You are correct but nothing can be done about it IMO. PLs live and die by their "killer apps" and that is most of the time the framework du jour.

There are refreshing exceptions here and there but there's also something to be said about whether it's a good thing that frameworks don't dominate a certain PL (like Golang; everything is very readable if verbose but one does get tired of generating the same boilerplate all the time).

Re: Why engineers can't be rational about programming languages

#203

Post by pdimitar » Thu, Nov 06, 2025, 4:22 PM UTC

tbrownaw wrote: post #100

bri3d wrote: post #20

I think the author almost contradicts themselves; they reach the salient-but-obvious conclusion that rewriting a product is almost always a bad idea and that rewriting a product only to change programming language is _always_ a bad idea, that tribalism is a poor decisionmaking framework, and that leadership by arbitrary decree is stupid. Great! These are age-old lessons that people somehow seem to forget, so seeing t…

> and that leadership by arbitrary decree is stupid. Great! These are age-old lessons To some extent! There are also cases where any decision is better than no decision, and all the options are good enough that it's not worth the delay to argue about them.

> any decision is better than no decision

Where does that fit, in a company where there's only one techie? Not sure I get your comment here.

Also "good enough" is a very, very tempting and treacherous mistress...

Re: Why engineers can't be rational about programming languages

#204

Post by pdimitar » Thu, Nov 06, 2025, 4:29 PM UTC

balder1991 wrote: post #181

thomasmg wrote: post #46

Earlier quoted context omitted.

> the language most of the team know the best I fully agree. The challenge is, some will want to use the latest languages and technologies because they want to learn it (personal development, meaning: the next job). Sometimes the "new thing" can be limited to (non-critical) testing and utilities. But having many languages and technologies just increases the friction, complicates things, and prevents refactoring. Even…

> This is a bit related to external dependencies vs build yourself (AKA reinvent the wheel). Quite often the external library, long term, causes more issues than building it yourself (assuming you _can_ build a competent implementation). I feel like this happens mostly because simpler is better, and most of these dependencies don’t follow a good “UNIX” philosophy of modularity, being generic etc. something that you’d…

Yep, true in my experience as well. And in the age of LLMs it is not so difficult to ask it to extract just this or that piece of functionality into another package but with a different API. So these days it's even easier to roll your own stuff. It's not such a huge time sink as it sometimes was before.

Re: Why engineers can't be rational about programming languages

#205

Post by pdimitar » Thu, Nov 06, 2025, 4:31 PM UTC

fabian2k wrote: post #56

hunterpayne wrote: post #38

Earlier quoted context omitted.

> More often than not, preference should be given to the language most of the team know the best. I'm sorry but I disagree. Languages are tools, pick the best tool for the job. The idea that languages are all good at everything is not true. And when I see takes like this, I tend to think that that person just doesn't understand how to assess a language's strengths and weaknesses. Want to write ML, probably best to us…

I think for many cases it is fair to make the assumption that you're staying roughly within the same kind of application. So if your team previously did web applications you won't suddenly do embedded stuff or high-frequency trading. And within such an area, there aren't enough differences between languages to overcome the drawback of learning a new one.

There is plenty of difference in Web backends. F.ex. Elixir, Golang, Rust make parallelism much easier and they scale better on a single host (which is what at least 95% of all startups ever will need).

Re: Why engineers can't be rational about programming languages

#206

Post by tpoacher » Fri, Nov 07, 2025, 9:39 AM UTC

lproven wrote: post #194

tpoacher wrote: post #187

Earlier quoted context omitted.

It's Bulverism because first you need to defend and establish that your proposition is true before you can start explaining "why" it is true. At the very least the title is clear Bulverism. Admittedly, I did enjoy the article, even if I was initially a bit predisposed not to from the title. And I think the quote "if you hire a rust evangelist to choose your programming language, you've already chosen rust" is very in…

He established his proposition in the opening paragraphs -- the ones that most HN commentators have seized up and not even noticed the actual argument and discussion. AFAICS you don't seem to have even noticed the initial example.

I hope the irony that your argument is now the Bulverist one is not lost on you :D