Is there a term for this phenomena yet?
"if another language is being discussed, Rust must be forced into the discussion, no matter how tenuous the connection"
"if another language is being discussed, Rust must be forced into the discussion, no matter how tenuous the connection"
That being said, GP seems to imply that Rust should be the default choice for basically every problem, which goes way too far. Not every application needs this kind of low-level control. Maybe even most don't (although I look forward to a future where it's easy to drop into Rust from a managed language when you hit a performance wall; I think this has been mostly achieved for Python, but not yet for other languages). But some do, and it sure sounds like Git's one of them.
The memory layout will simply leak into the program architecture and will have to be altered on refactors — something which is transparent with managed languages.
The trend seems to go away from high level languages in the VCS space. Developer time is one of the most expensive resources that FANG pays for, so any kind investment in performance improvements is going to pay off quite well.
Rustrusion
This is the natural order of things and is good.
And the proper term for introducing Rust should be “oxidation”.
We could use some perspective from, say, Ada programmers. Unfortunately, none of them ever seem to show up.
Akin's Laws of Spacecraft Design are appropriate here:
> 20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.
I stand summoned.
> Unfortunately, none of them ever seem to show up.
We do from time to time, but people assume our language is dead (it isn't). I learned it last year and I've been very impressed by how simple it is, given the speed you get with it.
It was a "big language" at the time, but now it's a language smaller than Rust or C++ which offers good performance with straightforward syntax. Ada also has a package manager now which includes toolchain install.
Ada has inline assembly, easy usage of compiler intrinsics, dead-simple binding to C, built-in multi-tasking (which includes CPU pinning), a good standard library, RAII, and real honest-to-goodness built-in, not-null-terminated strings. It's a compiled language, so you get good speed in general, but the built-in concurrency really does help work which can be split up. Ada 202x is getting even finer grained parallelism (parallel for-loops) in the language itself to even further help this.
And/or a lot of misconceptions. I showed up many times as well with those links, and explanations and whatnot.
I recommend https://blog.adacore.com/, too. Ada/SPARK is great when you want formal verification, and your checks to be done by GNATprove; statically, instead of dynamically. FWIW, you can disable runtime checks in Ada.
I also commented https://docs.adacore.com/live/wave/spark2014/html/spark2014_... not too long ago. The whole documentation is useful anyway. You can prove the absence of memory leaks, among a lot of other stuff!
I've tried too. I have an article about some of these:
- https://pyjarrett.github.io/programming-with-ada/clearing-th...
I've written a few tools for myself, including a command line code discover tool for large code bases (tens of millions of lines). There's a bunch of embedded work being done with it.
Make sure you use "Ada" rather than "ADA". Some people might give you trouble about it--it's not an acronym, just a name :)
Small sample statistics, but three or four times now I have re-written Rust in Nim and the Nim ran faster. Once you can do inline assembly/intrinsics in a PL, most "real world" benchmarks reduce to a measure of dev patience/time/energy not the language. They also become "multi-language" solutions (if you count SIMD asm as a language which I think one should). Even slow Python allows C/Cython modules which in the real world are absolutely fair game, and you can call SIMD intrinsics from Cython pretty easily, too. Since we have few ways to quantify dev patience/attention objectively, these "my PL is faster than yours" discussions are usually pretty pointless.
Rust's primary language feature - the borrow checker - is about adding compile-time checks on resource management(mainly memory), and the original article talks about boxed vs. value types being a major source of inefficiency.
So talking about Rust in a comparison of C and Java mentioning memory indirection bottlenecks seems about the most relevant place to discuss it.
I would expect to see Java, C#, C, C++, and Rust mentioned quite a bit in the threads here. It's all relevant.
The truth is Rust is an amazing language, with its own warts (async, Pin, etc.), but there is pent up demand for language that fits its description. Non-manual, non-GC low level oriented language. It's not a wonder some projects are switching to Rust
The point is that the issue does not involve people discussing "modern languages", just mindlessly shoehorning references to Rust into any discussion involving any application of a language which is not Rust.
I get Rust fanboys are excited about their hobby, but this sort of obsessive "when the only tool you have is a hammer" discussion is very tiring and fruitless, and only conveys a poor image of Rust's community.
No, you really don't. If you read the thread you're commenting on, you'll notice it's about C#.
The very first comment of the thread you're discussing in, and also the top post of this discussion, is, and I quote:
> It is quite interesting that most of the problems mentioned don't exist in recent version of C# on .NET Core, considering all the similarities of C# and Java. (...)
And somehow Rust fanboys parachute into the discussion to yet again talk about their hammer handling all nails and nail-like problems.
Rust is exactly as relevant here as any of those other items, but people are getting really upset about the Rust mention.
I think in a discussion that already started by comparing different performance characteristics in different languages in a VCS, it's not at all out of line to bring up the fact that another VCS is being rewritten into any particular language. It seems to me that the anti-Rust sentiment is far more disruptive and off-topic here than the mention of Rust in the first place was.