8 ms·

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 re

by bri3d 1y ago

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.

ludicity 1y ago
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 if forced to. We can't ship if the feedback loop is a 30-minute CI pipeline because there is no way to have a local dev environment.
- Ocerge 1y ago
  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!
  - bluGill 1y ago
    I remember being there and the large amount of work many people did to make things better. Dig in for a few years and you can too.
  - skydhash 1y ago
    I had local development in a previous job, but you had to start a whole Kubernetes cluster. No unit tests, but a whole suite of e2e tests. And forget about debuggers as it was all microservices.
    - fragmede 1y ago
      They may not have existed back then, but between kind, and either Tilt or Skaffold, it's at least not as bad as it once was.
    - pjmlp 1y ago
      When using Java or .NET, it is possible to plug debuggers into microservices, but that needs to be taken into account when designing their Dockerfiles. Just as heads up for others.
  - seemaze 1y ago
    Lol, that sums up the human experience. You should sell bumper stickers: "Rock bottom is deeper than you think!"
  - connicpu 1y ago
    My team reimplemented a stripped down binary of what our primary service does just so we could run it on our local machines. Otherwise it would take up well over 100GB of RAM. Iteration was a lot more annoying before we did that :)
tyleo 1y ago
> 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. This is my experience too. I’d go a bit further and say the leads are the primary driver of success. Because ultimately, if the composition of the people on a project is incorrect, it’s the lead’s responsibility to realize and change it.
seneca 1y ago
This is really the heart of it: > Don't get me wrong - to an extent, some languages (especially more niche ones) drive hiring and what kind of employee you get In my experience, the community around a given language is going to significantly influence the sort of typical applicant you get for a job working in that language. Those profile vary a surprising amount, especially for, as you say, niche languages, but also for "beginner" languages. I have seen businesses significantly harmed because they hired what I would term language specific technicians instead of engineers. That's a failure of leader, certainly, but that failure is a lot more likely for certain languages.
- bri3d 1y ago
  > they hired what I would term language specific technicians instead of engineers. I have seen this too, and I really like the way you phrased it - I think I'll use that in the future! I do think it's an easier trap to fall into with some languages, but I still don't think the language really drives it. I worked on a large-scale Rust project that could probably have been a Go project a while ago and while Language Technicians were a big hiring hazard, after we got one or two we both learned how to manage them and stopped hiring that type of employee (since they weren't what our project needed) and things evened out and were successful in Rust.
  - seneca 1y ago
    > I do think it's an easier trap to fall into with some languages, but I still don't think the language really drives it. Yeah, in the end poor hiring practices drive it. The language you choose just makes the probability of that failure possibility higher or lower. > I worked on a large-scale Rust project that could probably have been a Go project a while ago and while Language Technicians were a big hiring hazard, after we got one or two we both learned how to manage them and stopped hiring that type of employee (since they weren't what our project needed) and things evened out and were successful in Rust. That tracks with my experience, for sure. Once you learn to spot it, you can mitigate it.
    - pdimitar 1y ago
jerf 1y ago
"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.
- tyleo 1y ago
  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.
  - jerf 1y ago
    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.
hshdhdhehd 1y ago
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).
- roguecoder 1y ago
  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 because Rails neatly supported what we were doing and so much could be generated. We ended up with better test coverage too.
  - pdimitar 1y ago
    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).
- pdimitar 1y ago
  > 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.)
fabian2k 1y ago
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.
OkayPhysicist 1y ago
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. Switching from C++ to Rust? Probably not.
- tcfhgj 1y ago
  > Switching from C++ to Rust? Probably not. Counter example: https://fishshell.com/blog/rustport/ https://fishshell.com/blog/rustport/
  - bri3d 1y ago
    FWIW, this was an intelligent rewrite, piece by piece. This is the only way I have ever seen "rewrite it in X" ever work. Fish also isn't a commercial product, so the calculus is a little different.
- bmitc 1y ago
  > Moving from LABVIEW to a real programming language ... Switching from C++ to Rust? Probably not. Weird. LabVIEW is a real programming language. And both LabVIEW and Rust make entire classes of bugs that you often hit in C++ go away, especially for concurrent programs. > remotely modern development tooling I would make the argument that it is the tooling, i.e., Git and Diff, that is ancient and not remotely modern. Continually demanding that anything worth source controlling is text-based, and even further line-based, is as antiquated as it gets.
  - bri3d 1y ago
    > Continually demanding that anything worth source controlling is text-based, and even further line-based, is as antiquated as it gets. Do you have examples of working version control for non-text programs, including the ability to combine work from two parallel workstreams (aka, merge)? I worked for a long time at probably one of the largest companies using non-text based programming and version control was never even close to solved, and my subsequent forays into the literature when I worked in the "no code workflow" space still came up empty handed for working solutions here. We always fell back to "try to represent the structure of the change in some text-based way."
