Years ago, this was almost exactly my experience at my first software job, a large Rails monolith in the Ruby-on-Rails heyday. Obviously I was inexperienced, but aside from that, the application code itself was so hard to understand that I was seriously considering whether I was cut out for professional software development. It was just impossible to tell where things were defined, where data was coming from, when things were actually executing, etc.
It was only after working on other projects in other languages (Clojure, Java, Scala, Nodejs, Elixir, Rust) that I started to realize that maybe not all languages lead to teams writing code that is this difficult to follow.
People always say "oh, you can write terrible code in any language", and while this is true, it's a tautology. It doesn't actually tell you anything useful. I now think there is actually a pretty large spread in what kinds of code the various languages/frameworks encourage people to write. I'm not saying it guarantees what kind of code people will write, but, just for example, there absolutely is a difference between what the average Clojure programmer will write and what the average Java programmer will write.
If all of the various languages and frameworks and libraries all just ended up with the same effort producing the same results, no one would ever make anything new, because it would be pointless to do so.
> [A]side from that, the application code itself was so hard to understand that I was seriously considering whether I was cut out for professional software development. It was just impossible to tell where things were defined, where data was coming from, when things were actually executing, etc.
If the enormous pile of Ruby projects that I and the folks I work with at $DAYJOB had been the things I was required to work on and maintain at my first dayjob, I would have (no joke) left the field to go become a lawyer.
I'm so, so, so glad that I started off with C++ and got to work at a couple of C++ shops which got me to understand in my bones the importance of good tests and comprehensible-to-a-mere-mortal code.
> ...there absolutely is a difference between what the average Clojure programmer will write and what the average Java programmer will write.
Oh yeah, definitely. After being worn down by the many years I've burned at my current position, I've become VERY skeptical of the "Let's use $LANGUAGE_OR_TOOL because it will make it easy to hire!" argument. The quality of the stuff that the average user of that tool produces matters A TON.
> I sometimes wonder why we don't see ruby used for shell stuff more often.
The reason we don't see Ruby used more for shell stuff is because Python won this particular war. It's already installed on basically every Linux distribution out there, and this simple fact outweighs all other language considerations for probably >95% of people who are writing shell scripts in something that isn't Bash.
Personally, I don't much like Python, and even though Ruby is not my favorite language either, I find it much better than Python for this kind of work. But I don't get to decide how Debian builds their infrastructure, so in the end, I tend to use Python.
Yes, Python won the war, which is a pity. Linux distributions started getting bloated at the same time they switched to Python for everything. Yum hanging inexplicably and such things never occurred before.
The BSDs do not have this problem (yet!). I hope they stay sane and keep using Perl/sh.
this whole argument is silly. In my time on this site, I have seen someone suggest that every language is good for shell scripting including C.
Python and bash are used in the real world most often because convincing your sysadmin/infra/boss guy to install ruby for one script is a hard sell when you already have good-enough tools built into the system that don't add risk/complexity.
If a client has certified a specific Linux distro as an approved platform, that's what we use.
We can either deliver a single executable (Go) or a Python script, as python is preinstalled on their distro.
If we'd want to use Ruby, it'd be a huge hassle of re-certifying crap and bureauracy and approvals and in that time we'd have the Python solution already running.
Without a root account or inclusion in sudoers list, quite hard. There's millions of people that don't control the machines they work and spend most time with.
Depends on you, your team, your target hardware/os, your project, and many other factors. Considering all of those things, the hurdle of installation might just be too large for it to be worth it.
It's not. This is a non-issue. Every web shop is writing bash to twiddle a build script on servers they also manage, which includes the ability to install any package they want.
Mitigating the risk of downloading a script from the internet and executing it
-- even from a "trusted" website or package manager -- is absolutely a good reason not to use it.
Any decent distro has it. So you don't need to execute any random scripts, just install it or prepare the image with it for your OS install. That's it.
I don't really get this whole defaults being a blocker for tools choice.
I never started using python, ruby or node because all of them were a pain to use for me - this was 7-8 years ago, so maybe it has changed a lot. But even 2-3 years ago I had lots of issues just running one python project. Module, not module, pip or not...
Way too confusing, compared to go for example. Or hell, even Java/Kotlin when you use an IDE and it autoconfigures most things.
You need to introduce a build and release process then to do this then which still detracts from it being simple or the selling point being it's already installed.
Python ships with venv support. It’s not that difficult to bootstrap a venv before running your script, and that’s only if you actually need tooling other than stdlib, which you probably don’t.
There are plenty of ways to have the venv automatically activate (and de-activate) when you enter/leave the directory for the project. direnv [0], mise [1], or various shell hooks.
There are useful libraries, I’m not saying there aren’t. I just dislike it when people include one as a dependency when they really didn’t need it.
Pretty sure I’ve made exactly the same mistake. I feel like everyone who ever writes concurrent code learns that lesson at some point. It’s absolutely astonishing how much mileage one can get out of thread-per-core-fed-by-work-queues architectures.
The source code for Task is very readable but also kind of subtle, and makes for a good study. I would say definitely give it a shot to trace the flow from Task.async[0] to Task.await[1] to Task.Supervised.start_link[2] to Task.Supervised.reply[3]. There is some subtle interplay with regard to waiting for messages/timeouts and process links.
I can’t second this enough. I never knew him personally but hung out around him at a few Erlang conferences and he was always incredibly kind and giving. He never knew it but he had a huge impact on me as an engineer.
Briefly, the tradeoff that Erlang and its independent process heaps model make is that garbage collection (and execution in general) occurs per-process. In practical terms, this means you have lots of little garbage collections and much fewer "large" (think "full OS process heap") collections.
This provides value in a few ways:
- conceptually: it is very simple. i.e., the garbage collection of one process is not logically tied to the garbage collection of another.
- practically: it lends itself well to low-latency operations, where the garbage collection of one process is able to happen concurrently to the the normal operation of another process.
Please note that I am not claiming this model is superior to any other. That is of course situational. I am just trying to be informative.
It was only after working on other projects in other languages (Clojure, Java, Scala, Nodejs, Elixir, Rust) that I started to realize that maybe not all languages lead to teams writing code that is this difficult to follow.
People always say "oh, you can write terrible code in any language", and while this is true, it's a tautology. It doesn't actually tell you anything useful. I now think there is actually a pretty large spread in what kinds of code the various languages/frameworks encourage people to write. I'm not saying it guarantees what kind of code people will write, but, just for example, there absolutely is a difference between what the average Clojure programmer will write and what the average Java programmer will write.
If all of the various languages and frameworks and libraries all just ended up with the same effort producing the same results, no one would ever make anything new, because it would be pointless to do so.
reply