Hacker News Reader

> I've seen it. There are definitely incorrect language choices for certain projects.

I guess we can all agree that writing your web application using a fortran framework to generate JS code is a bad idea.

But if you pick tfa's second example, picking Go vs. Rust for a new project, the language choice is secondary. Both languages were likely fine unless the project as a specific library requirement.

The main criteria to make the choice was likely whether the team had developers with some experience in that language, and whether using that language would make them feel dead inside in the morning when they check in ; and I'm pretty sure developers can be found that make either choice a great choice.

The point tfa's making, that picking a language defines culture, the hiring pipeline etc. is fitting neither the first example (team already there, and a rewrite is almost always a bad choice) nor the second example (team also already there, and the culture with them. Pipeline therefore irrelevant).

In my first post, the example I really wanted to use was people picking Go for their top-end, competitive-with-anything-in-the-market database. I choose Python just because anyone who would argue that is a good choice is clearly not someone who is in a position to see reason. But I think Go is a serious mistake... it's just one that lets you get to market, unlike Python which never would. But it's still going to end up holding back the company that makes that decision in the end.

> 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 many workloads for which all available database engines are poor. If you have one of those workloads and the esoteric technical expertise, it is entirely plausible to improve performance, scale, etc metrics by 10-100x versus whatever is currently available in the market. 10-100x is qualitative if that is central to your business.

Of course, almost no one should attempt this. The number of people with the technical expertise to pull it off successfully is much, much smaller than the number of companies with workloads that would benefit from this.

It doesn't have to be an exotic workload. Sometimes the market is just full of weak implementations e.g. graph databases.

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.

A large part of success is picking a goal that is obtainable.

While I’ve seen bad technology chosen for projects, it seemed at root more a problem with the people choosing it than the technology itself.

Absolutely agree. People made the bad decisions. But the bad choices existed. People who don't understand the bad choices are bad choices, or worse, think that there is no possible way there is a bad choice, are far more likely to end up being those people who made bad decisions then people who understand that the decisions mattered.

Don't go running around telling people that they can dig the Panama Canal with three toothpicks and a spare weekend, and if they fail, well by golly they just didn't have enough grit and gumption like us awesome folks who could have done it with only two. Tool choice matters. In fact I can hardly process how anyone can be an engineer and think that it doesn't, let alone how they can think it's some sort of engineering wisdom to claim that it doesn't matter what tools you use to do a project.

Of course, picking the tool is only the moment the project may fail. It is not the moment the project succeeds; there's still a lot of using it correctly that will be necessary and plenty of further opportunities to fail even with the correct tool. But at least success is within the range of possibilities. You can forstall that possibility entirely on day one with incorrect tool choices.

Sure, people with ZERO enterprise experience might say - hey, let's write our <main software> in PHP - I had a lot of fun 15 years ago with that, and I'm sure we can make it work.. That's the "3 toothpicks" in your example.

But is anyone REASONABLY competent going to do that? They might pick C/C++, Go, Rust, Java, etc. Those aren't a choice between "bulldozers and toothpicks" - they are more akin to choosing between Caterpillar, Volvo or Hitachi as the vendor of choice for construction equipment. They may have some gaps in their specific list of equipment, they may charge too much for one specific tool, your workers may have experience with one, not the other, etc..

Your example should be the textbook definition of a strawman argument..

> Tool choice matters. In fact I can hardly process how anyone can be an engineer and think that it doesn't, let alone how they can think it's some sort of engineering wisdom to claim that it doesn't matter what tools you use to do a project

Just to be clear, I wasn't trying to claim this; tooling certainly matters, at the very least, for the happiness and welfare of an engineering team! But, the article tries to claim things like "choosing a programming language is the single most expensive economic decision your company will make" and outside of a few extreme edge cases, I just can't agree with that particular thesis. Even the examples of bad decision-making you pose in your sibling comments, like writing a database in Go or "almost failing" by using sketchy niche datastores, are actually examples of this exact thing: these projects made huge engineering mistakes only to achieve some level of success as a business. Would they have been more successful if they made better engineering decisions? Possibly, but again, language and framework just was not the most important decision or factor driving an outcome.

