"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.
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.
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.
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.
C# has them. For instance, interfaces used as generic type constraints are zero cost.
Another thing, some C# abstractions are very low cost. Critically to this thread, Span<T> abstraction is low cost, pretty much the same thing as a pointer+length in C. It's easy to design an abstraction which uses spans of bytes backed by a memory-mapped file, and the performance going to be pretty similar to C.
Depends on what we mean by 'zero cost'. For instance, Interface constraints themselves may not have a 'cost', but there are many cases where this means that the calls involving that generic type will be virtual (unless you're doing fun patterns like 'where TComparer : IEqualityComparer<T>,struct`). If you poke around at the internals of System.Linq you'll see there's a lot of checking to use specialized types depending on the collection in order to minimize costs.
And that's what you'll see a lot of in the .NET Standard bits; even in the past we've had some fairly low cost abstractions in places. SocketAsyncEventArgs, if a little arcane at first is a good design for it's time, and System.Linq.Expressions has been a great way for users to minimize the cost of things like reflection without having to write bytecode.
That said, some abstractions are deceptively costly; the 'new' generic constraint is definitely not zero cost, unless that got fixed in 6.0.
These fun patterns are precisely generic type constraints I mentioned in my comment. I do use them when performance matters, here’s an open-source example: https://github.com/Const-me/Vrmac/blob/1.2/Vrmac/Draw/Main/I... That code is from a 2D vector graphics library, these interface methods may be called at 10 kHz frequency or more. Displays are often 60 Hz, the methods are called couple times for every vector path being rendered.
> If you poke around at the internals of System.Linq you'll see there's a lot of checking to use specialized types depending on the collection in order to minimize costs.
Linq is awesome, but I’m pretty sure it was designed for usability first, performance second. I tend to avoid Linq (and dynamic memory allocations in general; delegates are using the heap) on performance-critical paths. YMMV but in most of the code I write, these performance-critical paths are taking way under 50% of my code bases.
> 'new' generic constraint is definitely not zero cost
If you mean the overhead of Activator.CreateInstance<T> when generic code calls new() with the generic type, I’m not 100% certain but I think it’s fixed now. According to https://source.dot.net/, that standard library method is marked with [Intrinsic] attribute, the runtime and JIT probably have optimizations for value types.
An ISO C certified compiler isn't required to support it.
Two C certified compilers for the same platform are free to provide completely different behaviours for what asm is supposed to do.
Anyone that cares about compilers does actually read ISO documents.
And C has inline assembly. Doesn't mean that most C code will use inline assembly.
Back in 2009, a lot of git utilities were still written in scripting languages. Not sure when it started, but the porting activity of those utilities to C is still ongoing. So the maintainers still want to use a lower level language today.
In other projects in the VCS space, we are seeing a similar trend. Hg, originally a project written in Python, is being rewritten in Rust by Facebook, one of the big users of it.
Sure, maybe you could have used C# together with some niche features. But it's not going to be fun compared to a language that has zero cost abstractions and that runs on the bare metal.
Even if your problem domain demands a managed environment, like extensibility with plugins, I still suggest you to use Rust together with wasm. It's the first choice thanks to its great type system, powerful static analyzer and first class support for resource management that garbage collected languages lack.