mamcx 1y ago
> I cannot agree that programming language choice is a primary driver in a product's success or failure.... This and similar are common ideas for the people that never see the real whole world of programming, and maybe have the fortune of be in the "startup" circles. I see the opposite, and is very good predictor to know how bad a product or a team is, using the programming language AND the main DB engine, but that is because I live in the world of "enterprise" code where for example: * I'm called to do a rewrite * I see the screenshot of the main app * I guess correctly was made with vb (first big alarm) (how I know: I never see in my circle anybody that do vb, php, c, c++ anything resembling a sane UI. BTW just the use of colors was enough to guess) * I worry, but confirm, that use Access as the main db * I discover that part of the data was ALSO in a excel file, that is used with the equivalent of "joins", and was not surprised to see things like this Even without knowing more about the people that do it, that is far enough signals to guess much. BTW, there are very good predictors, if Use: MySql, MonGo, Php, Js (almost whatever you wanna add here in terms of frameworks), VB, Perl, Android (aka: Java android and android itself without using iOS alongside), is likely terrible. Then Java or C# taking turns how much worse, but not as bad as the ones before. I sweat if somebody say it use C or C++. Probably enough to straight refuse to take the project. Any use of not-obscure tech in this sector and is a good predictor to be more or less not-that-bad. BTW: Also complex infra and related boilerplate is now probably a stronger predictor after some langs like python, go, typescript and more modern java/kotlin/c# has spread (and also more pg and much less nosql, but too much "cloud")
- binary132 1y ago
  I think you’re confusing cause and effect. The cause here is bad engineering. The effect is bad architecture and unmaintainable software.
