Microsoft seeks Rust developers to rewrite core C# code • Hacker News Board

Re: Microsoft seeks Rust developers to rewrite core C# code

#241

Post by LtWorf » Mon, Feb 05, 2024, 7:25 PM UTC

josephg wrote: post #223

Xeamek wrote: post #220

Earlier quoted context omitted.

I agree. 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

> There are ways to eliminate majority of those issues in cpp as well, but people simply don't care. If its that easy, why do Google, Apple, Microsoft and basically everyone else keep making memory safety related bugs? Are they all just idiots? Do you think they just don't care about security? Carmack found C++ static analysis tools found mountains of latent bugs in the quake source code - despite the game running gr…

Fun fact: working at a large company doesn't make you smarter.

In fact all the laid off people probably feel less smart then average for accepting to work somewhere that treated them like that.

Re: Microsoft seeks Rust developers to rewrite core C# code

#242

Post by LtWorf » Mon, Feb 05, 2024, 7:36 PM UTC

josephg wrote: post #239

Xeamek wrote: post #236

Earlier quoted context omitted.

>Do You think people just don't care about security Yes, people don't care nearly as much as we like to pretend in online debates

I partially agree with you. I think most security compromises are due to misconfigured mongodb databases, bad passwords and unpatched software staying unpatched for months or years. Things like that. Lots of B tier engineering companies get done by this stuff every year because they’re sloppy. But memory bugs in C++ seem genuinely hard even if you do care about the problem. Google and Apple have never (as far as I kn…

Apple? The same company that forked the JVM and then was taking months to fix vulnerabilities for which exploits were readily available on the internet, and that had been fixed immediately on linux and windows?

The same company that has had a stream of no click 0days in imessage, because they parse the messages outside of a sandbox, and patch the issue but not the larger issue of the no-sandbox?

Yeah they don't care about security at all. It's mostly just a thing their marketing department talks about. I'm sure their R&D budget for it is quite limited given their size.

Re: Microsoft seeks Rust developers to rewrite core C# code

#243

Post by pdimitar » Mon, Feb 05, 2024, 8:29 PM UTC

munchler wrote: post #138

Sparkyte wrote: post #64

I imagine it comes down to the handling of threads vs anything else. Technology is rapidly adopting the more cores strategy of technology since we are hitting some IPC limitations and in the server space more cores is better.

.NET supports asynchronous code very well, so that hardly seems like a likely reason for rewriting in Rust.

> .NET supports asynchronous code very well

Work-stealing task schedulers?

Re: Microsoft seeks Rust developers to rewrite core C# code

#244

Post by pdimitar » Mon, Feb 05, 2024, 8:30 PM UTC

neonsunset wrote: post #169

Sparkyte wrote: post #64

I imagine it comes down to the handling of threads vs anything else. Technology is rapidly adopting the more cores strategy of technology since we are hitting some IPC limitations and in the server space more cores is better.

Multi-core scaling (in particular within GC) is one of the strongest points of .NET (for example, Go used to have poor scaling on many-core systems (has this changed in 2024?) while in .NET the throughput would continue scaling linearly)).

I really doubt that this is true, might be your bubble. Have you dabbled in Erlang/Elixir? Your standards would increase substantially if you did.

Re: Microsoft seeks Rust developers to rewrite core C# code

#245

Post by Capricorn2481 » Tue, Feb 06, 2024, 8:23 AM UTC

tracker1 wrote: post #179

Capricorn2481 wrote: post #149

Earlier quoted context omitted.

What domain are you working in where Rust is the replacement for Python?

Performance, portability, reduced memory use.. even containerization which can benefit from all of the above.

Those aren't really domains. Chances are if portability was a concern to you, you didn't start your project in Python.

Re: Microsoft seeks Rust developers to rewrite core C# code

#246

Post by neonsunset » Tue, Feb 06, 2024, 9:39 AM UTC

pdimitar wrote: post #244

neonsunset wrote: post #169

Earlier quoted context omitted.

Multi-core scaling (in particular within GC) is one of the strongest points of .NET (for example, Go used to have poor scaling on many-core systems (has this changed in 2024?) while in .NET the throughput would continue scaling linearly)).

I really doubt that this is true, might be your bubble. Have you dabbled in Erlang/Elixir? Your standards would increase substantially if you did.

Wouldn't that be trying out something that is a strict downgrade? (bytecode interpreter based VM with weak JIT, GC is likely much weaker too)

