211–220 of 256 posts
I love writing Rust, but I was really surprised by how difficult it was to find a job _actually_ writing Rust. I'm happy to see the increased activity in the space, but searching for a job in Rust is probably still 10x harder than C or C++. It worked out in the end, and I'm happy to be getting paid to be writing Rust every day, but I hope that the market for Rust jobs continues to grow -- ideally even faster than it…
There are tons of Rust jobs in blockchain.
Earlier quoted context omitted.
- Native interop in Java is surprisingly slow and very clunky (C# interop with C/C++ can be as cheap as direct calls nowadays) - .NET had been able to produce single-file (and self-contained when needed) executables way before NativeAOT was introduced - RPi is a fairly large platform compared to e.g. Arduino (for which Rust should be awesome) and can be well-served by NativeAOT ( today ). I might still use Rust for t…
Java also has had possibility to do AOT since around 2000, the difference being that unlike NGEN, it was only available in commercial compilers like Excelsior JET, Aonix, and many others. PTC, Aicas and microEJ are still around, placing Java in hardware that .NET will never be, even with Meadows. Panama main goal is to replace JNI performance warts, while Java / ART has had mechanisms to do fast interop (@FastNative…
Do you have references that say otherwise? (I know you don't, it has JNI level of performance)
p.s.: you have to be insane to use Java today on those listed platforms, which are much better served by C and now Rust. RPi is as small as it gets and on that I'd rather never touch any Java tooling because liking it is literal Stockholm syndrome - it is as low bar as it gets and almost anything else is better.
p.p.s: for anyone's interested, here's the JEP for Panama: https://openjdk.org/jeps/424 do give it a read, then look at C# spans and interop API and ask yourself whether you want to look again at Panama without gouging your eyes out.
Earlier quoted context omitted.
I feel like this could be a great in depth blog post...unless such a blog post already exists? It would greatly benefit novices and those who haven't gotten to that stage where this mentality kicks in.
There's a pretty good YouTube video I saw pulling all the types of strings in rust. I find it confusing still... Been wanting to do a few things that would mean dealing with it streams that could be cp437 or utt8, generally and haven't been quite sure how I want to deal with it.
Earlier quoted context omitted.
Java also has had possibility to do AOT since around 2000, the difference being that unlike NGEN, it was only available in commercial compilers like Excelsior JET, Aonix, and many others. PTC, Aicas and microEJ are still around, placing Java in hardware that .NET will never be, even with Meadows. Panama main goal is to replace JNI performance warts, while Java / ART has had mechanisms to do fast interop (@FastNative…
Panama appears to be solving the abysmal UX of JNI but puts the final performance nowhere near close .NET (without even measuring direct P/Invokes which are literal direct C calls if you statically link AOT binary). Do you have references that say otherwise? (I know you don't, it has JNI level of performance) p.s.: you have to be insane to use Java today on those listed platforms, which are much better served by C an…
I do agree Panama UX could be much better.
Earlier quoted context omitted.
We acquired a product last year, where the entire back-end was written in Rust. Unfortunately, Rust developers were hard to get by, and we didn't have any internally that could maintain the Rust code at such scale. The entire back-end ended up being re-written.
Why not just learn rust? It really is not that exotic to learn. I doubt it is faster to rewrite it.
Earlier quoted context omitted.
That’s not technically accurate. While both JIT/ILC and GC are implemented in C++, the former might have as well been written in any other language which would impact the time to JIT/AOT compile the code (startup time) but not the final product. Pretty much all performance-sensitive code is written in C#.
> Pretty much all performance-sensitive code is written in C#. I think you’re exaggerating things a lot here. The JIT/ILC and the GC are hugely important, complex, core pieces of C#. The performance of the entire .NET ecosystem is rooted in the well written (and well performing) runtime and GC. And there’s not a lot of languages those pieces could be written in. That’s the sort of niche in which rust shines, enabling…
- Metadata representation: type system, reflection
- JIT compiler
- PAL: low-level platform-specific code and interaction with kernel APIs that are mostly consumed by the JIT and GC themselves
- Garbage Collector
- Special features: string interning, threadlocals, ThreadPool, assembly (un)loading and reflection emit, etc.
Only some of the above is written in C++, mostly JIT, GC, and parts of type system facilities.
This contrasted with CoreLib (like C stdlib) which includes code for everything else:
- Primitives (string, int, long, etc., they are partially or fully special-cased by compiler for layout purposes, good example to see how it works - ZeroSharp)
- What you usually see in standard library like APIs for working with strings, file and network IO, math, etc.
CoreLib is written in pure C#.
My issue is with "C++ making C# run fast" which is not the case - the compiler does, and the goal it achieves can be done in most other languages which would only impact the time to JIT the code which would only impact the startup time and not the performance of the compiled C# code.
To give a better example, some features have been historically written in C++ but later on were rewritten in C# for either NativeAOT, which does extra compilation work (also written in C#) or both NativeAOT and regular CLR (you could think of it as the vast majority of CLR being shared but JIT and AOT being two slightly non-overlapping spheres which implement certain runtime features differently, with NativeAOT using C# for what was in C++ previously).
Examples of these are threadlocals/threadstatics and string interning, where rewriting threadlocal storage in C# enabled further optimization in the compiler to fully elide any interop calls to C++ land and completely inline reading of these values, massively improving performance for this case, while rewriting string interning in C# too improved its performance and usability and allowed to remove the legacy cruft that existed to make it work on NativeAOT (still old C++ version for regular CLR but it's a rarely used feature anyway).
Another example is all string searching and manipulation code, all memcpy/memmove routines are too written in C# and always get optimal performance because C# has rich SIMD and intrinsics API which reach optimal HW utilization without ever having to touch C++ because it already gets compiled to comparable asm.
Or ThreadPool, it used to be written in C++ and then has received a rewrite in C# to enable further evolution and performance improvements (like blocked thread detection, or allowing for small methods to be inlined which is not an option with C++).
The overarching trend throughout all versions of .NET after going OSS has been moving more and more C++ code to C#.
There is a reddit post where a dotnet developer on the MSFT team details why they are moving certain processes to Rust. TLDR, it is all about performance that scale.
Does anybody have a link?
Earlier quoted context omitted.
There are tons of Rust jobs in blockchain.
I’m interested. Can you tell me what do rust developers build or work on in this space? Where do you start networking and build the demonstrable skills to get into blockchain?
In Ethereum (the domain I work in) there are lots of developer tools being written in Rust (Foundry, Build Bear). There is a new Eth node/client being developed in Rust, as well as a "wallet" browser extension. In Bitcoin I know Hiro, a Bitcoin L2, has lots of Rust, but I don't know which parts.
Earlier quoted context omitted.
And how many of such bugs could be prevented with compiler warnings and flags?
If you're going to start writing it testing or C++ like Rust or follow certain guidelines, a lot of them. But if you're going to constrain how you do things, why not use a language that also gives you higher level functionality along the way?
My point is that I just feel like "but someone please think of the ̶ ̶c̶h̶i̶l̶d̶r̶e̶n̶ memory safety" argument is over blown. There are ways to eliminate majority of those issues in cpp as well, but people simply don't care.
If You want to use Rust because it's just better language - go for it, I do it as well. But let's actually use that as an argument, instead of hiding behind superficial ones