- necovek 1y ago
  If you are called in to rewrite the project, I would say this signals a successful project: it was built in whatever tech stack a midling engineering team had competency in, it originally worked well but started struggling with more scale/needs/updates, and it is still worth enough to invest in rewriting it. Yes, you may not enjoy turning a legacy system that works into a nicely architected system, but the ones that get to that phase are clear successes IMO. Contrast this with systems which had nice, clean, maintainable architecture from day one but bit the dust two years later. The original article is a silly shill, as engineering managers have looked at economic cost of choosing a language and other technology since... forever. And some of that "invisible" discussion happens visibly too (I've done that a number of times: "how do we keep our engineers motivated who want to explore a new hyped tech stack vs the cost of them being slower or leaving the company").
dev_l1x_be 1y ago
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-rust https://discord.com/blog/why-discord-is-switching-from-go-to...
mpweiher 1y ago
> I cannot agree that programming language choice is a primary driver in a product's success or failure A possible reason for this is that our current languages are way too similar to make a difference. Even most of the ones we think of as radically different.
tbrownaw 1y ago
> 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.
- pdimitar 1y ago
  > 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...
zeroq 1y ago
It's not a contradiction if you assume that (a) language choice is critical and (b) rewrites are doomed to be failures. Having that said I agree that language/platform is a "non technical requirement" in 90% of real world cases. You pick what you know or in more industrious scenarios - what's available on the market or what's the most cost effective. But people are indeed irrational about programming languages. There's tribalism, stereotypes and preconceptions. Most notable is probably PHP, language for human failures and shit projects. As if same exact project written in Java was suppose to be of higher philosophical value. But it's something you can't deny. I've been asked in non ironic way by a (non technical) founder investor if I could recommend him Rails programmers, because he read about it and it's suppose to be great. I asked him about specifics of his new project and he said he doesn't have an idea yet, but it has to be in Rails. Go figure.
asveikau 1y ago
> rewriting a product only to change programming language is _always_ a bad idea, There are of course a few scenarios where changing the programming language is a more defensible, less "always wrong" kind of thing. An extreme case would be something like a COBOL system that needs maintenance and you have trouble finding people who can do it.
- FuckButtons 1y ago
  Or if you’ve written the mvp in python and realize you have to meet some performance metric that is 100x what your system is capable of.
  - roguecoder 1y ago
    It is bizarre how popular Python is for a language that is as poorly operationalized and encourages such poor architecture choices. I would argue that the number of successful companies with Python code bases is the best evidence that language choice doesn't matter.
jolt42 1y ago
Java didn't exist when I originally wrote C++ code. When it did come around it was easily 4x improvement for a good amount of development (eg. enterprise software). I think you need like 4x+ to be worth switching, and I don't see that between many languages. I do see it between libraries/frameworks though. I think a lot of the problem of switching isn't so much the language, but relearning all the undocumented lessons that were learned the hard way the first time around.
- beachy 1y ago
  I had the same experience. I was put in charge of a large ERP rewrite in C++. Being woefully unprepared we dived in and, based on the issues the existing C codes had, the first thing we built was a memory management framework - what I realized much later was basically garbage collection. It worked very well. When Java came along its garbage collection blew my mind. I agree with the 4x factor.
- trenchpilgrim 1y ago
  In my experience so far most languages I've encountered have been similar enough that language choice mostly comes down to "Does it have the APIs I need" and "Do I like the tooling." There are a handful of exceptions where the capabilities of the language are fundamentally different enough to provide a competitive edge. - Systems languages with manual memory management, like C or Zig, where real-time/low-latency performance is important. - Rust and its borrow checker, as an alternative to manual memory management. - A strongly FP influenced language such as a Lisp or Haskell. Especially Lisp macros. Exceptionally good for working with structured data in cases where purity is more important than performance. - The BEAM/OTP architecture for distributed systems (Erlang/Elixir). - Languages with good CUDA/PTX/Vulkan support, for programs that need the GPU. - Assembly. This was a much bigger deal in the past before compilers got good. Today good mostly for educational purposes.
WalterBright 1y ago
> I cannot agree that programming language choice is a primary driver in a product's success or failure I've rewritten a very large and complex macro assembler program into C. The original developers were gone. Nobody would touch that assembler code. I volunteered. The result was a program that could be maintained and could be ported to multiple diverse platforms needed by the company. I tried to port Optlink (a linker for Win32) from assembler into C. It failed because the market for Win32 programming died, and so I abandoned the project. My Empire game started out in BASIC. Then it was converted to FORTRAN, then PDP-11 assembler, then C on the PC, then D.
_sharp 1y ago
The point of the article was to choose your language based on economic impact, rather than technical debates that are a facade of an engineer's identity beliefs. With that pov, I don't see any contradiction by saying the language is an important decision, and rewriting your project in a new language is probably a bad idea.

by bri3d 1y ago

ludicity 1y ago

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 if forced to. We can't ship if the feedback loop is a 30-minute CI pipeline because there is no way to have a local dev environment.

Ocerge 1y ago
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!
- bluGill 1y ago
  I remember being there and the large amount of work many people did to make things better. Dig in for a few years and you can too.
- skydhash 1y ago
  I had local development in a previous job, but you had to start a whole Kubernetes cluster. No unit tests, but a whole suite of e2e tests. And forget about debuggers as it was all microservices.
  - fragmede 1y ago
    They may not have existed back then, but between kind, and either Tilt or Skaffold, it's at least not as bad as it once was.
  - pjmlp 1y ago
    When using Java or .NET, it is possible to plug debuggers into microservices, but that needs to be taken into account when designing their Dockerfiles. Just as heads up for others.
- seemaze 1y ago
  Lol, that sums up the human experience. You should sell bumper stickers: "Rock bottom is deeper than you think!"
- connicpu 1y ago
  My team reimplemented a stripped down binary of what our primary service does just so we could run it on our local machines. Otherwise it would take up well over 100GB of RAM. Iteration was a lot more annoying before we did that :)

tyleo 1y ago

> 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. This is my experience too. I’d go a bit further and say the leads are the primary driver of success. Because ultimately, if the composition of the people on a project is incorrect, it’s the lead’s responsibility to realize and change it.

seneca 1y ago

This is really the heart of it: > Don't get me wrong - to an extent, some languages (especially more niche ones) drive hiring and what kind of employee you get In my experience, the community around a given language is going to significantly influence the sort of typical applicant you get for a job working in that language. Those profile vary a surprising amount, especially for, as you say, niche languages, but also for "beginner" languages. I have seen businesses significantly harmed because they hired what I would term language specific technicians instead of engineers. That's a failure of leader, certainly, but that failure is a lot more likely for certain languages.

