You Can Choose Tools That Make You Happy
157 points by oger
157 points by oger
When I see posts that go on and on about how someone did something in some obscure technology or how they have used EMACS to wash the dishes, I always think it’s some kind of rebellion against the fact that a lot of technical choices are not our choices.
If you work for any company, there is usually very mediocre technology that is foisted upon you. If you have a family, maybe you can’t convince them to move to your favourite chat application or to use matrix. Above all the way that we use technology these days is extremely social and the network effects are quite punishing.
Therefore we can assume, that when people make obscure technological choices, it’s the equivalent of hiking in the mountains, to escape a life in the city.
I agree with the author though that we should rationalise it with ourselves, but I think the reason that people don’t do that is because they yearn to bring their friends into the mountains with them
I have noticed that when I get bored with work stuff, my GitHub open source contribution chart lights up in green.
Thank you. This is a beautiful comment.
Being able to make one’s own choices is such a pleasure after a hard day’s work.
I think this is spot on - with the one extension that at least speaking for myself, it is as at least as much a rebellion against the absurdity of the modern-day software world itself. We who pride ourselves on simplicity have built a world of unmanageable complexity, and we live in a world of abstractions so far removed from actual computers that the self-parodying “half gig TODO app in Electron” isn’t just a joke.
More personally: A few years ago, I made my peace with the main thrust of OP: Many of my tech preferences aren’t based on rational analyses at all, but on aesthetics. I love Lisp; I’ve spent an enormous amount of my time writing various hacks in Lisp (and a whole bunch of ill-fated personal Lisp implementations). But the reason I love Lisp, if I’m being completely honest with myself, is that it feels great in my brain, in a way other languages and programming environments don’t. I don’t think it’s a “secret weapon”, I don’t think it will rise from the ashes and become the next big thing, and I especially don’t think everyone should use Lisp for everything. Most of the great technical elements of Lisp have been integrated into other languages - and since it seems like people who like Lisp are a distinct minority, I’m perfectly willing to concede that “Lisp feels great in my brain” might be saying more about my brain than it does about Lisp.
Even if there might be only 7 people in the world who’d even want to go with me on my particular mountain hikes, that has to be enough - I think those are 7 people whose company I’d appreciate a lot more than that of 200.000 random LinkedIn users.
That makes sense as to why I don’t find it as interesting. My family does use my preferred chat applications, for example.
Maybe I still find the technology interesting, but I don’t have to go far away to enjoy it. It is possible.
There’s an equally dangerous mental trap, though: writing off all seemingly-contrarian technology choices as examples of this.
Exactly so. Choosing the tool that “everyone uses” because everyone uses it is a profoundly misguided and dangerous move.
The software industry really desperately needs proper controlled trials of different tools to find ways to quantify and then measure the claimed costs and benefits. As it is, Ken Olsen was right after all: it is all snake oil. It’s nothing but medicine men claiming that their patent brand languages, editors, OSes, frameworks, etc. will fix your problems.
And all of them have happy customers who come forwards and say “yes, I bought this, I used it and now I feel better.” And we have no numbers for who lived, who died, who did get better but didn’t feel it, who felt better but wasn’t, and so on.
Scientific progress is about measurement, trials, and falsification. The software world almost totally lacks this.
Scientific progress is about measurement, trials, and falsification. The software world almost totally lacks this.
So much of the world is lacking this, not just software.
So much of the world is lacking this, not just software.
Very true, and a global tragedy that keeps spiralling.
If people exercised critical thinking, there’d be no “alternative medicine” industry, Brexit wouldn’t have happened, and much more.
Cf.
If you’re trying to hire people who use it, using things everyone uses is a pretty big advantage.
It can also be a fantastic “secret weapon” to use more obscure technology. Most people using such tech off the beaten path are intrinsically motivated and often experts. This makes hiring both easier and harder- it’s easier to find qualified people because the rabble isn’t even interested in your company. It’s also great for employee retention, as there isn’t much competition. But of course it’s also harder to find people in a pinch.
Yup, I get a lot of recruitment emails and seeing more interesting tech makes me take a second glance.
A recruiter’s job isn’t to hire you, it’s to hire someone who can fill a position. If there’s 20 of those for every one of you, they’re likely to succeed anyway. If there’s only you and you’re happy at your current position, they have a problem.
It’s not so easy to attract talent, especially if you’re a mid-sized company with an extremely dull SAAS solution. So you can either offer a higher salary, which you might not afford, or maybe something else that is hard for tech talent to get elsewhere.
If you’re trying to hire people who use it
There is a big preconception, an assumption, in that question which I’d like to spell out.
It’s a valid one and a very common position, indeed in much of industry it is the default position, but it’s a flawed one, and I think this is a relevant consideration.
What if you aren’t looking to hire? What if you can’t hire anyone? What if there’s no money, time, space, kit budget, whatever?
What if you could but you have reasons for not wanting to hire people? What if the goal is not volume or excellence or scale? For instance, the primary goal is producing an excellent product or service and you don’t want to hire people to do it?
To spell this out, here are some perfectly valid alternative approaches:
There are dozens and dozens of possible reasons why you might not want to hire people. Or you do, but you want to weed out the smartest and most flexible, where obscure tools are a valid way to do it. Or you want to but can’t.
Etc. etc.
The “if” here is operative, I didn’t ask a question, or make a blanket statent or assumption about your situation. I made a conditional statement. The statement “If it is raining, then the streets are wet” is true even when it’s not raining.
If any of those things are true, then you’re not trying to hire people who use it, and the associated advantage doesn’t weigh anything to you. That doesn’t mean the statement is false or somehow flawed or that the associated advantage weighs nothing to everyone. It makes it not apply to your situation.
Yes, I got that. As well as being a native English speaker, and a professional writer and editor, I’m also a TEFL teacher.
But at least half of the points I made addressed this specific condition.
If you are not trying to hire people, a statement predicated on wanting to hire people doesnt apply to you…
You seem to equate “wants to hire people” with “wants to hire lots of people” which implies “from the largest pool of available labour”. There are also people who want to hire, say, a very small number of the best developers they can find, in any language.
Or, for example, you may have a language that is de facto unique to your company and so you know that you can’t hire anyone who knows it – such as, for example, Morgan Stanley’s A+ language – so you want to hire talented developers who know multiple languages and train them in your special in house one. That happened to my friend Jonathan, a former Perl developer.
Or, to pick another personal example, my ex-fiancée, who became a Smalltalk developer, but was hired as a bright graduate with good IT skills but they did not hire developers because they wanted the fresh mindset of non-programmers.
You seem to me to be holding a common fallacy which is all to often accepted as a universal truth, and the more exceptions to it I point out, the more strenuously deny that they apply… rather than recognising that your generalisation is false.
No, the entire software development industry does not run on lowest-common-denominator stuff like Unix, Windows, C and Javascript.
Lots of important lucrative sectors are doing very well thanks specifically by avoiding that.
I’m not equating that, i’ve said nothing to that effect. My initial predicate was “if you’re trying to hire people who use it” and you keep bringing situations where the predicate is false. There’s no fallacy here unless you add things to my thesis that I knowingly left out.
Again, “if it is raining, then the streets are wet” is a true statement on a sunny day.
I appreciate all the situatioms in which it isn’t raining, some of them are new to me and interesting, but i’m not engaging with a fallacy. Us continuing to talk past eachother like this isn’t productive or fun, I’m out, sorry.
I think this usually a wrong assumption for many reasons:
The last thing is a personal experience that I had a couple of times now. Sometimes using that big famous project makes you assume that the obvious things have been done and “that you can’t be the first one with this problem”. Yet time and time again I’ve witnessed that. In the last couple of years I was surprised time and time again about Rails for example, which I’d argue is the famous choice. I won’t go into details, but things like how bigint wasn’t the default until recently, how UUIDs were pretty uncommon, badly supported, how enums were really weird, and PGenums not really supported, etc.
This is also true for companies and products where I learned that a decade later they finally implemented what was common place for every competitor.
And usually for more obscure tech the barrier of upstreaming something you depend on is much lower. Both because of how projects are structured in terms of signing off a change and because of how since these projects are often smaller there might be fewer technical restrictions, things to work around, also the target moves slower so you don’t end up always having to adapt for whatever internal API changes happen.
I’m not sure how much a scientific approach really helps (or is applicable) when choosing a framework, language, or library. Evaluation criteria should be defined, and a benchmark can be useful, but more often than not many technologies will be strong choices.
Most of us work on relatively straightforward problems where there’s a wide range of viable options; and no single best one. In those cases, “quality” often becomes subjective, shaped by personal preference or team context. That’s what fuels the industry’s constant cycles of trends, whether it’s tools, languages, or architectures. Remember when microservices were the only “serious” choice for any company, regardless of size?
I am just boggling with utter astonishment at this.
There is a vast contradiction between:
I’m not sure how much a scientific approach really helps
and
a wide range of viable options; and no single best one
But the point is there is no way to know.
Maybe there is, but without measurement, you don’t know. You can’t know.
Wouldn’t you want to know?!
There’s some truth there but otherwise it seems largely like a “you shouldn’t use technologies I do not like” post.
Every technology choice once was difficult to justify before it was popular, and someone always put in the work to make it an undeniably good choice. For many technologies it took many years before they became “the future” — like UNIX was considered an OS for people who couldn’t afford mainframes, until it became the de facto standard OS design (for better or worse).
Don’t tell your boss it was a rational cost-benefit calculation that made you rewrite the frontend in Prolog. Above all, do not lie to yourself. Examine your motivations. If you pursue things out of pure obsession, and ignore reason, you might wake up and realize you’ve spent years labouring in obscurity on a dead-end.
It would be very easy to justify Silverlight to yourself and your boss back when it was heavily pushed by Microsoft. It came from a megacorp. It allowed using more languages than Flash, which was limited to ActionScript. It felt less obsolete than Java applets.
But now we know that it would have been a short-sighted choice that would require a complete rewrite, while Prolog transpiled to JS would continue to work.
I’m a maintainer of a project whose original authors chose to use “well-established” Perl instead of a “new-fangled” language like Python — exactly at the time of Python’s meteoric rise. You can say that my idea to fork and rescue the project because I used and liked it was irrational and I should have just switched to something else — a lot of people were saying that at the time.
In the hindsight, I’m sure someone may now see me as a “visionary” who correctly devised a years-long “strangler fig” rewrite project and correctly guessed that a failed project was worth rescuing. But hindsight is always 20/20. I could have been a guy who burnt himself out for nothing.
Because people make technical decisions, in part, for affective reasons. They choose a technology because it feels good, or comfortable, or because it’s what they know
“Because it’s what they know” is, arguably, why people started writing server-side web application code in JS. Asynchronous event-driven server existed in different languages and there’s nothing special about JS that makes it better-suited for that model. Node.js became so wildly popular because it allowed people to do that in a language they already knew from frontend development.
They choose obsolete languages, like Lisp or Smalltalk, because they think of the heroic age of Xerox PARC, and they want to feel connected to that tradition.
Any statement about a “Lisp” is completely meaningless without saying which language they mean. In 2010, would Clojure be obsolete because it was a Lisp or too unproven because it was too new (created in 2007)? ;)
(I could use Fennel but picked Clojure because I know it did get a non-zero industry adoption)
They find tools whose vibes align with theirs: Ada says “slow, conservative, baroque” while Rust says “fast-paced, unproven, parvenu”
I wonder what makes them think Ada “says” that. I really don’t know why anyone would described a project that strives for design consistency as “baroque” — maybe because they don’t actually know the language? Do they know Ada has a built-in formal verification tool since 2012?
Don’t look me in the eye and tell me SNOBOL is the language of the future.
Python had been an incredibly obscure thing from a little-known research organization until it became one of the most popular languages. Ruby was a completely unknown language for a decade until the efforts of Ruby on Rails authors and some outspoken early adopters propelled it to fame. In 2002, this could read “don’t tell me Ruby is the language of the future”. Then in a few years, using the formerly-obscure Ruby would be easily justified with “everyone is using it”.
The arguments for the Obscure Thing downplay the downsides (“yeah I had to take a six-month detour to implement an HTTP server for Fortran 2023”)
Someone had to write the first HTTP server in every language. Writing the HTTP server in Ruby that allowed RoR to serve pages is vindicated by history now. It was no different from writing an HTTP server in Fortran 2023 today.
Also, run fact: Fortran of any edition can be trivially linked with any older code. You can take an HTTP server in Fortran 77 and integrate it in your project. The greatest difficulty is importing it from a deck of punch cards.
It doesn’t have to be you, of course. For example, I have oddly warm feelings towards StandardML but never use it in practice precisely because I can get the same benefits from OCaml without having to be the one to create the libs I need from scratch. But for every technology, someone has to be the one to write the first web server and there’s no way around that.
Emacs is a Gnostic cult. And you know what? That’s fine. In fact, it’s great.
Without a definition of a “Gnostic cult” in relation to editors, this is a completely meaningless statement. Is the author implying that using Emacs is never a rational choice? I could argue that choosing a tool that offers very modest resource consumption and exceptional stability is a very rational choice if that tool allows one to be productive. Some people don’t like Emacs (I’m not a big fan, although I occasionally used it for some modes), and that’s fine.
But to say that not liking Emacs is rational while not liking the corporate IDE of the day is irrational doesn’t seem… rational. Emacs has already outlived dozens of those. For a corporate-backed product, I’m sure that alone would make people call it a success.
While I feel that the original article contains unnecessary hyperbole, I think the core message is: “Be honest towards yourself about your reasons”. And in my opinion that message is important; and I would extend it with “also, be honest towards others about your reasons”.
So if I write an HTTP server for Fortran 2023 because I think that Fortran might become the next Ruby, then sure, I should tell others about that reason, and I can expound on the virtues and great outlook of Fortran! But if I write that server only because I like a challenge, then I should equally honest say “Look, I know (or am pretty sure) that Fortran will not get any more popular, but I like the challenge”. That honesty also makes it easier for others to assess the viability of Fortran.
I don’t think anyone who writes something like a web server in Brainfuck for CP/M (or similar technology that clearly has no future — unmaintained, inherently obsolete due to being unusable in any modern environment, or never intended for production use) tries to present it as anything else than an intellectual challenge.
The post mostly attacks a specific class of tools — well-established and actively maintained but niche.
I’ve seen a lot more motivation honesty problems with new and heavily promoted tools than with those. If someone wants to use a framework of the day that has been making rounds on social media and collected a few thousands GitHub stars (mostly from people who starred it without using it first) but is really just a minor variation of an already popular approach, I think there’s a pretty good chance that they are just curious about it or, worse, just want it in their CV as a bargaining chip for their next job. But who ever admits that?
If someone says they are using BSD on their laptops or servers because they disagree with design decision of Linux or oppose the Linux monoculture, what is it that makes it more likely that they don’t actually think BSD deserves to be more popular? Same goes for Smalltalk and Common Lisp — both have actively maintained implementations, and unlike a fresh framework, are unlikely to break the compatibility or become unmaintained soon.
If anything, Fortran is absolutely massive in number crunching applications. LAPACK, pretty much the library for systems of linear equations is in Fortran 90 and “how fast can it execute LAPACK?” is the benchmark of the TOP500 supercomputer list. One of the reasons is that the industry invested enormous efforts in making Fortran compilers fast that that application, and keeping them compatible with older standards to allow reusing a large number of libs accumulated over decades[1]. There’s nothing especially good for fixed-point financial calculations in it, but at least a tax reporting program in Fortran will continue to work for years to come.
[1] Rumor has it that one of the reasons for that investment is that the software involved in the US nuclear arsenal stewardship is in Fortran and rewriting it in Julia or NumPy or anything else isn’t an option because the nuclear weapon test ban makes it impossible to verify the correctness of any possible replacement by blowing up a nuclear charge and measuring the explosion parameters. If true, that ensures that Fortran compilers will keep getting better as long as nuclear tests remain banned.
I don’t think it is attacking a specific class of tools though. As the title says, “you can choose tools that make you happy”. My reading of the article is that it’s attacking made-up justifications for choosing tools, while still suggesting that it’s completely valid to use those tools.
Bear in mind that the author says that people choose Rust because of vibes, or that Emacs is a gnostic cult, as a Rust and Emacs user (at least based on their previous posts). Honestly, as someone with my fair share of quirky tool preferences, I agree with them - I don’t have solid, good, well-evidenced reasons for choosing most of those preferences, it’s largely just vibes and feeling. I like Rust and well-typed languages, and I’d even go so far as to assert that I write better code in those languages, but I have no evidence that that’s the case. Hell, there’s no even really any evidence that statically typed languages improve correctness or programming speed (although it’s more a lack of evidence either way rather than evidence to disprove that idea).
It might help to reread the article, but with the assumption that the author themself uses all the technologies that they’re talking about. I don’t think that’s true for all the things they mention, but it’s true for some of them, and I think it gives a better sense of the point the author is making.
I don’t think it is attacking a specific class of tools though.
I don’t know if it was the intent, but almost all examples belong to that category, and the assumption that everyone who uses them does so for irrational reasons doesn’t help at all.
like the guy who uses NetBSD on a ThinkPad to feel like a William Gibson protagonist
ThinkPads are still made, NetBSD maintainers made a release past December. I’d understand it is said “NetBSD on a SparcBook” or “NetBSD on a PPC MacBook” because neither is made and NetBSD is one of the few OSes that still supports those platforms. But it mentions two readily available things, even if both are niche. And ThinkPads aren’t even that niche, they are in every computer store.
obsolete languages, like Lisp or Smalltalk, because they think of the heroic age of Xerox PARC, and they want to feel connected to that tradition
Squeak had its last release in 2022, more mainstream Pharo had a major release past week. Pharo is partially funded by INRIA. It’s certainly not obsolete in the same sense as Miranda or Algol 68 that don’t have still-maintained implementations.
“Smalltalk shouldn’t be more popular” is an opinion one is certainly entitled to, but there are people who clearly think it should be, else they wouldn’t be approving funding for it, however modest that funding is. Same holds for any “Lisp”.
Put ZFS in your air fryer,
ZFS for Linux is an unusual choice compared to LVM or Btrfs because you need to go out of your way to install it(on air fryers or any other devices), but on FreeBSD or Solaris where it comes from, it’s the default choice and it’s frictionless.
Should FreeBSD with its ZFS be more popular? I make a point to ensure that all my software works on BSDs, even though I was on the Linux side of the flamewars all along and havee no reason to be emotionally attached to BSDs — I just think that portability matters and monocultures are inherently dangerous.
do your taxes in Fortran
We already went through this elsewhere, and I’m willing to give the author the benefit of the doubt, but I’m not sure i
You use Tails because it’s cyberpunk?
So, do Tails maintainers work on it “because it’s cyberpunk”? Are only its users irrational?
write a novel on a Gemini
I’m not sure why the author chose to link to a Wikipedia page instead of the manufacturer’s website. When I red the post, I didn’t check that link and assumed he was talking about the Gemini protocol. I didn’t know about Gemini PDAs but they actually do look pretty cool.
That PDA is readily available for ordering and they are making new models. It runs mainstream Android or standard Linux distros. If the author’s logic is that one can buy a high-end Android phone from Google or Samsung for rational reasons but the choice to use a device from Planet Computers cannot be rational, I don’t understand that logic.
take pictures for your LiveJournal
I don’t know if the author knows that LiveJournal was purchased by a russian state-controlled company, with all that entails. LiveJournal was certainly popular with people opposed to the government, although it was also just popular in those parts in general as well. Whether to be able to censor dissent was the ultimate goal of that acquisition from the start is debatable but the outcome is clear. Sticking with LiveJournal when it means being subject to an oppressive regime would indeed be quite irrational. But I don’t know if the author realizes that it’s not a “white dwarf” social media service that remains technically alive after losing its mainstream popularity.
I’m mildly surprised that example is not the Fediverse — these days it’s what lots of people say no one has a rational reason to use, despite the actually growing numbers of users.
on a 2003 digital camera. Move the family groupchat to Signal
Why a 2003 digital camera is juxtaposed with an actively developed project as if they were somehow equivalent?
Dial into standup from an ISDN payphone and tell your PM the feds are after you
I suspect this may be a fundamental misunderstanding of ISDN of payphones, of both. How exactly a payphone (a booth with a phone inside it that people can use for a fee) makes calls remains hidden from its user, since it doesn’t offer a way to connect your own device.
Don’t look me in the eye and tell me SNOBOL is the language of the future.
The only actually obsolete example (no active implementations).
So, the article is to some extent pretty close to describing me - and I don’t really feel attacked. My daily laptop is a Thinkpad X2100 (a Chinese-made replacement motherboard for the Thinkpad X200), complete with a ton of ports (many of which I’ll never ever use, like the VGA port), a rear-mounted battery and heft. It’s bulky and matte black; it looks about as far from a sharp, stylish modern Macbook as a laptop can get.
I could come up with some technical arguments for why I love the X2100, and they’d all be true. The keyboard is great; it’s of much higher quality than most modern laptops (including Lenovo’s own). I have 64 GB of RAM in it, and it has more user-serviceable parts than pretty much anything this side of a Framework. But if I’m being brutally honest with myself, that’s not why I have it. I have it because, well, it makes me happy. I like how it looks, I like how the keyboard feels, and I can’t rule out that there’s a bit of me that likes it because I like being the kind of person who uses a Chinese-made refurb of a clunky laptop from a time gone by - which is arguably just one step removed from “wanting to feel like a William Gibson character” (note: not the protagonist; his protagonists tend to be his dullest characters). It’s certainly closer to the author’s statement to “make your life a work of art” than it is to Rational Consumer Behaviour.
As I mentioned a bit upthread, I love Lisp (I lean towards Scheme more than CL) … and that is mainly for reasons that have nothing to do with calculated, rational choices and everything to do with the fact that Lisp feels great in my brain. I can also come up with a bunch of technical reasons for why I like the Lisps - and they’d also all be correct, but many of them would be moot because the elements I like most have been absorbed by other languages. Once again, if I’m being brutally honest, I like Lisp because there’s something about its “technical aesthetic” I enjoy a lot, and it is perfectly fine to choose technology that you enjoy. I’m not going to claim that there’s a Lisp renaissance right around the corner (there might be, but I don’t think there is), and I’m especially not going to try wedging Lisp into my day job as an embedded Linux developer.
Perhaps I’ve misunderstood the article, but I don’t really read it as attacking the technical merits of eg. ZFS, emacs, Signal, Lisp and Smalltalk (or even SNOBOL), but pointing out that some use of those are made from a position that isn’t about technical merits. I don’t even think the author is claiming that this is “irrational” (eg. counter to logic and reason), more that it is “nonrational” (eg. choices made for other reasons than logic and reason) … and that it is perfectly OK to make technical choices that aren’t about technical merit. I don’t think many would argue that it is not OK to make technical choices based on ethics - the article, as I read it, is making the point that it is also OK to make technical choices based on aesthetics - but that we should at least be honest when we’re doing so. Less “Smalltalk shouldn’t be more popular”, more “Smalltalk’s popularity has nothing to do with its industrial viability”.
Consider Picotron. It’s a cool little Lua-based fantasy workstation that will never supplant actual workstations, and deliberately has restricted capabilities that makes it unsuitable for lots of the sorts of things you’d want to use a modern workstation for. But it’s actively developed, and people don’t just use it, they pay money for it … and if we’re all being honest here, that’s because using it and developing on it is a fun nerd pastime, not because anybody expects that it’ll be the Next Big Thing. It’s perfectly OK to enjoy things for their own sake.
PS: My chats with family are in fact on Signal! The reason we all agreed on was “Mark Zuckerberg is a monster and his company shouldn’t exist” - which also has nothing to do with the technical merits of either Signal or Facebook Messenger. Even if the latter was technically superior in every way, I’d prefer to not use it.
I don’t really read it as attacking the technical merits of eg. ZFS, emacs, Signal, Lisp and Smalltalk (or even SNOBOL), but pointing out that some use of those are made from a position that isn’t about technical merits
I think the article is quite unambigious at least when it comes to SNOBOL and Prolog as a frontend development language.
Just don’t bullshit me. Don’t look me in the eye and tell me SNOBOL is the language of the future. Don’t tell your boss it was a rational cost-benefit calculation that made you rewrite the frontend in Prolog.
I can’t see how it can mean anything but:
authors’ previous post starts with “I recently wrapped up a job where I spent the last two years writing the backend of a B2B SaaS product in Rust” apparently that didn’t spark joy
A B2B SaaS Product is not exactly the kind of project one works on when looking for joy :)
This is one of my frustrations with interactions IRL.
Sometimes I’ll have discussions with coworkers next to the coffee machine, and we end up talking about how I solve $problem at home (either with my desktop setup, my homelab or with my 3D printer) Often, folks will start going, “why?” and then proceed to review my solution like this is some work project, and I don’t know how to politely say “I just want to do it this way, and unless you suggest a way that I, me personally, like more, I don’t give a shit about how you would do it.”
So far, I’m just saying: “I’m not saying you should do it this way, I’m saying, I, me, solved it this way.”
I sometimes feel that people tend to judge a lot what other people do on their free time. If someone wants to re-write Tensorflow in OCaml, who am I to judge. I believe that the journey is more interesting than the goal, and I look forward to read what they have to say about their endevour.
Something I’ve seen on Mastodon, about “why didn’t you include blah blah blah”:
oh, I wrote this using my brain, not yours
I find “Why didn’t you…” is frequently a bad format for feedback. It makes the suggestion sound obvious. I try to use “did you consider…” or “did you try…”. I feel like it asserts less and comes off better. It can still be awkward to provide feedback in a non-judgemental way when you don’t understand how the person came into a particular situation.
Sometimes I’ll have discussions with coworkers next to the coffee machine, and we end up talking about how I solve $problem at home (either with my desktop setup, my homelab or with my 3D printer) Often, folks will start going, “why?” and then proceed to review my solution like this is some work project, and I don’t know how to politely say “I just want to do it this way, and unless you suggest a way that I, me personally, like more, I don’t give a shit about how you would do it.”
And sometimes I’m in such discussions where a friend gives his reasons for his complicated home setup, and I don’t know how to politely say “these reasons don’t make sense at all; why don’t you say right away that you do this because it’s fun?”. Other people admit to this right from the start; and for me those are much better discussions, because the premise (“let’s have fun”) is made clear.
“Is there an end goal to this, or is it just for fun?”
I would always ask to clarify. Can’t blame someone for not knowing the precise context others have.
It feels like this article was made as a counter to the famous blog post about Lisp from the orange site’s creator god (for those not in the know, the title is “Beating the Averages”). I remember reading that post — if you will believe it — as assigned reading for a course and it always rubbed me the wrong way. Though OP’s article comes off a little strong, it resonates much more with me.
The orange god attributes his success to the esoteric “AI and research language” and then frames an entire essay off of the premise. But… is that really true? Wouldn’t it be more parsimonious to say that maybe orange god was just smart? Or at least smarter than his competitors? Or lucky? Whatever the contribution Lisp had to his success, his post did not make me believe it was the singular reason.
But maybe I’m not smart enough to understand why.
Yeah, had the same article come to mind.
Since Beating the Average was published, there seems to be little correlation between choice of language and success. Etsy and Facebook used PHP, Twitter became popular while on Rails, Netflix use a JVM stack, Google was built on C++. And Paul Graham was coding before Stack Overflow, before open source package repository, before modern IDE and automated refactoring. Maybe in 1996 the programming language mattered a lot, but today the ecosystem is king.
Plus Viacom was an internet startup in the 90s. Come on. The weather on the day they met with Yahoo! could have had more impact on their success than their choice of language. It was mostly luck that helped them. Cool that they used lisp but you can’t generalize from a sample of n = 1 taken from an era of exciting new frontier technology that hasn’t been figured out yet.
That article always rubbed me the wrong way too.
I haven’t seen that essay brought up in a long time – surprised you had to read it for a course!
But I think if you look at the history, it’s pretty easy to understand
So basically “Ruby and Python are acceptable Lisps” – they are dynamic languages with convenient data structures and GC.
As far as making the kind of companies they make, there is probably no difference between Ruby/Python and Lisp
In 2004, PG wrote “the Python paradox” - https://paulgraham.com/pypar.html
which basically confirms that
Yes PG often writes without nuance and comes off as arrogant
But the core of the argument is basically true, for that world, if you read it with the language landscape of the time in mind …
I think the problem is that the context is not necessarily in the essay itself – it comes off as a bunch of absolute statements. He does play the trick of appearing to seem measured and dispassionate, but also throwing in some real zingers / turns of phrase that piss people off, to generate discussion / controversy
I make a living maintaining Perl code bases (the “dead language” since mid 2000s), using Emacs. I use Docker, though. When I started programming, I got immensely sad using Eclipse IDE, but I survived, and it made me stronger. My bosses do not care what text editor I use, they probably think it’s VSCode, or maybe they use Emacs or Vim themselves.
For me it’s more a choice of simple tools, than a religion. I spend less than 5 minutes a month configuring Emacs (I actually hate writing Elisp and my Emacs config must be less than a few hundred lines after 20 years of experiments). I barely use autocompletion nor AI. I use print statements a lot, or I dump objects with a fancy dumper, I really dump a lot.
I change my hardware every 5-7 years, use microphones and headphones that have cables. I think Makefiles are great, not only for programmers.
My life is so beautiful <3
Sometimes it’s true, sure, but this:
the justification is purportedly rational and technical. And always, always, it is complete sophistry
is tosh.
Ada says “slow, conservative, baroque” while Rust says “fast-paced, unproven, parvenu”
Where such descriptions are generally accepted as being reasonable, that’s not because people who use them want to seem as though they embrace those properties, but because the languages actually have properties which can be described in those ways. Some people do use them for the appearance, sure, but some people use them because Ada is conservative and Rust is less so, and to say everyone who uses them does so purely to seem that way is ill-considered at best.
The fact that the author thinks that all people who use anything other than mainstream technologies (or anything, really) do so only out of affectation or for other vainglorious reasons says a lot more about the author than it does about the people described - i.e. that they assume everyone is the same as they are, and so ascribes their motivations to everyone else. The fact that they need to shout about it in a ranty blog post makes it seem like they’re trying to get others to join in so they can feel better about it.
Just don’t bullshit me … Examine your motivations.
Yeah, how about you try a bit of self-reflection.
It’s the bell curve meme, with “I use this tool because it makes me happy” on the edges and something laden with should directives in the middle.
The best parts of tech are building things with tech I like, iterating on it with people I like, and solving problems for people.
The comment section is just noise. I, like others, get sucked into these tool discussions all the time. It’s natural, it’s easy, and the Internet excels at it because it is engaging, and much, much easier than talking about actually doing the work, which is nuanced and not as suited for Internet Points.
This post got me triggered, it feels like a personal vendetta against me lmao, in my defense, I do not use Emacs nor make a living with Haskell because they make me happy, but because they offer the least frustrating experience out of the existing options while carrying out my duties, I often joke that I hate Haskell for not being perfect, so I’m not happy with it, still frustrated on the sad state of the software industry, but I could see my situation being worse if PHP/Java/JS/etc were forced upon me.
Meanwhile, Emacs and (neo)Vim specifically are the only editors that make sense to use as a programmer, it’s a very natural and quite frankly the most logical decision, as a software developer you want an editor you can modify, change and program to your liking, taking it to the extreme is as if a NASCAR driver took uber everywhere when not in a race, a cheff always taking food delivery at their home, or a builder hiring some contractor to carry out some modifications in his home he could easily do himself. Why would I want an editor that does not help me to change it easily/fast and move on with what I was doing without having to create a whole project structure for the simplest change I need in my tools? We’re always building custom tailored software solutions, the editor should also be customized for the task at hand, Emacs/Vim are just frameworks to build my own.
Your post reminded me of this https://blog.glyph.im/2008/12/emacs-test.html which reasonates with me (and lots of Emacs users for sure) on why we still use Emacs.
IMHO using a tech stack because “it’s what everyone else is using” is way worse, I could see how that’d lead to a title post “You can choose tools that everyone else uses since you shouldn’t care about your profession, never explore anything else, let’s follow fashion.”.
I’ve been an Emacs user since about ‘07 after switching from Vim. It was only in the last few years that I started using “GUI” Emacs… up until probably 2021 it was always in a terminal. I’ve tried other tools and every time I do I get frustrated and go back to Emacs as quick as I can.
Meanwhile, Emacs and (neo)Vim specifically are the only editors that make sense to use as a programmer
That is almost certainly overstating the case. I love Emacs. You love Emacs. Lots of people… don’t. IntelliJ, for example, is a fantastic editor for Java and friends. I have lots of colleagues who are fabulously productive with VSCode. Visual Studio is actually pretty darned good for working with the .NET languages. Could you make Emacs into a good .NET IDE? Probably could, using a bunch of LSP stuff and writing some ELisp glue to hold it all together.
My setup is pretty customized and it feels nice and cozy for me. But… lots of people have no interest in customizing their editor and much prefer to be able to just sit down and do stuff without thinking about it too much.
Org-mode is a great example too. I love org-mode. I’ve used it a ton. But I recently switched to Obsidian for note-taking with a paid plan because it fits my workflow better. It’s not as customizable, but I can really easily access it from my phone or iPad. I’ve also used org-mode for literate programming/code notebooks but these days I mostly use Jupyter because it’s so easy to just run jupyter lab and have a notebook that I can share with a colleague by giving them a Tailscale URL.
I used to make the mistake of thinking “people who don’t like the tools I love are being irrational”. Now it’s more “if you ask what I use I’ll happily rave about it but… you do you and let me do me.”
Fair, I abstained from mentioning it earlier, but I could see my self using Jetbrains IDEs, they are so good and I won’t hold anything against someone that uses a real IDE, the only reason I don’t use an IDE is because I gain nothing from switching at this point. Almost 16 years ago, when I started to use Vim (and then Emacs about 9 years ago) was because I just couldn’t use any other without my crappy school computer getting bogged down, I was a student, I didn’t have the money to buy decent equipment, a teacher revealed CLI editors to me and got me out of my misery of doing Java in notepad, after a few weeks of nano I forced myself to learn the Vim way, I did not enjoy it but I had no choice, it felt overly complicated, but in hindsight totally worth it. Nowadays, as you mention, I prefer to be able to just sit down and get to work without thinking about tinkering too much, Emacs Doom does that for me, I decide to stay with Emacs because my muscle memory it’s already there which I won’t throw away for anything subpar. Times have changed, while many others have reconfigured their editors all the way from sublime text, atom, brackets, …. all the way up to zed, Emacs has stayed the same, and it’s still the better tool (for me).
It’s funny you mention the muscle memory thing… over the years I have flip flopped between OSX and Linux laptops depending on what I’m doing (eg current $JOB standardized on Word for documentation and PowerPoint for presentations so OSX it is). One of the things that I find so embarrassing for Linux desktop environments is how inconsistent the hotkeys are while OSX has essentially Emacs-compatible hotkeys everywhere. C-a, C-e, all of that stuff works in pretty much any application that uses native widgets and also in most places in Electron-based apps. It’s so frustrating going to Linux, hitting C-a, and having a whole screen of text get selected instead of just moving to the start of the line.
I forgot to ask, and I’m sorry if I sound like a preacher or an annoying salesman, but did you consider org-roam before your switch to Obsidian? I know at least one person who did the opposite switch and haven’t heard complaints from him. I guess having a fleshed out product that specifically fits your workflow is better, but Emacs also gives you options to achieve the same; ofc you’ll have to invest time and resort to 3rd party tools for diagrams or mobile sharing, but as a benefit you always stay in control. I understand that may not appeal to everyone, though. All in all, I must confess I don’t do any fancy note-taking myself; org-mode is enough for my needs, however, I’ve considered once or twice whether a Zettlekasten + Org-Roam approach would be worth embracing. I’m curious on your perspective in case you tried it but ended up discarding it.
Also, know it is possible to export org documents to Jupyter notebooks, I guess the problem comes when non Emacs users try to contribute to the notebook (and even then, there’s almost always a way).
On another note, there’s also an argument where people know that they could do better using X or Y, but they decide against it, I have in mind quite a few acquaintances that refuse to leave make, sublime text or qwerty behind even though they know there’s something objectively better out there, to each his own for sure.
Not at all an annoying salesman or preacher! I would absolutely love to go back to org-mode being what I use every day but… this the kicker that I’m talking about when I say workflow:
I can really easily access it from my phone or iPad
This has always been the problem with Org-mode for me and if Org-roam does solve it… the documentation doesn’t do a very good job of explaining how. I often only take an iPad to meetings instead of my laptop. I also often do field work with a Windows laptop. The problem that Obsidian solves for me that Org-mode doesn’t very well on its own is: how can I access my notes from any device?
I’ve tried Mobile Org (https://mobileorg.github.io/documentation/) but it’s pretty limited as far as what it supports and doesn’t support. When I was a heavy org-mode user and was using it for scheduling and task management I put a fair bit of time into creating custom task states and transitions, agenda filters that let me see my different clients, etc. and Mobile Org didn’t support any of it. I do pretty math-heavy work on a regular basis and used the Org-mode LaTeX functionality quite a bit… totally unsupported last time I tried Mobile org.
I actually don’t love Obsidian. Markdown makes me itchy, pasting screenshots into notes is weird. I often keep a debugging log while I’m working through problems and its fixed-width text blocks are too narrow and wrap text in a way that makes it tough to read. But the ability to access my notes from every device I use (including excellent off-line sync so I can review and work on things on a flight) is an absolute killer app for me. When I was using org-mode religiously I also carried a paper notebook around with me all the time so that I could capture notes when i wasn’t near a computer; with Obsidian I can just make notes on my phone and they’ll be waiting for me on my laptop when I open it up.
I have in mind quite a few acquaintances that refuse to leave make, sublime text or qwerty
I’ll bite. I left Sublime behind (well Textmate…) but still use make and qwerty every day :). Similar to why I love Obsidian (I can use it anywhere), I have decided not to put the effort into learning a keyboard layout other than qwerty because… any given machine I sit down at to do something with is going to have a qwerty keyboard that I can use without messing around. And make… I spend most of the day writing C and C++ code. Admittedly I don’t often use bare Makefiles on anything but the simplest projects, it’s usually CMake generating Makefiles but… it works and it’s everywhere. It’s pretty great to be able to take a project, git clone it onto a fresh embedded Linux install (day-to-day work), run make and have it build and run without needing to dig around and figure out which apt packages I need to install beyond build-essential and cmake. No Python dependencies to worry about, no Java dependencies to worry about, it’ll work the same on an Ubuntu 18.04 build and a 24.04 build (yay embedded systems based on 7 year old distros…)
there’s something objectively better out there
One of the things I do on a regular basis at work is trade studies, looking at different options for hardware modules and software libraries. There’s almost never something that is objectively better. We look at a bunch of different aspects, assign weights to those aspects, and try to evaluate the different options using a weighted sum. My weighting might be different than your weighting. The options that come out as the winner will highly depend on the weights. To make it really interesting, we will often do this as a team:
As a team we debate and come up with the different criteria that we care about. As an example for an embedded processor module we might have: Cost, BSP quality, size, weight, performance, supply chain availability, schematic availability, presence of JTAG/SWD, etc.
Individually we assign weights to the different criteria. Some people care more about certain factors and others care about different ones. We blind the weights.
Individually we then assign a score of 1-5 for each criteria and then come together and try to find consensus on those scores. This is usually pretty easy and it surprises me how often we are all +/-1 on each before getting together and doing this.
The big finale, we unblind everyones weights, multiply the scores for each option by the weights, and see how things shake out. This is usually where the most debate happens. While everyone tends to agree pretty close on the scores for each criteria, there is often pretty wild divergence in the weights. Sometimes even with the divergent weights there are one or two clear winners and we just have to pick one; sometimes there isn’t even a clear ranking and we need to spend more time trying to get some convergence in the weights. We’ve had situations where the team was divided: half had a certain option ranked first and half had the same option ranked last. Ultimately we do need to make a decision to move the project forward but… we’re all aware that the outcome wasn’t necessarily objective but it is defensible.
Edit: one last thing… along with build-essential and cmake, I do also always apt install tmux and emacs-nox :D
they offer the least frustrating experience out of the existing options while carrying out my duties
My colleagues routinely have to fight with VSCode and plugins and at least once a month somebody ends up uninstalling and reinstalling it or even having to go so far as rebuilding their Windows desktop to get back to a working environment. As an Emacs user, I don’t. Windows is a means to launch Putty and XMing. I was dragged, pretty much kicking and screaming, from VisualAge and JBuilder by colleagues over twenty years ago and after a while it stuck (Android Studio and XCode are, however, the least friction for mobile). Even if you totaled all the time I tried packages and fiddled with versions over the years I spent less time hacking on my environment than my current colleagues do right now.
Yes totally! I can offer another example; I know of people that routinely have to re-install their Linux distro or surgically fix it after an update upstream broke them, bad drivers, changed something they shouldn’t have touched, or whatever. Even at work, I’m forced to use Ubuntu, and I’ve been bitten by this on more than one occasion, having to lose a couple days of work. Meanwhile, my NixOS systems have been solid, even the few times when something has gone awry, I’m just a rollback away to be back in a working state, I’ve got a NixOS user friend that hasn’t re-installed since 2021 when her first got into it, I would’ve a longer streak if I didn’t have my computer stolen last year.
So OP may consider NixOS an obscure technology, and again happiness is not why I use it, it really is more convenient! (for me).
re-install their Linux distro or surgically fix it after an update upstream broke them
As an OpenSUSE Tumbleweed/Slowroll preferrer, I get this 😅 I’ve also had pain recently with Guix that, somehow, were poorly vetted upstream. It happens.
You mean we don’t have to write everything in Typescript?
Laughed at this, as I spent about a year trying to like the TS ecosystem. It has some good stuff in there (Astro, Svelte, Kysely) and a lot of stuff that…isn’t my favorite to use.
Nobody ever got fired for using big words to disparage those who dared to pick something other than Java, I guess.
Related, somewhat less angry and more funny post: https://lobste.rs/s/z8jvte/static_types_are_for_perfectionists
As I’ve said then, while emotional stuff is rightfully a big part of the effect here, it’s not the only one. Context is another major part: nothing is better than the other thing in general, there are pokes where benefits of unconventional decision top “better is different, different is worse”.
Another case is when you can see the future. Back in 2015, it was clear that Rust represents the biggest advancement in industrial languages since Java popularized managed safe reasonably-fast languages, and that, while it was likely that the language would just die, if it didn’t, it would be absolutely massive.
This things are necessary probabilistic in nature, but it doesn’t mean that you can’t have rational judgements about probabilities.
Even though I agree with the sentiment that you should use whatever tool or tech that makes you happy and don’t need to justify yourself, I find the tone in the article quite condescending as if the people making those choices need to be making it just cause vibes/feelings/aesthetics. How the author frames things as undead, gnostic, etc, gives me the ick. If they don’t like a given technology for whatever means, that doesn’t mean they should be talking people who do down as if their decisions are just emotional and thus somewhat less than what the author believes to be correct.
Probably related to the author himself being an Emacs Rust user made him feel free to express that way, while he may have come to the conclusion that using obscure technology makes him feel happy, he surely did the mistake of projecting that onto others, happiness is not why I use Emacs (and others) for sure.
Above all, do not lie to yourself. Examine your motivations. If you pursue things out of pure obsession, and ignore reason, you might wake up and realize you’ve spent years labouring in obscurity on a dead-end.
I’d agree.
Emacs is a Gnostic cult. And you know what? That’s fine. In fact, it’s great. It makes you happy, what else is needed? You are allowed to use weird, obscure, inconvenient, obsolescent, undead things if it makes you happy. We are all going to die. If you’re lucky you get three gigaseconds and you’re up. Do what you are called to do. Put ZFS in your air fryer, do your taxes in Fortran.
I wouldn’t use Fortran. But I see many reasons to prefer Emacs over VS Code (although I also believe that most programmers should use the latter), and occasionally find the need to use ZFS on random laptops. Not all uses of Emacs/ZFS/etc are because of pure obsession, yet this Story seems to frame it this way (especially for Emacs — unclear what they mean for ZFS, imo).
Docker is too complex
Tried for two weeks and still couldn’t wrap my mind around it. Being too complex could be a dealbreaker for me, and that is the case for Docker (unless if specific benefits outweigh the costs in a specific application).
I think we (the technical community) is missing the point here, from both sides of the discussion.
It stands to reason that people do things because they like doing them. This cuts both ways, however, and you’re just as likely (or even more likely) to keep that language, ide, and toolchain from last year, adding on to it some new gizmo that you think you’d like instead of starting over, or just kicking around with some language you think is fun.
And therein lies the rub: it’s not that Ada is better than Javascript and React, or that LISP’s language features made programming more fun and concise or whatnot. If that’s all there was, we’re just having a big discussion around chocolate versus strawberry ice cream. You have your way, I have my way. That’s not a bad discussion, but there’s no end to it.
There’s a bigger question you get to when you learn your 8th or 9th language: ok, I like it better, but I’m always like that. What actually makes it better ten years from now? Who cares? As long as I’m getting paid, is there really any good, defensible reason to do things one way or the other? These things are endless.
When I first learned YAGNI and TDD/BDD (You Ain’t Going to Need It and Test/Behavior Driven Development), it helped clear my mind about what code structures to use and helped me understand what’s going on under the hood. You don’t have to use these things if you don’t want. I found them useful – so useful, in fact, that I “picked them up” and applied them in all sorts of other technology contexts.
My lesson is that if these are applied in a rigorous manner, and it is counterintuitive and very difficult to do this, these problems all go away. It’s not the language or platform. There are lessons to be learned here that will be true 100, 1000 years from now. I don’t care what kind of stuff you like or are forced to use. There is a rigorous way to determine this that has nothing to do with personal opinion. I’m done. I never need to address this again. (Aside from being over-caffeineated one morning and typing in huge comments on lobsters)
That’s my journey. Good luck in your own.
The only way you are happy using digital technology is when you are completely at peace with eternal breakage everywhere.
Nice post. This applies to me, for sure.
I’ve reflected on why I’m passionate about obscure technology such as self hosting, NixOS, Emacs, Signal, tiling window managers, and in a past life, Haskell. I think I’m overly (?) sensitive to tools that break my expectations, and thus like to have control of my environment.
If this overly sensitiveness is a part of me, then high control tools (even if obscure) might still be reasonable. But perhaps I could afford to desensitive myself by accepting pragmatic-but-annoying software.
I have been working on doing that. I have mixed feelings on having spent so much time on it. At the least it has led to a fruitful career.
Professionally, I’m more pragmatic, and pick tech to fit the team/problem, rather than my quirks.
The opposite is more common. People use the thing everyone or some big company users because it must be good (and not marketing, etc.). No technical reason whatsoever.
God must exist because so many people belly it
It goes further. People believing that somehow Google, Amazon and Facebook magically don’t have bugs, never have downtimes, never have security incidents, magically have superhuman developers or SREs, etc.
And if course then any tech and any tech product by then is magically great and superior in every area, cause while there is pros and cons for others, the magic bands of Google made Kubeenetes the perfect thing for everything and how could we ever have lived without it. People not using it simply use faith and intellect.
(sarcasm of course)
A great example of this is how every tool even before telling you what it does and often instead of why it’s good tells you who uses it. And it doesn’t matter if it’s some tiny team nobody at the big corporation had heard about or whenever it was just some quick test it must be on the “trusted by…” list.
Oddly, I am both an Emacs user and a Gnostic. It’s not for nothing that we say that any editor can save your files, but only Emacs can save your soul.
I like this. I actually describe my decision to use Rust on a particular project as “I had a hammer” (and everything becomes a nail). That is, I had sound technical reasons to use it (the performance aspect was important), but I also really wanted to! Luckily for me it worked out very well.
Use tools that make you feel empowered. https://blog.startifact.com/posts/empowering-languages/
Rust is definitely one of the hammer-iest tools out there! Once you get used to it on projects where the performance and the whole “system”-ness of it matter a lot, you start running out of reasons to use “higher level” languages in other projects that don’t have any such demands. Because you don’t even remember how Rack and WSGI and Express and whatever work anymore, while the crate ecosystem is right there so you just do cargo new and cargo add axum …
Huh. Is there a guide you recommend for Python and golang users to adopt rust?
I don’t know of any such thing myself. I think reading the official Rust book (and perhaps supplementary material, I liked the “Programming Rust” book) is helpful. And trying it out on hobby projects. But I don’t have any particular perspective coming from Python (and I never used golang).
Most people say this about people using Scala or Elixir or Clojure, but all his examples are patently ridiculous, and I’ve never seen them. “Frontend in Prolog”? “an HTTP server for Fortran”?
If you see this, name names! But I think he’s lampooning one thing by pretending it’s something else. I even agree with the greater point of “do your taxes in Fortran if it makes you happy,” but if you think someone pointing out JVM features around scheduling vs. Python’s when advocating for Clojure on the job, that they’re just full of shit and chasing dopamine… I think that’s dumb.
Additionally, I think most people choose conventional stacks for similar “joy-based, fake rationalization” (i.e. full of shit) reasons they don’t admit. Literally every Elixir dev I’ve worked with knew Elixir better than 99% of Python devs I’ve worked with knew Python. And to his point, yeah, it’s all good, use whatever. But I think the fans of both conventional and obscure tech avoid having conversations on technical merits (or expending thought into trying to define them at all, or how much they even matter in the program getting written) and would rather minimize the other side.
Very well written and resonates with me a lot.
We have recently started work on large-ish rewrite/migration/clean up at work and I have talked to others about how there are “no correct choices” in programming. All choices are driven by some personal bias or preferences and the current circumstances.
I still have some (thinking) work until I have this thought fully formed for myself, perhaps then I should write it as a short blog post.
Choose tools that make you happy, as long as it’s not something in a professional setting, otherwise the risk of finding someone new to take on maintenance for said technology erodes over time as tastes evolve.
This is so funny, loved it! Also never read the Neal Stephenson essay before and I really enjoying it as well.
one of the things i like about odin is that instead of “it’s better”, its creator often justifies it by saying it aligns with how he likes to program (i haven’t used the language, or even looked at its feature set)
my biggest reason for avoiding both C++ and rust is that they don’t spark joy. i tend to default to C# for “real” work, and C for hobby stuff these days, mostly because i enjoy using them. though there are technical reasons to avoid both, depending on the project
if i need to do a lot of low level stuff, C# becomes cumbersome. if the project gets large, or needs to connect to the internet, keeping C safe and segfault-free starts to be more painful than fun