81–90 of 206 posts
> A programming language is the single most expensive choice a company makes By far no. Now I don't know if I even should read beyond that.
Worse, this also falls into the trap of thinking you have to make a choice, and that an informed choice is better than chance. Reality is that you are often best trying to do both, and then having some sort of coin flip to disambiguate choices works far better than we'd like to admit. In large part for the simple reason that simply doing something is more than a lot of your competitors will be doing.
> A programming language is the single most expensive choice a company makes By far no. Now I don't know if I even should read beyond that.
Same thing with the fundamental architecture of programs, and especially the data model & database solution.
Still I don't entirely agree with the article. He makes it sound like there isn't any difference between programming languages and any preference is purely about developer identity. But that identity doesn't come from nowhere. Rust is popular because a load of C++ developers finally found something technically better. Not because they all woke up one morning and decided to be "a Rust developer".
Where the story falls apart is that Perl is arguably even worse than PHP. One deluded Perl programmer does not prove a principle.
On Rust vs Go, he's absolutely right that Go is has a slightly better "build & deploy" story (though not by a much). But reading between the lines I think he's misrepresenting that - it sounds like a) that was just one point for choosing Rust, and b) that was a point when comparing to typical alternatives, e.g. C++ or Java. It's not untrue that Rust is easy to build & deploy simply because Go is slightly easier.
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…
In my experience, a language switch rewrite can be a benefit only when switching from a dead ecosystem to a living one. For example, migrating a web app from a language that predates Unicode to something that won't require a bunch of scaffolding around every user input sometimes is worth it. Moving from LABVIEW to a real programming language that integrated with remotely modern development tooling was worth it. Switc…
Counter example:
Earlier quoted context omitted.
In my experience, a language switch rewrite can be a benefit only when switching from a dead ecosystem to a living one. For example, migrating a web app from a language that predates Unicode to something that won't require a bunch of scaffolding around every user input sometimes is worth it. Moving from LABVIEW to a real programming language that integrated with remotely modern development tooling was worth it. Switc…
> Switching from C++ to Rust? Probably not. Counter example: https://fishshell.com/blog/rustport/
Earlier quoted context omitted.
This is a good take. In the consulting context, I've quickly realized that most problems at a business can be broken down into "this will destroy the project on its own" and "this is an annoyance to a good engineer". Language choice is basically always in the latter category, whereas poor management or one egotist is frequently in the former. Like, my team doesn't know anything about Java, but we COULD ship in Java i…
My team ships with a multi-hour CI pipeline that works 50% of the time and effectively zero local development. It's awful in almost every way developer experience-wise, but rock bottom is deeper than you think!
Earlier quoted context omitted.
> the example I really wanted to use was people picking Go for their top-end, competitive-with-anything-in-the-market database. You mean they're writing their own database? Why? That's a huge job and available databases are pretty good. There are multiple open-source choices, all of which work. If they think they're going to compete with Oracle, they need to read the history of Oracle.
There are at least a dozen new databases in the market making decent money that were started this decade. They're just not competing with Oracle.
Earlier quoted context omitted.
great team can write amazon clone in fortran. bad team cannot write todo list clone in… well anything :) it is (almost) always people and (almost) never language/framework/…
The great team would not have written the Amazon clone in Fortran. There is no engineering justification for such a choice, and "we are swaggeringly awesome engineers who can conquer anything" is not even remotely an engineering justification.
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…
"I cannot agree that programming language choice is a primary driver in a product's success or failure" I've seen it. There are definitely incorrect language choices for certain projects. It would be fair to say that these cases are themselves often exceptions. Many projects can be equally well accomplished by teams skilled in any language. But there is definitely a set of problems for which you can make incorrect la…
That being said, some programs can only be written in one of those. Browser code is JS exclusive, low-level needs C++, secure code needs not C++. Machine Learning needs Python and high performance can't use Python. Some Windows things need C#. Those cases are the obvious ones where there is basically no choice. Beyond those, it is mostly about the team.
False. Next.