bri3d 1y ago
> they hired what I would term language specific technicians instead of engineers. I have seen this too, and I really like the way you phrased it - I think I'll use that in the future! I do think it's an easier trap to fall into with some languages, but I still don't think the language really drives it. I worked on a large-scale Rust project that could probably have been a Go project a while ago and while Language Technicians were a big hiring hazard, after we got one or two we both learned how to manage them and stopped hiring that type of employee (since they weren't what our project needed) and things evened out and were successful in Rust.
- seneca 1y ago
  > I do think it's an easier trap to fall into with some languages, but I still don't think the language really drives it. Yeah, in the end poor hiring practices drive it. The language you choose just makes the probability of that failure possibility higher or lower. > I worked on a large-scale Rust project that could probably have been a Go project a while ago and while Language Technicians were a big hiring hazard, after we got one or two we both learned how to manage them and stopped hiring that type of employee (since they weren't what our project needed) and things evened out and were successful in Rust. That tracks with my experience, for sure. Once you learn to spot it, you can mitigate it.
  - pdimitar 1y ago

jerf 1y ago

"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.

tyleo 1y ago
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.
- jerf 1y ago
  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.

hshdhdhehd 1y ago

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).

roguecoder 1y ago
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 because Rails neatly supported what we were doing and so much could be generated. We ended up with better test coverage too.
- pdimitar 1y ago
  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).
pdimitar 1y ago
> 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.)

fabian2k 1y ago

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.

OkayPhysicist 1y ago

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. Switching from C++ to Rust? Probably not.

tcfhgj 1y ago
> Switching from C++ to Rust? Probably not. Counter example: https://fishshell.com/blog/rustport/ https://fishshell.com/blog/rustport/
- bri3d 1y ago
  FWIW, this was an intelligent rewrite, piece by piece. This is the only way I have ever seen "rewrite it in X" ever work. Fish also isn't a commercial product, so the calculus is a little different.
bmitc 1y ago
> Moving from LABVIEW to a real programming language ... Switching from C++ to Rust? Probably not. Weird. LabVIEW is a real programming language. And both LabVIEW and Rust make entire classes of bugs that you often hit in C++ go away, especially for concurrent programs. > remotely modern development tooling I would make the argument that it is the tooling, i.e., Git and Diff, that is ancient and not remotely modern. Continually demanding that anything worth source controlling is text-based, and even further line-based, is as antiquated as it gets.
- bri3d 1y ago
  > Continually demanding that anything worth source controlling is text-based, and even further line-based, is as antiquated as it gets. Do you have examples of working version control for non-text programs, including the ability to combine work from two parallel workstreams (aka, merge)? I worked for a long time at probably one of the largest companies using non-text based programming and version control was never even close to solved, and my subsequent forays into the literature when I worked in the "no code workflow" space still came up empty handed for working solutions here. We always fell back to "try to represent the structure of the change in some text-based way."

mamcx 1y ago

> I cannot agree that programming language choice is a primary driver in a product's success or failure.... This and similar are common ideas for the people that never see the real whole world of programming, and maybe have the fortune of be in the "startup" circles. I see the opposite, and is very good predictor to know how bad a product or a team is, using the programming language AND the main DB engine, but that is because I live in the world of "enterprise" code where for example: * I'm called to do a rewrite * I see the screenshot of the main app * I guess correctly was made with vb (first big alarm) (how I know: I never see in my circle anybody that do vb, php, c, c++ anything resembling a sane UI. BTW just the use of colors was enough to guess) * I worry, but confirm, that use Access as the main db * I discover that part of the data was ALSO in a excel file, that is used with the equivalent of "joins", and was not surprised to see things like this Even without knowing more about the people that do it, that is far enough signals to guess much. BTW, there are very good predictors, if Use: MySql, MonGo, Php, Js (almost whatever you wanna add here in terms of frameworks), VB, Perl, Android (aka: Java android and android itself without using iOS alongside), is likely terrible. Then Java or C# taking turns how much worse, but not as bad as the ones before. I sweat if somebody say it use C or C++. Probably enough to straight refuse to take the project. Any use of not-obscure tech in this sector and is a good predictor to be more or less not-that-bad. BTW: Also complex infra and related boilerplate is now probably a stronger predictor after some langs like python, go, typescript and more modern java/kotlin/c# has spread (and also more pg and much less nosql, but too much "cloud")