It really comes down to performing as much work on a core-local basis and .NET SRV GC does already a lot to avoid inter-core synchronization cost (per-core heaps, I'd expect JVM GCs do a similar, maybe better, job), and so does various thread-safe code in the standard library.

Re: Microsoft seeks Rust developers to rewrite core C# code

#247

Post by neonsunset » Tue, Feb 06, 2024, 9:44 AM UTC

pdimitar wrote: post #243

munchler wrote: post #138

Earlier quoted context omitted.

.NET supports asynchronous code very well, so that hardly seems like a likely reason for rewriting in Rust.

> .NET supports asynchronous code very well Work-stealing task schedulers?

Yes, and overall task-based code has been a basis for many APIs since .NET Framework 4.5 (2012), earlier async patterns existed before too. It is not in a frozen state either as each release sees improvements to asynchronous code execution (overall improving ThreadPool, reducing size of state machine boxes, experimenting with alternate underlying implementations like green threads experiment, the learnings of which have been carried over to runtime task handling experiment which will massively reduce the async overhead when it eventually finds its way into mainline runtime).

Re: Microsoft seeks Rust developers to rewrite core C# code

#248

Post by pdimitar » Tue, Feb 06, 2024, 11:24 AM UTC

neonsunset wrote: post #246

pdimitar wrote: post #244

Earlier quoted context omitted.

I really doubt that this is true, might be your bubble. Have you dabbled in Erlang/Elixir? Your standards would increase substantially if you did.

Wouldn't that be trying out something that is a strict downgrade? (bytecode interpreter based VM with weak JIT, GC is likely much weaker too) It really comes down to performing as much work on a core-local basis and .NET SRV GC does already a lot to avoid inter-core synchronization cost (per-core heaps, I'd expect JVM GCs do a similar, maybe better, job), and so does various thread-safe code in the standard library.

To answer your question:

To see how far behind everything is in terms of parallelism and concurrency. It's not even funny how primitive 99.9% of everything out there is in this area.

Re: Microsoft seeks Rust developers to rewrite core C# code

#249

Post by neonsunset » Tue, Feb 06, 2024, 2:03 PM UTC

pdimitar wrote: post #248

neonsunset wrote: post #246

Earlier quoted context omitted.

Wouldn't that be trying out something that is a strict downgrade? (bytecode interpreter based VM with weak JIT, GC is likely much weaker too) It really comes down to performing as much work on a core-local basis and .NET SRV GC does already a lot to avoid inter-core synchronization cost (per-core heaps, I'd expect JVM GCs do a similar, maybe better, job), and so does various thread-safe code in the standard library.

To answer your question: To see how far behind everything is in terms of parallelism and concurrency. It's not even funny how primitive 99.9% of everything out there is in this area.

Maybe compared to C++ or even Go (yes, Go is very rudimentary with examples expecting you to synchronize goroutines by hand), but unlikely compared to C#. While both parallelism and concurrency are not as central to it as to Erlang, it is a much more approachable language and achieving either or both is trivial:

    // Concurrency
    using var http = new HttpClient();

    var req1 = http.GetStringAsync("https://example.org/");
    var req2 = http.GetStringAsync("https://news.ycombinator.com/");

    Console.WriteLine(string.Join('\n', await req1, await req2));


    // Parallelism
    var user = Environment.GetFolderPath(
        Environment.SpecialFolder.UserProfile);

    var hashes = Directory
        .EnumerateFiles(Path.Combine(user, "Downloads"))
        .AsParallel()
        .Select(path =>
        {
            using var file = File.OpenRead(path);
            return Convert.ToHexString(SHA256.HashData(file));
        })
        .ToArray();

    Console.WriteLine(string.Join('\n', hashes));

For distributed computing, there are Orleans and Akka.net frameworks which allow to achieve it at scale and garden variety of other, simpler frameworks for job scheduling.

Re: Microsoft seeks Rust developers to rewrite core C# code

#250

Post by wredue » Tue, Feb 06, 2024, 6:21 PM UTC

theon144 wrote: post #145

wredue wrote: post #114

Earlier quoted context omitted.

I feel like you’re giving rust a pass here. It would be a red flag if you were interviewing for react and decided to bring up vue or svelte or angular or whatever else as well. It’s not like it’s only this C++/Rust type deal that is being picked on. Although I would suggest that rust fans tend to be particularly ardent and loud at the current moment, so interviewers may be far more turned off of you as a person just…

>It would be a red flag if you were interviewing for react and decided to bring up vue or svelte or angular or whatever else as well. ...why? Seriously, why on earth? I don't follow this train of thought at all; if they demonstrate proficiency within the scope of the position, why does it matter if they also happen to know other technologies? "Oh, Alice? Yeah, she was a great candidate, unfortunately she also had exp…

Nice strawman bro.

Nobody is saying to not expand your knowledge. You’re assuming it of this because it’s literally your only argument, but it’s an unfortunately shitty one, as most logical fallacies tend to be.

Nobody said “don’t have wide experience” but you. What I did say was “I’d probably avoid being an ardent fanboy toward an irrelevant to the interview tech stack”. And that “it’s most often best to leave irrelevant digressions to the interviewer”

Again, you go ahead and give out all the shit tier interview advice you like. For people that actually want jobs, probably try to stick to what’s relevant.