Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Rational choice for an engineer is not the same thing as rational choice for the company. I want to have an interesting working life, learning new things and keeping my CV current. It's not rational for me to shackle my career to doing maintenance fixes on a dying PHP app.
- We see the "we need to rewrite in X" conversation play out all the time here on HN. Love this take on it.by bobx17
- Yes, we do, but that is not the subject the article is talking about.
From the way so many commentators are refusing to engage with the point expressed in the title I think there is collective denial of the core point, so instead, people are discussing the symptoms rather than the disease that is the subject here.
by lproven - Isn't this what Joel wrote 25 years ago? Don't rewrite your software?
I wrote a compiler/language, and I was expecting something different from the article after my experiences
Like many of the other commenters, I didn't like the article
by levodelellis - That is not what the article is about.
The subject is right there in the title:
Engineers Can't Be Rational About Programming Languages
by lproven - > 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.
by wiseowise - Maybe not the most expensive but it is certainly potentially one of the most costly. Look at Facebook with PHP and Dropbox with Python. It's the sort of thing you can overcome despite the odds (as both those companies did), but can also tip an on-the-edge company into failure.
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.
by IshKebab - It CAN be.
If a company chose brainfuck as a main programming language, it's doubtful they'd come back from that choice.
by cozzyd - This person appears to have been "Languages Product Lead at Google", so they are very used to arguing about how important language choice is.by Arcuru
- This falls into the "people aren't rational/logical" trap. You really have to define what you would mean for it to be rational. And then you have to establish what the baseline ideas are from which you plan on establishing the logic/rationality. All the while, you need to really resist any "just so" stories that would explain anything.
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.
by taeric - A reasonable rate at which to consider a new primary programming language for non-niche, non-throwaway production software is once every 15 years. Adventurous, risk-seeking teams can try for 10, but that's pushing it.
If you find yourself searching for a replacement language more frequently, you should stop, take a long look in the mirror and ask yourself:
1. Something has clearly gone wrong last time, since you're looking for a replacement so soon; are you confident of your language-picking ability?
2. Are you sure your goal is to do what's best for the software and its long-term maintenance, or is there some other consideration here?
by pron - What’s your take on older languages gaining new life in production because of ecosystem improvements? I’m thinking of Python, which for most of its 34 year history wasn’t always a go-to choice, but nowadays its ecosystem is being scaled with Rust and C++ libraries and tooling. I’ve noticed a similar trend in JavaScript, where Go and Rust are improving bundlers, type-checkers, etc. The way we deploy our software has also changed dramatically with Kubernetes, code running at the edge (thinking of Cloudflare Workers, AWS Lambda).
- I absolutely love this take. Then again it matches what I've been saying for decades, so I would.
Generalizing briefly, the same phenomena of identity underlies a lot of our religious wars. Be it language, braces, indentation, or a variety of other programming choices. What's fundamentally going on is that programming expertise is fragile. (I think I first saw that idea in Code Complete?) A new language / style / technology / whatever very often will leave us less competent. Ideally we would respond with, "I guess I need to get back on that learning curve." But often it is easy to instead blame the external factor. "I'm a good programmer. I tried it. The result didn't work well. It must be bad."
Among the many attempts to try to fix the problem, I can recommend https://blog.codinghorror.com/the-ten-commandments-of-egoles.... To the extent that you manage to apply its advice, you really will do better.
Of course your improvement won't directly help those around you...
by btilly - > A new language / style / technology / whatever very often will leave us less competent.
This may be a big factor in rejecting unfamiliar languages. Over time the brain trains itself to grok a specific syntax, and understanding becomes partly automatic: we look at a Java program and our brain injects meaning into our consciousness. If we then look at APL or Lisp, however, that training on Java doesn't apply and the automatic injection doesn't function. We're left having to read the symbols directly, and it's unsettling not having the auto-assist. It makes us feel we "can't" understand the language, when it would likely take a couple weeks of immersion to change that impression.
- > 1. The power to transcend paradigms.
- Donella Meadows, Leverage Points: Places to Intervene in a System https://donellameadows.org/archives/leverage-points-places-t...
If you're a Python Programmer, and you've made that your identity, you've trapped yourself into the mindset that you are a Python Programmer. Same with any other identity you ascribe to yourself (or allow others to ascribe to you). Separating yourself from your tools allows you to evaluate the tools independently of your identity and you will find yourself unaffected (or at least less affected) by reaching a conclusion that the thing you know well may not be appropriate to the job. You may not be appropriate for the job, and that's fine too. Getting past paradigms (or identities with how I'm extending it) gives you much greater freedom to explore and participate in the world.
by Jtsummers - Someone told me to read Meadows over a year ago, and I can no longer remember who, and to make it worse it slipped off my radar. I'm filled with regret now because they appear to be a concise and insightful thinker, or at least an effective proliferative of good ideas.by ludicity
- >Getting past paradigms gives you much greater freedom to explore and participate in the world.
It's not me who has problems getting past paradigms, or anyone else I know for that matter, it's the recruiters and HR people who screen resumes by only ticking boxes on buzzword.
by jack_tripper - > A programming language is the single most expensive choice a company makes, yet we treat it like a technical debate
I'd have to disagree, it really isn't, and I even think that's kind of the point the article makes.
Rewritting existing services from scratch in another language can often be a bad decision, because it assumes the choice of programming language is an important one. And any rewrite is costly, doesn't matter the reason why.
But starting a new project in a new language I don't think has much impact generally. And if it motivates the team, because they're excited about it, it can even help.
Deciding later to rewrite this once it's been built because it's not in the same language as what is common at the company, that's likely the mistake that will happen.
by didibus - By corollary with Warren Buffett's belief that the most important financial decision you will ever make is to choose your marital partner... The most expensive choice a company makes is who will lead.
NOT because a good leader will save $$$$$$; because a bad leader can single-handedly sink a ship.
by IAmBroom - I dunno. I take the position that language designers have blind spots around the weaknesses of their languages.
Python: Python is almost a hard-compiled language. Most of the dynamic stuff that's really hard to compile isn't all that useful. But Guido and his enablers love the dynamism, and the CPython implementation. So instead of PyPy taking over, we have CPython with hacks to call C.
Go: The "share by communicating" thing in Go works out about as well as it does in other languages, that is, it's useful but not central. Early on, there were tortured examples of implementing locks with queues. Nobody does that any more. People pretty much write Go like they do other languages, with shared state and locks. Queues are used when queues do something useful. The real strength of Go is that the libraries needed for webcrap are maintained and used by Google, so they're all well-tested and exercised. Also, goroutines/green threads eliminate the sync/async distinction. Garbage collection takes care of most ownership problems. Simple. (I recently wrote a web back end in Rust. Big mistake. Should have used Go.)
Rust: The "traits" system is an overreaction to Objects Are Bad. Rust probably would have been better off with single inheritance, which is well understood. (Multiple inheritance has too many dark corners.) People keep trying to do OOP with traits, which is like pounding a screw. Rust still doesn't have a good solution to the back reference problem, as I point out occasionally. The macro language sucks, but then almost all macro languages suck. "Async" is a nightmare but necessary to keep the Javascript crowd happy, since that's all they know. If you really need complex multiprocessor concurrency, Rust is currently the best game in town. Most people don't.
C++: They can't take anything out, and the cruft is too deep. "Modern C++" is not all that bad, but all of bad old C/C++ is still in there. So the safety situation remains awful. The cumulative complexity is now so high that even long-time language lawyers are giving up following it.
Javascript: Who thought that would rule the world? It's awful, but everywhere. Heroic efforts have made an inherently slow language go fast. It's kind of impressive, actually.
by Animats - I generally agree with your sentiment.
> Rust: The "traits" system is an overreaction to Objects Are Bad.
It's interesting. Interfaces, traits, and mixins are all OOP concepts.
> "Async" is a nightmare
In what way? I do agree though, that it's annoying to yet again have a new language not have concurrency baked into the language. In some ways, Rust has excuses, because they want their concurrency primitives to support microcontroller, real-time Linux, and general purpose programming.
by bmitc - Python: I get how PyPy is better in some ways, but calling C libs is the most important feature of Python. It doesn't have a lot going for it otherwise.
Go: Greenthreading is a big deal in backends. Arguably the main reason for Kotlin is because Java didn't have that, but now there are vthreads. Rust has chipped away at the Go systems use cases, so it's mainly for backends and CLIs now, but I wish it had better error handling.
Rust: There's a very good preso from the Rust team about how they arrived at async/await, and also how every other language does concurrency. Greenthreading was considered, main problem being you need a runtime for that.
C++: Torvalds was right about it all along.
JS: Honestly the best high-level language, made better choices than Python, never made huge breaking changes, somehow had a decent answer to cooperative multitasking before most other langs, deserves its popularity.
by morshu9001 - As far as I'm aware, Rust's trait system is more closely related to Haskell's type class system than to actual object-oriented programming. As a type class system, it is fine; it is a different mindset than classic OOP. Rust happens to also use this same system for something more closely resembling traditional objects, but this is much more restricted than either.by egorelik
- More often than not, preference should be given to the language most of the team know the best. The only exception is when everyone on the team feels a different language is a better fit for the need or there are underlying reasons for a language shift.
Personally, my bias is towards the languages I'm most comfortable with. I recognize this and will make other suggestions and if I'm not responsible for the code, I'm more than flexible.
All the fad chasing and top down declarations that we're all going to use Cucumber, GraphQL, Microservices or anything else is often a bad move.
First learn the problem you are trying to solve and empathize on behalf of the user... Then empathize on behalf of support... on behalf of the maintenance developers... on behalf of yourself in a decade. Is there a boxed solution? Buy it.. Is something custom really needed, what can you outsource as part of it? integrate it. Do the simplest, easiest thing you can to get the job done.
by tracker1 - > 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 use a language with functions as first class types (ie a FP language). You might say, most people doing ML use Python. This came to be because the language was picked based upon what people knew. But the big companies doing ML (successfully) don't use Python anymore and haven't for over a decade. ML researchers kept FP alive for several decades when nobody else cared because FP is the best tool for ML (or for writing a compiler). Where the FP folks get into trouble is trying to push FP where it doesn't make sense. I see this pattern repeating over and over again. Languages are pitched as silver bullets when they are just screwdrivers and hammers.
Right tool for the job, ignoring this leads to "religious wars" because that's how we describe disputes which are matters of taste.
Also, you are massively overvaluing expertise in a given language. A more talented engineer who doesn't know your favorite language after a couple of months will be better than you in your favorite language too despite your greater experience with that language.
by hunterpayne - > 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 mixing just scripts with regular languages is a problem; calling one language from another is similar. The same with unnecessary remote APIs. Less technologies is often better, even if the technologies are not the best (eg. using PostgreSQL for features like fulltext search, event processing, etc.)
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).
by thomasmg - 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 them reiterated is fine.
Then they turn around and claim that choosing a programming language is the most important thing you can do, and that you'll need to Like and Subscribe to learn more about it...
I've been through tens of rewrite projects, successful and unsuccessful, and seen projects and products at almost every scale, and I cannot agree that programming language choice is a primary driver in a product's success or failure. Even extending this thesis from language to framework and ecosystem, where there's perhaps a _tiny_ bit of signal, still doesn't really lead to a meaningful conversation. The main driver of a project's success is almost always driven by: the composition of employees working on the project, and the competence of the people architecting the project. Don't get me wrong - to an extent, some languages (especially more niche ones) drive hiring and what kind of employee you get, but this effect is dwarfed by who works on the project and how well it's managed.
by bri3d - It's not an issue as long as you use a mainstream language, but using a language or framework that will be perceived as a dead end can hurt your chances to hire and retain people. If you're a large or prestigious enough employer you can probably compensate that as long as you're willing to train people.
Programming language alone should almost never be a big enough issue to force a rewrite, but if you already have serious other issues that force huge changes you might as well look at it at the same time.
by fabian2k - I think rewriting something in another language can be a great idea, especially if $CURRENT_LANG does not have a sane way of configuring its features.
https://discord.com/blog/why-discord-is-switching-from-go-to...
by dev_l1x_be - "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 language decisions.
I'm going to exaggerate to make the point in an attempt to avoid too much argument about whether or the language would be suitable, but: You do not sit down to write an industry-leading, high-performance database whose top-level implementation language is Python. If your project spec involves running code provided at runtime by users, Go is a fairly poor choice. You can make things a lot harder for yourself trying to be too insistent about what language you'll do your mobile development in, rather than just accepting that there's a very dominant choice in those spaces.
I've also seen projects I couldn't prove to you beyond a shadow of a doubt failed due to language selection, but I am fairly certain the project I saw that chose Scala failed primarily for the choice of Scala where it was a bad fit, both technically and for the skillsets of the engineers involved.
I've also seen projects nearly fail because they chose databases incorrectly, which I would submit is a fairly similar thing. Mostly because of choosing a NoSQL database "because fast" when they should have used a relational DB. The projects in question didn't fail because they were able to switch in time, but it was a close thing.
Part of "the composition of the employees of a project" being responsible for its success is that good engineers pick at least a decent solution to a problem from day one. The aforementioned DB problem, for instance, should have been obvious from the very beginning that it was not the correct choice in their case. There are absolutely wrong choices, that can crash projects both quickly and slowly.
by jerf