binary132 1y ago
I think you’re confusing cause and effect. The cause here is bad engineering. The effect is bad architecture and unmaintainable software.
necovek 1y ago
If you are called in to rewrite the project, I would say this signals a successful project: it was built in whatever tech stack a midling engineering team had competency in, it originally worked well but started struggling with more scale/needs/updates, and it is still worth enough to invest in rewriting it. Yes, you may not enjoy turning a legacy system that works into a nicely architected system, but the ones that get to that phase are clear successes IMO. Contrast this with systems which had nice, clean, maintainable architecture from day one but bit the dust two years later. The original article is a silly shill, as engineering managers have looked at economic cost of choosing a language and other technology since... forever. And some of that "invisible" discussion happens visibly too (I've done that a number of times: "how do we keep our engineers motivated who want to explore a new hyped tech stack vs the cost of them being slower or leaving the company").

dev_l1x_be 1y ago

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-rust https://discord.com/blog/why-discord-is-switching-from-go-to...

mpweiher 1y ago

> I cannot agree that programming language choice is a primary driver in a product's success or failure A possible reason for this is that our current languages are way too similar to make a difference. Even most of the ones we think of as radically different.

tbrownaw 1y ago

> 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.

pdimitar 1y ago
> 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...

zeroq 1y ago

It's not a contradiction if you assume that (a) language choice is critical and (b) rewrites are doomed to be failures. Having that said I agree that language/platform is a "non technical requirement" in 90% of real world cases. You pick what you know or in more industrious scenarios - what's available on the market or what's the most cost effective. But people are indeed irrational about programming languages. There's tribalism, stereotypes and preconceptions. Most notable is probably PHP, language for human failures and shit projects. As if same exact project written in Java was suppose to be of higher philosophical value. But it's something you can't deny. I've been asked in non ironic way by a (non technical) founder investor if I could recommend him Rails programmers, because he read about it and it's suppose to be great. I asked him about specifics of his new project and he said he doesn't have an idea yet, but it has to be in Rails. Go figure.

asveikau 1y ago

> rewriting a product only to change programming language is _always_ a bad idea, There are of course a few scenarios where changing the programming language is a more defensible, less "always wrong" kind of thing. An extreme case would be something like a COBOL system that needs maintenance and you have trouble finding people who can do it.

FuckButtons 1y ago
Or if you’ve written the mvp in python and realize you have to meet some performance metric that is 100x what your system is capable of.
- roguecoder 1y ago
  It is bizarre how popular Python is for a language that is as poorly operationalized and encourages such poor architecture choices. I would argue that the number of successful companies with Python code bases is the best evidence that language choice doesn't matter.

jolt42 1y ago

Java didn't exist when I originally wrote C++ code. When it did come around it was easily 4x improvement for a good amount of development (eg. enterprise software). I think you need like 4x+ to be worth switching, and I don't see that between many languages. I do see it between libraries/frameworks though. I think a lot of the problem of switching isn't so much the language, but relearning all the undocumented lessons that were learned the hard way the first time around.

beachy 1y ago
I had the same experience. I was put in charge of a large ERP rewrite in C++. Being woefully unprepared we dived in and, based on the issues the existing C codes had, the first thing we built was a memory management framework - what I realized much later was basically garbage collection. It worked very well. When Java came along its garbage collection blew my mind. I agree with the 4x factor.
trenchpilgrim 1y ago
In my experience so far most languages I've encountered have been similar enough that language choice mostly comes down to "Does it have the APIs I need" and "Do I like the tooling." There are a handful of exceptions where the capabilities of the language are fundamentally different enough to provide a competitive edge. - Systems languages with manual memory management, like C or Zig, where real-time/low-latency performance is important. - Rust and its borrow checker, as an alternative to manual memory management. - A strongly FP influenced language such as a Lisp or Haskell. Especially Lisp macros. Exceptionally good for working with structured data in cases where purity is more important than performance. - The BEAM/OTP architecture for distributed systems (Erlang/Elixir). - Languages with good CUDA/PTX/Vulkan support, for programs that need the GPU. - Assembly. This was a much bigger deal in the past before compilers got good. Today good mostly for educational purposes.

WalterBright 1y ago

> I cannot agree that programming language choice is a primary driver in a product's success or failure I've rewritten a very large and complex macro assembler program into C. The original developers were gone. Nobody would touch that assembler code. I volunteered. The result was a program that could be maintained and could be ported to multiple diverse platforms needed by the company. I tried to port Optlink (a linker for Win32) from assembler into C. It failed because the market for Win32 programming died, and so I abandoned the project. My Empire game started out in BASIC. Then it was converted to FORTRAN, then PDP-11 assembler, then C on the PC, then D.

_sharp 1y ago

The point of the article was to choose your language based on economic impact, rather than technical debates that are a facade of an engineer's identity beliefs. With that pov, I don't see any contradiction by saying the language is an important decision, and rewriting your project in a new language is probably a bad idea.