No, it is not all that fast after the CGo call marshaling (Rust would need to compile to the C ABI). I would essentially call in to Rust to start the code, run it in its own thread pool and then call into Rust again to stop it. The time to start and stop don't really matter as this is code that runs from minutes to hours and is embarrassingly parallel.
I have no experience with FFI between C and Go, could anyone shed some light on this? They are both natively compiled languages – why would calls between them be much slower than any old function call?
• Go uses its own custom ABI and resizeable stacks, so there's some overhead to switching where the "Go context" must be saved and some things locked.
• Go's goroutines are a kind of preemptive green thread where multiple goroutines share the same OS thread. When calling C, the goroutine scheduler must jump through some hoops to ensure that this caller doesn't stall other goroutines on the same thread.
Calling C code from Go used to be slow, but over the last 10 years much of this overhead has been eliminated. In Go 1.21 (which came with major optimizations), a C call was down to about 40ns [1]. There are now some annotations you can use to further help speed up C calls.
It has great ideas but because of all these conveniences it is very bad for performance based programming making it slower than C#. I like the ideas in Roc language to make functional programming as fast as imperative by controlling allocations in things like closures
It's quite funny to classify it as such, given you need to run your programs like a script as it's nearly impossible to compile a binary you can distribute (though I am aware they're working on this as a priority task, currently).
It’s not always clear what is meant by “system programming”. I’ve begun writing utility scripts in Julia; it’s practical now because the startup time is vastly improved. These can be run like bash scripts, with a shebang line that invokes Julia with the desired environment (using the --project flag).
> It’s not always clear what is meant by “system programming”. I’ve begun writing utility scripts in Julia; it’s practical now because the startup time is vastly improved. These can be run like bash scripts, with a shebang line that invokes Julia with the desired environment (using the --project flag).
I think it is clear enough. The language must have a small or non-existing runtime so it is practical to write systems that do not ship the same fat runtime on every binary. The language must support compiling to binaries, otherwise it really cannot be used by itself for systems. It must provide access to the available Operating System API directly without the need for bindings (to the extent possible, as some OSs only expose the C API;ABI).
What is a system, you may ask. I think you can define that as anything that can run by itself (no runtime) and perform any "low level" operation permitted by the OS.
It's a heavily gamed benchmark, but TechEmpower Fortunes is pretty good at revealing the max throughput of a language runtime for "specially tuned" code (instead of idiomatic code).
I judge more idiomatic / typical code complexity by the length of stack traces in production web app crashes. Enterprise Java apps can produce monstrous traces that are tens of pages long.
ASP.NET Core 9 is a bit worse than ASP.NET Web Forms used to be because of the increased flexibility and async capability, but it's still nowhere near as bad as a typical Java app.
What matters in practical scenarios is that ASP.NET Core is significantly faster than Spring Boot. If you have a team willing to use ActiveJ or Vert.x, you are just as likely have a team willing to customize their C# implementation to produce numbers just as good at web application tasks and much better at something lower level. There are also issues with TechEmpower that make it highly sensitive to specific HW/Kernel/Libraries combination in ways which alter the rankings significantly. .NET team hosts a farm to do their own TechEmpower runs and it just keeps regressing with each new version of Linux kernel (for all entries), despite CPU% going down and throughput improving in separate more isolated ASP.NET Core evaluations. Mind you, the architecture of ASP.NET Core + Kestrel, in my opinion, leaves some performance on the table, and I think Techempower is a decent demonstration of where you can expect the average framework performance to sit at once you start looking at specific popular options most teams use.
No, records are a reduction in boilerplate for regular classes (the result also happens to be read-only — not deeply immutable, mind you). Value types are in the works:
Hmm looking at that it seems like being a struct type is a non-goals they seem to explicitly call out C# value types as a different thing...
Smaller objects from dropping identity is nice but it really doesn't seem like it gives you more explicit memory layout, lifecycle, c interop etc that C# has with their structs. Maybe I'm missing something.
Why do people say Rust follows the tradition of C++? Rust follows very different design decisions than C++ like a different approach to backwards compatibility, it does not tack on one feature on top of another, it is memory safe etc that are very different from C++. If you are just comparing the size of language, there are other complex languages out there like D, Ada etc
> Why do people say Rust follows the tradition of C++?
They mean the domain that Rust is in.
Before Rust there was only C or C++ for real time programming. C++ was an experiment (wildly successful IMO when I left it in 2001) trying to address the shortcomings of C. It turned out that too much of everything was in C++, long compile times, a manual several inches thick, huge executables. Some experiments turned out not to be a good idea (exceptions, multiple inheritance, inheritance from concrete classes....)
Rust is a successor in that sense. It draws on the lessons of C++ and functional programming.
I hope I live long enough to see the next language in this sequence that learns form the mistakes of Rust (there are a few, and it will take some more years to find them all)
Some of C++'s warts are still available in Rust, though, such as long compile times. Additionally it encourages using a lot of dependencies, too, just like npm does.
Anyways, I dislike C++, it is too bloated and I would rather just use C.
It was no experiment at all, it was Bjarne Stroustroup way to never ever repeat his downgrade experience from Simula to BCPL, after he started working at Bell Labs and was originally going to have to write a distributed systems infrastructure in C.
Also there have been alternatives to C and C++, even if they tend to be ignored by most folks.
The one big (and IMHO most problematic) thing that Rust and C++ have in common is the desire to implement important core features via the stdlib instead of new language syntax. Also both C++ and Rust use RAII for 'garbage collection' and the 'zero-cost-abstraction promise' is the same, with the same downsides (low debug-mode runtime performance and high release-mode build times).
While I don’t disagree that there’s a similar desire regarding libraries vs syntax, Rust is also more willing to make things first class language features if there’s a benefit. Enums vs std::variant, for example.
And it's a balance act, both approaches to language design have merit.
That being said, I can't work with std::variant, and God knows I tried to like it. Rust's enums look a lot nicer by comparison, haven't had enough experience to run into potential rough edges which I'm sure are there.
For me the defining feature of C++ are its move semantics. It permeates every corner of your C++ code and affects every decision you make as a C++ developer.
Rust's defining feature is its borrow checker, which solves a similar problem as move semantics, but is more powerful and has saner defaults.
What do you think about Rust for Rustaceans? I read it and there are very niche and useful information there about Rust that I didn't see anywhere. It's a solid book but for a book about programming there are so few real code examples that it can come off dry. I just bought Rust atomic and locks and it seems exercise based, so I'm excited to finish it. The first chapter seems promising
You are right about it not being a beginner friendly book. Hence why I placed it lower in the order of books to study.
Yeah Rust atomics and locks is essential if you truly want to understand low-level concurrency. But you might have to also refer to the C++ std::atomics reference [1] to get a complete idea. It took me a while to grasp those concepts.
reply