Earlier quoted context omitted.
Is that needed because the compiler accesses some higher privileged APIs?
Why would a compiler needs any privileges, it's like a text editor
I don't know. That's why I'm asking
Microsoft seeks Rust developers to rewrite core C# code
201–210 of 256 posts
Re: Microsoft seeks Rust developers to rewrite core C# code
#202Earlier quoted context omitted.
This effect of spreading everywhere is very frequently a novice mistake of putting temporary scope-bound loans (AKA references) in structs that aren't temporary views themselves. People used to C or C++ perspective tend to reflexively (over)use references to avoid copying, but references in Rust are to avoid owning , and not-copying is handled in different ways. BTW, apart from edgiest of edge cases, &String is a use…
I am a novice when it comes to rust but as I recall the instant you put anything that isn't a scalar type you need lifetimes. Is that what the person you are replying to frustrated with? How would not copying be handled? Sorry for the basic questions. Your comment tickles something in my brain that suggests I need to know.
Very rarely do you need to pass around a lifetime-bound struct or enum that isn't _also_ meant to be temporary. (One database pool has database connections lifetime bound, for example, but the pool still owns the connection.) When I do, I generally eat the cost and put it behind a Rc/Arc, where cloning is cheap.
It is 'borrowing' because you don't own it, not because you don't want to clone/copy it. Sometimes it is cheaper to borrow than it is to clone/copy; sometimes it is not.
Re: Microsoft seeks Rust developers to rewrite core C# code
#203Earlier quoted context omitted.
Seems like RUST needs work to become easier to learn. Hard for a business to take a risk on using it (outside of a use case absolutely needing a memory safe language) if the talent pool is shallow.
I don't care that it's hard to learn. What turns me off rust is that if I ever make a change that requires a lifetime annotation, I now have to go back through all my code potentially adding lifetime annotations to everything it touches. I was making a little toy compiler in rust and basically gave up when I wanted to make a change that would have amount to string -> string_view in c++ because in rust I now need to t…
This is more or less the reason I don't like adding "const" to member functions in C++, or setting any method or field to anything but public.
Working with the code base gets so annoying if you suddenly want to change something you didn't plan for.
Such changes can have a domino effect through the code.
Re: Microsoft seeks Rust developers to rewrite core C# code
#204Earlier quoted context omitted.
Seems like RUST needs work to become easier to learn. Hard for a business to take a risk on using it (outside of a use case absolutely needing a memory safe language) if the talent pool is shallow.
Learning Rust to the point of being productive is 100x easier than C or C++. It's not even funny.
As someone that speaks legalese, and knows C and C++ relatively well to be productive, if nothing else by knowing them since 1993 and 1994 respectively, also have already written a couple of interesting stuff in Rust, that 100x easier is a bit too much.
Specially if we are talking about anything related to graphics programming, or asynchronous programming.
Re: Microsoft seeks Rust developers to rewrite core C# code
#205Earlier quoted context omitted.
The last few versions made a lot of the lifetimes elided so you can drop them.
I feel like this has been this way for at least two years, too?
Well maybe we started with 1.5x or so and especially impl trait‘s made a lot of things easier. We barely have lifetimes in our rust code.
Re: Microsoft seeks Rust developers to rewrite core C# code
#206Earlier quoted context omitted.
The last few versions made a lot of the lifetimes elided so you can drop them.
Do you have a direct link? I'd love to read more.
Sadly not. But between 1.5x and 1.7x a lit of things changed, especially around traits and there is clippy which actually helps. So our functions barely need lifetimes anymore.
Re: Microsoft seeks Rust developers to rewrite core C# code
#207Earlier quoted context omitted.
Depends on the language and platform/Runtime... For C# a single executable over a directory of files. For that and Java, a massive runtime, generally slow cold starts, high initial memory use, reduced relative effectiveness for smaller platforms (RPi and similar). For JavaScript and Python, slow introp, in addition to the negatives above. It's also possible to leak memory like a sieve in any language.
- 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 and @CriticalNative).
Re: Microsoft seeks Rust developers to rewrite core C# code
#208Earlier quoted context omitted.
Oh man, GC is amazingly nice but when it fails sure does it fail. It also typically fails when your biggest task is reducing overall resource spend, or getting that extra 9 after 3+ 9s of latency reduced. On multiple teams of FAANG engineers, Ive seen the GC be a big part of some meltdown and none of us knew a good way around it. Tuning only goes so far. Otherwise, you just have to give it more memory and CPUs (horiz…
Nothing like a game server engine in C# that would freeze for 15-30 seconds now and then for garbage collection...
Or like one locking the cache every few seconds a COM counter has to be updated, with a major freeze when a domino effect of objects reaching zero happen, when using DirectX, badly coded.
Re: Microsoft seeks Rust developers to rewrite core C# code
#209Earlier quoted context omitted.
What pain does it save most folks from that are using GC languages (as GP alluded to)? Genuinely curious.
GC _is_ the pain. Lots of use-cases where precise memory management is critical, or real-time guarantees are needed that are difficult with GC.
Hence why real time GC exists in first place.
Re: Microsoft seeks Rust developers to rewrite core C# code
#210Earlier quoted context omitted.
> C# — and garbage collected languages in general — aren’t going anywhere. So what? What does that have to do with rust? There’s no fight between C# and rust where only one language will survive. Both languages are great, and both languages probably have a bright future. C# depends on a lot of low level C/C++ code to function and run fast. I can imagine a future where rust enables c# to get better. I love rust, but t…
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 C# itself to be a great language for applications.
What part of my comment is “technically inaccurate”? I stand by it.