I'm not saying that means we shouldn't care about making good engineering choices; there are easy ways to do things and hard ways to do things, and certainly I'm going to advocate for and work with people and at companies that favor the easy ways to do things. But when it comes to overall outcomes, I'll stand by having seen far more projects sacrificed to analysis paralysis, rewrites, rewrite-related hand wringing, and language/tooling hubris than sabotaged by poor language and framework choices.

> a problem with the people choosing it than the technology itself.

Which is, I think, the key point of the OP's article.

And my response to this is:

We need objective, scientific, real-world measurements of PL efficiency, so that informed judgements can be made free of cognitive bias.

This is how science works. Especially medicine. But programmers seem to feel that they are above this stuff.

> But programmers seem to feel that they are above this stuff.

No, programmers are quite below this stuff. Budgets for medical research, treatments, trials are way more than IT budgets. And for typical IT project the underlying point is even if requirements were wrong, changed halfway , software is malleable enough, to be changed, refactored. And all while it can remain in use even during change cycle.

I would say, though, that for most programs any one of the most popular languages would do the trick. By this I mean Java, Go, C#. Javascript, Python, C++. All of those are general purpose multi-paradigm languages that you can code almost anything in.

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.

> I would say, though, that for most programs any one of the most popular languages would do the trick

Which of course ignores and contradicts the primary lesson of the chap who founded this company and pays for this website.

https://paulgraham.com/avg.html

I’m having a hard time envisioning a project that could be killed by choosing Scala that wasn’t actually killed by bad engineering. Scala is pretty easy to write Just Simpler Java in….

I would say that Scala is more complicated than Java because it introduces a number of useful new features to a JVM language.

Perhaps it's running on a semi-embedded system...

The fact that it's simpler Java makes it a good candidate for failure: it tries to remove from the code enough to make it hard to maintain.

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.

The parent article's point, though, is that choice of programming language is often NOT driven by justified choices, but is a foregone conclusion because it is part of the identity ("I am/want to be a XY developer.") of someone influential (e.g. tech lead, CTO, VP Eng).

One argument I would like to add to this original debate is that I have observed two types of developers: one type tries to stick to one programming language for everything (e.g. Java) and tries to write everythin in that language. They are specialist and they may accrue deep knowledge of the language versions, APIs and IDE(s). Another type of developer, in contrast, maintains active knowledge of a dozen programming languages (C/C++, Java/Kotlin, Python, bash, Rust, Go, PHP, JavaScript, ...), and is capable of delivering projects in each. They'd pick a language suitable for the task and stick with it for a project. They won't know any single language as intimately as the first type, but they benefit by virtue of their choice of language being more appropriate to the given project.

keep in mind though that size of the organization/team/... matters greatly. I have been involved with tens of projects over the course of my career (3 decades) and have encountered numerous scenarios where the choice of languages/technologies/... is already made, company-wide. I have seen this especially in companies that do a lot of contracting work. If apps are built say on top of springboot services and angular front-ends and we have 200 developers that specifically learned and know those technologies (along with myriad of internal libraries etc built on top of those technologies) swapping people between the projects becomes a non-event (or even adding few bodies to meet deliverables).

If you are starting from scratch fortran is a bad choice. However if you have a fortran project that keeps getting more features you may become an amazon clone along the way

I was of course being facetious mentioning fortran but given a choice between working with an amazing group of people on a project which has a completely wrong tech/frameworks/... stack for the job at hand (e.g. fortran to built an e-commerce website) vs. working with average/subpar team utilizing some amazing stack, I'd choose the former any day of the week and twice on Sunday

> There are definitely incorrect language choices for certain projects.

There is an entire book about it which documents the problems in lavish detail, and it's generally hailed as a classic and a must-read.

https://www.dreamingincode.com/