You can choose tools that make you happy
86 comments
·May 22, 2025hardwaregeek
strken
> Is there any actual evidence that one stack is better than another? No, not really.
It is not controversial to say that any two stacks will have advantages and disadvantages over each other. There is absolutely evidence that Go compiles code faster than C++, or that C++ can call C code with less overhead, or that Rust eliminates certain classes of bugs, or that Postgres supports LISTEN/NOTIFY and SQLite doesn't, or that SQLite excels at storing a database in a single file.
Choosing a given stack means picking which particular advantages you want and/or need. I agree that there's no evidence that one stack is always "better", but this is like asking for evidence that a hacksaw is better than a table saw: they don't do the same thing! You can probably use either of them to cut through a skinny tree branch, though.
carlmr
>It's just that software engineers like to pretend they're fully rational beings
So much this. There are some rational factors to consider, but in the end gut feeling and UX is a much bigger factor than what people like to admit.
IME the people that espouse "facts over feelings" often have a lot of badly expressed feelings disguised as rational opinion. I prefer discussing with people that are at least aware of their own feelings and can admit that.
bicx
I think there are definitely objective reasons why you would pick certain stacks for specific projects. They all have strengths and weaknesses. You can technically achieve a lot of the same tasks regardless of your stack choice, but the timeframe, elegance, available ecosystem, cost, and ability to hire for your stack may vary quite a bit.
That said, if I’m not spending someone else’s money, I’ll pick the stack I enjoy or feel most productive in. I use Elixir for my own projects, but it’s generally a bad option for the startups I work for. Tough to hire for, limited ecosystem, unusual and sometimes polarizing concepts. It’s a business risk compared to, say, TypeScript or Go. Great concurrency model and cool pipeline capabilities though. :)
bluGill
there are objective strengths and weaknesses. However for any set there is another option that has very similar pros and cons with just one - often minor point different.
monksy
I feel like Elixir has such a small amount of jobs that it would be a lightning rod for those who have skills in it. I appreciate Elixir, I like it. But it's weird to see an expectation of experience in it when the marketplace is so small.
You could always target scala/akka engineers with it. Theres a lot of crossover there.
simonask
Software development is not engineering, but it's also not completely arbitrary. It's a craft, and like all other craftspeople, you build intuition through experience, which guides decision-making.
It's a little controversial to say that it isn't engineering, but compare what we do to things like building bridges or constructing dams. The level of rigor in those fields is galaxies apart from almost all of software development. You _could_ apply it, and some organizations do, especially when lives are on the line, but the cost/benefit ratio is impossible to justify in almost all software development.
This isn't to say that "real" engineers don't also build intuition, but they have enormously higher accountability requirements. In some areas I would argue that software development _should_ have much higher accountability, but this also means a significantly higher cost. I think governments around the world are coming to realize that the money would be well spent.
worik
> building bridges or constructing dams.
Discuss your ideas with a civil engineer
You'd be surprised how similar our professions are
Our shoddy work is our fault, we know how to do better, we don't
We are like civil engineering in 1850
bonoboTP
I think software engineers would benefit from talking a bit more with actual engineer peers at real companies and hear them vent and rant, to see that "real engineering" isn't the idealized utopia we imagine it to be either.
nasretdinov
I've worked in backend infrastructure teams for ~6 years in a couple PHP shops, and you know what, dynamic languages absolutely suck when you want to do any kind of refactoring :). That made me really appreciate compiled languages like Go, since they don't feel too heavy and have a feeling close to a dynamic language, but do allow for painless refactoring.
askonomm
Modern PHP shops don't really do dynamic PHP anymore. Ever since it got types and runtime type validation. Refactoring is also proven to be very easy as a result, and especially with something like Rector (https://github.com/rectorphp/rector).
nh2
> types and runtime type validation
This is what "dynamic typing" means.
In other languages, you know that the types are right /before/ you run the code.
vinceguidry
I wouldn't want to refactor anything other than Ruby. If you have the intuitive understanding about how its object model and scoping semantics works, refactoring is really fun.
nasretdinov
The issue with dynamic languages mostly is that it's sometimes next to impossible to find all references to the code you're refactoring, so you can't just rely on a compiler & tests to ensure that nothing breaks after a change in some core library that everyone uses. Instead you almost have to add some logging into a function you're refactoring, make sure it's not used after you've made the change to a new API, and ideally do that a couple times. It's not too bad when you're the sole developer in a repository, but in the presence of hundreds of feature branches that sometimes can be weeks old, you can't be sure that nothing breaks after your change in the future too. So unless your code can be statically analysed reliably (like in compiled languages) large scale refactoring is a huge pain
layoric
> You can deploy to AWS, Vercel, GCP, Azure, Cloudflare, etc.
It's interesting that this is now and has been the default for quite sometime. I'm still waiting for the pinch to hit where people realize running on these platforms is either really expensive (EC2/RDS), or platform specific ("serverless", Cloudflare workers, lambda, etc).
makeitdouble
TBF it's only expensive if you know how much the alternative costs, and have a reasonable path to switch to it. So for most small shops, it's just a cost of doing business, and they're small enough it doesn't cost astronomical sums yet.
Running an on-premise cluster requires enough expertise that it will mostly be for mature companies, and they'll have completely different priorities when choosing technologies.
MaKey
> Running an on-premise cluster [...]
You don't need a cluster for most things. A simple server managed with Ansible playbooks will take you quite far.
lawn
It's quite telling that running on a regular server isn't in the list.
pacifika
Ultimately code is written for humans first, otherwise we’d all be using assembler. So how readable the code is written matters, and how frictionless it can be managed. A lot of opinions form around that. As Usually “it depends”.
Note I’m not disagreeing with the core of the comment but presenting this as pretence when this is simply the craft until we manage a layer that manages code for us and have opinions on that instead, seems harsh. My 2c anyway.
tonyedgecombe
There are happy paths to follow for many projects. For instance if I was starting a macOS or iOS project I'd need a really good reason not to use Swift.
jwr
I agree with "choose tools that make you happy", I disagree with the implied premise that all "obscure" (not very popular would be a better description) tools have value purely because they make me happy.
I have used (and continue using) many tools and solutions that are not popular. Some of them make me happy, some do not. All of them bring practical advantages.
Not every good tool will become popular, and many popular tools are not good.
jclulow
Yeah I agree with the positive part of the thesis; i.e., that it's alright to like things, and it's alright to pick things in part because you are a feeling sentient person and you should have nice things.
I think the corollary that people, when looking also at the data or at constraints, are acting irrationally or its sophistry or whatever is bunk, though. Plenty of people do actually engage in some amount of evaluation, and it's intellectually lazy to disregard that because they may have also made an aesthetic or otherwise personal decision on some level as well.
I use a bunch of niche software, and it's difficult or impossible to completely separate my aesthetic preferences from the concrete reasons I also have for doing so -- my aesthetic preferences and my joy in using certain things actually stem from those concrete benefits in some cases!
zzo38computer
I believe you that there are practical advantages; often the more popular ones have several problems that are insufficient for what I am trying to do, but sometimes just that there are advantages and disadvantages of different ones and the ones that I like are different. This is true of file formats, character sets, protocols, etc as well as of programs.
> Not every good tool will become popular, and many popular tools are not good.
Yes. (In my opinion, there are also specific kind of features that it has or lacks, that I might think is good even if it is uncommon or bad even if it is common, but there are also features that are good as well as common, or that are bad as well as uncommon.) (However, there is also the consideration of: something might be good for some purpose but bad for others, and might be used for many of the purposes that it is bad for even though there is clearly something better.)
linkage
As with most things, there is a happy medium here. Ditching poetry for the new and shiny uv made my day-to-day experience an order of magnitude better, especially because I had to introduce Python to an existing monorepo. Being able to inline dependencies as Python comments made it possible for a completely non-technical person at my company to run an AI-generated script that used Pandas with just one CLI command. Had we picked poetry, I would have to spend half a day setting up a proper Python environment on his machine.
You can also go too far and pick a JS web framework with 17 users that hasn't been battle-tested in production. You'll then waste time solving problems that have already been solved by users of React/Vue/Svelte instead of shipping working code.
bitwize
I keep using Emacs because without it I do feel like a William Gibson protagonist -- "trying to reach the console that wasn't there" (or M-x or Lisp repl in my case).
Emacs works the way I work, the way I need an editor to work. I recognize that it's a very personal thing and doesn't readily generalize, but it's a bit condescending to imply that all these personal choices are to forge some pretentious cosplay identity. Some of them are just a simple matter of: human need get work done, human brain work best this way, use tools that best support way brain works to get work done.
astral_drama
My first boss at the uni would tease me about my Emacs usage, saying, “It’s an operating system with a text editor tacked on.” I just smiled and loaded up a game of snakes within my Emacs buffer and carried on hacking.
arjvik
It IS an operating system and a pretty solid one at that, just one lacking a good text editor... Thankfully evil mode emulates a really good editor.
:)
tho2342i34234
He's not wrong though - Emacs was meant to replace the MIT lisp-machine/symbolics interface and it does a magnificent work of it.
The things that Emacs allows one to accomplish is quite insane, though, as with all lisp-projects, it also seems to suffer from the "Lisp curse" (which is fine IMO).
bitwize
Emacs was meant to be an extensible text editor.
The standard "great OS, needs decent editor" quip is just that -- a quip. If you look at the actual history of Emacs, you will see that the it was originally a collection of TECO macros. The first Lisp version was written by Dick Greenblatt for Multics -- it was not intended to be an operating system in its own right. The Lisp machines had Emacs versions of their own -- called EINE, ZWEI, and Zmacs. So Emacs was well-established on multiple operating systems before GNU Emacs even came along. You could say that the GNU system as a whole is intended to be a successor to ITS and the Lisp machine OS, but Stallman deliberately chose Unix as a basis because he wanted GNU to be popular and Unix was already widespread in 1983-1984.
In fact, GNU Emacs didn't even get some of its more powerful UI features until the 90s, after Lucid Emacs/XEmacs was developed by Lucid Inc. as a component of their Energize IDE -- they found GNU Emacs at the time to be inadequate from a UI standpoint, so they forked it and added the bits they needed. Most of those were implemented back into GNU Emacs, despite that Stallman thought that, for the most part, they weren't needed.
So no, Emacs wasn't designed to be a software Lisp-machine workstation. It just sort of slowly morphed into one over time.
bitwize
Correction: Multics Emacs was written by Bernie Greenberg, not Dick Greenblatt.
thom
The author is very cleverly using unexamined motivations leading to incorrect conclusions to demonstrate that we shouldn’t allow our unexamined motivations to lead to incorrect conclusions.
neilv
> The general form being: why Obscure Thing is better than Popular Thing. And always the justification is purportedly rational and technical. And always, always, it is complete sophistry.
Is the author scoping the piece, to say that this piece is speaking only of the subset of posts claiming obscure-thing-better-than-popular-thing that are sophistry?
Or is the author asserting that all posts claiming obscure-thing-better-than-popular-thing are sophistry?
skribanto
My interpretation is that as engineers, we attempt to justify all of our choices through purely rational means. However, as humans, we cannot really make said choices without also being at least somewhat influenced by our subjective affections.
Perhaps I'm stretching the author's message, but at least I believe that the argument extends to all engineering conclusions. The author's call is that we acknowledge this subjective side.
Essentially, true engineering is about tradeoffs, there is no X that is objectively better than Y in all circumstances and contexts.
zetalyrae
> The author's call is that we acknowledge this subjective side.
I think that acknowledging the subjective side is a necessary step to making more rational choices. If you don't know your motivations, you will be a motivated reasoner.
When you can add "I like this tech because it helps me build an identity I aspire to" as an item in the pros column, you realize you no longer have to.
neilv
> When you can add "I like this tech because it helps me build an identity I aspire to" as an item in the pros column, you realize you no longer have to.
But, for many of the cases of using-obscure-thing-instead-of-popular-thing, that's not a factor.
Not everything divergent is hipster impulse. Nor is everything about slotting yourself into a clique category in high school.
Which is why I asked for clarification on what was being said.
FWIW, I use a vintage ThinkPad mainly because I can type all day on it without problem. The serviceability is also nice. I also own a sleek high-end last-year's P1 and an X1, both of which I think would look more attractive in cafes and in some ways fit my ideal self-image better than the T520 that I choose to use instead. Currently, due to the inferior keyboards, I might use the P1 or X1 only if I need to do a startup meeting with a 20-something who doesn't already know I'm good despite being over-30. That choice would be the image one, and it's not about validation or aspirational identity, but pragmatic gaining of acceptance despite prejudice.
bitwize
Nine times out of ten, popular thing is going to be objectively better than obscure thing, because it's much easier to find people who know, and tools that work with, popular thing. All other things being equal, the person who launches a startup based on Go or JavaScript is going to have an easier time than the person who launches one based on Common Lisp or Haskell -- unless they do all the coding themself.
If you have some objective, measurable reason for choosing obscure thing over popular thing, by all means -- tell us why. But show receipts. Actual numbers and measurements.
Otherwise, it's all vibes.
zetalyrae
I'm describing the set of posts that jointly satisfy:
- The thesis is "tool X is superior to (Y, Z, ...)" or "X is a modern/practical choice".
- The argument is purported to be technical and rational.
- The arguments are fallacious and do not stand to rational scrutiny.
Where you can reasonably think that the author's actual reasons are affective, and they are trying to make rational arguments by backward-chaining from the conclusion and failing.
Buttons840
If an article is (jointly) written in green font, uses the word "the", and is fallacious and does not stand to rational scrutiny; that article is fallacious and does not stand to rational scrutiny.
MetaMalone
Should we feel happy solving our problems with our fancy tools? Are our tools and in-depth knowledge a distraction to inflate our egos, or a sign of self-respect and passion?
I’m inclined to believe the latter. Our fancy tools provide so much more utility beyond keeping us happy. Our tools teach us new things and stretch our curiosity and creativity. Our happiness stretches us to solve more problems and ask better questions.
skydhash
I just like to use simple tools I understand where I can extend anytimes I like instead of tools that's complex and always morphing whether I like it to or not. Most tools brings in a new thing I may like, while reinventing 95% of things I already use. A truly lateral tool that just bring in something new and useful is rare (LSP in text editors). And most of these are protocol based instead of feature based.
reikonomusha
This is a disappointing article from an author who usually writes excellent works. The article touches on a seedling of truth, but then takes it in a misleading direction. Unfortunately, I don't think this article actually inspires anybody to inquire more carefully or rationally within, but instead provides great thought-terminating ammunition that can be fired at anybody doing something not perceived as popular, ordinary, or boring. (And it's entirely in vogue to do so, with all the Grug Programmer, Use Boring Technology, etc. haranguing these days.)
What I think is true: A person will often hide their true rationale and/or intent of a decision behind a facade of weak, ex post facto objective arguments.
I think the author is absolutely right that it's OK to use something just because it makes you happy. Especially for personal/hobby projects, you don't need to be disingenuous and attempt convince the world that SWI-Prolog was truly the optimal technical choice to build your CRUD web app. Saying "I like Prolog and I built a CRUD web app using it" is perfectly fine. I'm really on board with this intellectual honesty.
Where the author goes off the rails is how he ties this criticism specifically to people who make "obscure" decisions. He does so especially through alienating caricature. The subtext of the article is that if you're not doing something conventional, then avoid being a sophist from the get-go and just say how you really feel: it makes you happy. He doesn't lend any credence whatsoever to the idea that an obscure choice may actually be technically justified.
The reality is that people who choose popular technologies often do so without any good reason either, and they too provide a facade of objective justification. They may not be writing blog posts that offend the author ("Why I Chose Python to Build XYZ") that reach the top of Hacker News, but they are espousing their own weak, ex post facto justifications in settings when their decision is challenged—which is almost inevitable, as their choice of popular technology isn't the only popular technology. They'll manufacture the same load of baloney for their decision in the same way the author's Common Lisper boogeyman does.
I would even make a stronger claim: People decide to use popular technologies because it makes them happy, and this happens far more often in load-bearing situations than the Obscure Weekend Technologists do. Furthermore, popularity serves as a sort of immunity to further technical inquiry.
This has led to far more technical derangement and damage writ large to the field than the weekend APLer writing about why they chose APL for a project, and I think it demands scrutiny the author doesn't offer in the slightest, despite being entirely relevant to his broader criticism.
More subjectively, after reading the article, I just felt the author is sour about something or has some sort of ax to grind. He's no stranger to obscure technologies (ex-Common Lisper; now disavows it) and has even created his own obscure programming language with an obscure Wirthian syntax written in an obscure OCaml. Maybe this article represents an admission of sorts.
pseudony
> I would even make a stronger claim: People decide to use popular technologies because it makes them happy, and this happens far more often in load-bearing situations than the Obscure Weekend Technologists do. Furthermore, popularity serves as a sort of immunity to further technical inquiry
Spot on. Could not have articulated it better if I tried.
I'll add a data point though: https://flownet.com/gat/jpl-lisp.html
From description AND observed results, this is a case where a team was successful in a challenging situation with lisp and then failed to deliver, first with c++, then java - the indistry-standard languages of the day.
rewgs
They had me in the first half, not gonna lie.
But the whole "but actually you only like what you like for superficial reasons" thing lost me. I really dislike essays that create false dichotomies just so that they can purport to know why what you do is bad or wrong.
Can't someone choose a tool for _both_ rational and aesthetic reasons? In fact, isn't that basically the definition of "best?" And by "best" I (hopefully obviously) mean "best for me/you," not "objectively best."
I'm sure the author would take a dig at me: I have a love of Thinkpads of command lines. Regarding the CLI, I won't deny that I love the aesthetic. That's genuinely why I was originally drawn to them. Vain? Silly? Maybe. But I own it, won't deny it, and will never stop loving the aesthetic of a cool ass looking terminal.
However.
Seeing as the author chose to focus on editors, I'll do the same: I have never found an editor that is all together _better_ than neovim. Sure, this is probably still subjective, whatever, but putting aesthetics and feelings and whatever else aside, neovim still always wins for me and it's not even close. The speed, the stability, the power of a well-configured LSP, the navigation afforded by things like fzf and treesitter, the unbelievably rich and forward-thinking plugin community, and so on and so forth, make it come out on top time and time again for me. Many, if not most, of these reasons are rational.
I could say similar things about most of the other apps (cli-based and otherwise, though most are cli-based) that I use, as well.
The author also seems to misunderstand that the so-called "cult" of Emacs might exist for more than just superficial reasons. Perhaps a "cult" formed around it because it's actually really good, or at least addressed a lot of people's problems at a particular time, and groups of people tend to form their own aesthetic? I myself have never jived with Emacs, but I can certainly recognize the power of it -- and, yes, the aesthetic, community, etc -- and I certainly wouldn't dream of shitting on someone's joy of it, especially in a condescending "you actually only like this because you think it looks cool" or "it confirms some aspect of yourself" way.
It's simple: we can, and probably even should, choose tools for both rational and "superficial" reasons. It's perfectly fine, and one aspect does not negate the other.
kstrauser
I agree. I primarily use Emacs, because I think it’s just about the greatest program mankind’s ever developed. Anything you could ever possibly want it to do is already packaged for it. It supports all the features of newer editors (yes, I said all of them). It supports every language known to humanity, and it does it consistently so that if you use it to write Python, you know how to use it to write Rust or Prolog or C.
I don’t use Emacs to be contrary, just like you don’t use Neovim for that reason. We use them because they’re really good.
Joker_vD
Some people can use Emacs for amazing productivity gains, and some just can't, no matter how much they try. The first ones are blessed, the seconds ones are inferior and better to stay away from.
It is Gnostic cult, even if it happens to be true.
zzzeek
There's a major reason people seek to rationalize the tools they use and it's because we all have jobs, and we want to be allowed to use what we want at work. When some other tool comes out and is one that you find highly annoying, that tool is literally a threat to your own personal comfort, lest it become popular enough that your job is making you use it. Which is something that happens to all of us that have software oriented passions and dispassions all the time.
People underestimate how much of software engineering is subjective touchy feely decisions. But really it's just a nature of being in a field with so many possible options and so few hard constraints. You can write your web app/cli in Java, Go, Rust, JavaScript, Ruby, Python, etc, each of them with reasonable justifications. You can deploy to AWS, Vercel, GCP, Azure, Cloudflare, etc. You can use Postgres, Mongo, SQLite, MySQL, etc. Is there any actual evidence that one stack is better than another? No, not really. It's ultimately up to what your brain decides it likes, and then it fills in the arguments post-facto.
It's just that software engineers like to pretend they're fully rational beings and don't go off of subjective reasons like the rest of society.