I wrote an article about the growing trend toward compiled languages in programming. I thought that you all might enjoy reading it. See:
5 Likes
Nice article! I liked the in-depth introduction on how this trend is driven by the diminishing returns in hardware-land. To me that was a novel perspective.
It really makes sense that diminishing "free" performance from the CPU-bakers makes the focus on software performance bigger again. I also appreciate the excursion to the huge-scale users, where a "2%" performance loss means they need to buy another €3,000,000 in servers. Again, for them the trade-offs are far more in the direction of more-efficient-software. Good catch!
I disagree with one of your basic notions later on though: "the amount of extra mental work the language requires", of ownership and lifetimes.
To me this has never been a penalty that rust imposes, but a complexity inherent in the problems we try to solve
After two years of learning rust, I've summarised it for myself like this:
"writing a Rust program is harder than writing a C program, but writing a correct Rust program is far easier than debugging incorrect C".
It's the 80-20 principle; where C (Or python, or java or....) allows you to get 80% of the results with 20% of the effort, but then you start running into edge-cases... and error-handling... and subtle race conditions... and off-by-one errors... and leap-year bugs... and then malloc returns null and and and....
Those last 20% suddenly cost 80% of the effort, so most people don't bother and just tolerate the buggy software.
The same applies to dynamic languages: 95% of the time, their abstractions take work out of your hands, but those 5% of the time you need the control, it is magnitudes harder to figure out what the problem is.
Example: A colleague of mine has a python program that analyses genomic data. He goes through gigabytes of data, but only in megabyte-sized chunks. somehow, the program ends up consuming 100+ GB of RAM, but it shouldn't... Where are we leaking that memory? Python makes it very hard to see this, and suddenly that "nice, simple" managed language requires him to use cprofile and gdb to debug.. That's NOT the complexity level that he signed up for.
Rust, in my opinion, makes you pay the "edge-case" cost up front, so that the first 20% of the work also cost 20% of work (so more expensive/less productive than C), but the last 20% of the work still only costs 20% (so FAR cheaper than C).
To close on a positive note: I appreciated the discussion on the popularity trends of programming languages: I do indeed find it fascinating that there's apparently a block of "entrenched" languages that never moves out of the top-10, and a "moving" set of languages that come and go.
I'm really curious to see if Rust has made it into "entrenched" territory in the next decade!
7 Likes
Thanks for writing the article. I agree with almost all of it.
I had a conversation with collegues at work where I was the only one arguing for fast lower level languages because of the end of Moores law. They made good points that languages such as Java are fast enough in a lot of cases, calling out to C++ could be used for the performance bottlenecks and that parallel processing was finally getting more popular.
Only small sections of programs are performance hogs, and at the moment, I feel the best solution would be C# (which has a painless FFI, and is a nice productive language) with Rust for the lower level parts. I haven't actually tried this combination yet -- just C# and C which worked quite well together even with threading and all kinds of crazyness.
Of course the perfect solution would be to be as productive in Rust as in VM-based or scripting languages, although for me personally, thats a long time off in the future if its possible at all.
1 Like
Interesting! This article made me want an article on the problems the semiconductor industry has had moving from DUV to EUV. Are they really building 10nm features with 193nm wavelengths?? Wow, that sounds interesting.
Oh and small typo s/dorm runs/dorm rooms.
Thank you for sharing!
I haven't used Rust enough to be able to observe the benefits of the extra mental load it imposes on the programmer. A number of people have made similar observations as you that Rust cuts down on the non-obvious bugs that bedevil programmers, so the extra time it takes to write code in Rust is worth it. I don't have any real reason to learn Rust, since we use PHP and JavaScript at my work, but I have enjoyed the mental challenge of trying to get the language to compile. I suspect that you have to write a serious program before Rust starts to pay dividends. So far I have only written a few simple programs to experiment with the language and test how fast it executes. It is definitely the hardest language that I have tried to learn, but that is partly because there aren't any good books yet to learn the language.
Thanks for catching the typo. I fixed it in the article.
I see what you mean, php/js is quite a different background!
I don't use PHP myself (Java/Groovy/Perl/Python here, and now slowly Rust), but rust's story for server backends has gotten quite good with server-crates like "hyper", "Iron", "nickel" or "rocket".
If you have the mental capacity to work with/around all of PHP's many, many quirks and oddities, I'm certain you can master Rust as well. What I like about Rust is how all it's concepts integrate so nicely with eachother, it feels like a coherent language, rather than a "mixed bag of features" like PHP always seemed to me.
The obvious downside is that one can only "get" Rust after you've wrapped your brain around multiple concepts, whereas PHP you can learn-as-you-go. The reward is that Rust will let you think/work at a far higher level, with both more performance and more abstraction/power
I agree with you on lack-of-books. Mostly because the language is still so young.
I will add that the rust-book is great thanks to Carols10Cents and Steve Klabnik, their effort really shows!
Maybe also this is something for you: "Why Rust" (O'Reilly free eBook).
I'll also add that I learnt a lot of rust by reading a few specific blogs, such as:
https://llogiq.github.io/ (Llogiq's blog)
http://blog.burntsushi.net/ (BurntSushi)
Baby Steps (Niko Matsakis).