Microsoft are re-writing c# stuff in Rust! https://news.ycombinator.com/item?id=39240205

The problem with writing a browser in C# or Java is that neither of them can provide anywhere close to the level of thread safety that Rust does.

both java and c# has thread safety primitives that are also pretty easy to use. E.g., the java concurrency package.

The cool thing about rust is that it forces you to use thread safety primitives. It's called fearless concurrency

Having done concurrency in Java and Rust, my experience is that Rust's concurrency primitives are an order of magnitude better than Java's. I haven't tested C#'s.

No, that's not what I'm talking about. C# and Java have nothing like the Send and Sync traits, and they don't have & and &mut.

C# doesn't have Send and Sync that is true. It frequently does not need either because it uses GC instead of affine types for automatic memory management. Synchronization is indeed "just don't write bugs", where Rust offers a massive upgrade, but .NET CoreCLR's memory model is more strict than C one, like object reference assignment having release semantics, so quite a few footguns are luckily avoided: https://github.com/dotnet/runtime/blob/main/docs/design/spec...

'&' and '&mut', however, are your 'ref readonly' and 'ref' respectively.

Is there anything in C# which ensures what Rust does statically, that you must acquire a lock to access data protected by a mutex? Rust also has MutexGuard not be sendable i.e the mutex won't be released on a different thread from which it is acquired.

With traditional mutex APIs it's just far too easy to get it wrong. I think you just have to structure your thread-related APIs to be misuse resistant. As humans we're just not good enough at not making mistakes.

> I think you just have to structure your thread-related APIs to be misuse resistant

The premise of this stays. C# approaches this in a more traditional way, with exposing the set of synchronization primitives. It's a step above C and, usually, C++ still because you don't need to e.g. have an atomic reference counting for objects shared by multiple threads.

Concurrent access itself can be protected as easily as doing

  lock (obj) {
    // critical section
  }

This, together with thread-safe containers provided by standard library (ConcurrentDictionary, ConcurrentStack, etc.) is usually more than enough.

What Rust offers in comparison is strong guarantee for complex scenarios, where you usually have to be much more hands-on. In C#, you can author types which e.g. provide "access lease", that look like 'using var scope = service.EnterScope(); ...`, where using turns into a try-finally block, where finally that calls .Dispose() on the scope is guaranteed to be executed.

It's a big topic, so if you have a specific scenario in mind - let me know.

Thanks! To be fair, there are certain advanced scenarios which Rust's mutex model can't handle either -- sometimes you want to protect writes via a mutex, but allow reads without them (maybe you're okay with torn state on reads). This is a rare, expert use case with architecture-specific considerations that must be handled with care.

I do think Rust's mutexes handle almost every use case that can be thrown at them, though, and in a way where it's next to impossible to get it wrong. I think if you're writing a browser engine in the 21st century you should bake in parallelism and concurrency from the start, and Rust is the most suitable language to do that in.

Servo exists, in Rust. I don't know of any browser engine in C#/Java?

Also, modern browsers as a whole outsize entire OSes (sans browser)...

> I don't know of any browser engine in C#/Java?

A famous one is HotJava. According to Wikipedia, it was also the first web browser to support Java applets.

It was also a mess :)

> A famous one is HotJava.

"Final release: Late 2004; 20 years ago"

I guess I should've specified "not completely and utterly dead"? ;D

(Also, the size and complexity of a browser at that point in time was arguably still a whole lot less than a modern one)

> At the end of the day web browser is just bunch of parsers and compilers working together

At the end of the day, OS is just a bunch of command lines being piped together. /sarcasm

Sure, you are just missing: rendering, layout, security, network traffic for sockets, low-level control over hardware, writing a decent enough VM, image processing, video playback, music playback, compression, decompression, self-update, decryption, don't forget add-ons people love add-ons, also add-on security and isolation, web edit and debug tools, network analysis tools, etc.

You know, little things.

Why would you need to reinvent networking layer instead of just sending http requests via matrue, battle tested lib available in your programming ecosystem e.g from MSFT? Same with crypto, sockets, compression, etc?

Video and audio I mentioned.

Extensions are tricky, right, but more from privacy standpoint cuz after all you can just expose too much

Browsers are using new http features much earlier than they're available in the system libraries. Browsers supported http2 and 3 before they were standardised enough to include in systems. .net http client still can't even tell you about http2 early hints as far as I understand it.

It's going to be the same for crypto and compression. Systems don't ship with brotli for example. The battle tested implementations come to the browsers first in many cases - or at least they're battle tested at the point anyone starts including them in .net or Java.

Sure, not being at the leading edge is a disadvantage, but I guess you could still handle 99.x% of web pages

All the major browsers came out when Windows XP had substantial market share.

So browser vendors couldn't rely on the platform to provide up-to-date SSL support. Or MP3 support. Or MPEG-4 support. Or PDF support. This established the norm that browsers would ship their own video support, their own SSL support, and so on.

And Google realised they like the power this gives them - if Google wants to replace HTTP with QUIC or introduce a new video DRM standard, or a new video codec like VP9 - they don't need the cooperation of anyone outside of Google.

If Chrome bundles DRM support (allowing it to play Netflix), and its own HTTP/2 stack for speed - are you going to release a browser that's slower and doesn't play Netflix? Doesn't sound like a recipe for big market share.

> Why would you need to reinvent networking layer instead of just sending http requests via matrue, battle tested lib available in your programming ecosystem e.g from MSFT?

Because modern browsers are essentially cross-compatible OSes.

So is .net

You've clearly never tried to use .net on a non-MS OS. Sure, it's possible. But it's also a royal pain, at least last time I checked.

I had .net on prod linux since 2018 and it works very fine. Web apps.

I'm happy to hear of your experience, but all we have at this point is a sample size of 2 with one good experience and one poor one…

(I've tried [and failed/given up after about 2 weeks] to get a .net desktop application to build on Linux.)

I hope you haven't been trying to use Mono or something obscure for this, which unfortunately happens from time to time.

If you have .NET SDK installed (you can get it with apt/dnf install dotnet8 or dotnet-sdk-8.0), you only need the following:

  dotnet new install Avalonia.Templates
  dotnet new avalonia.app
  dotnet run

If you don't like XAML, you can use https://github.com/AvaloniaUI/Avalonia.Markup.Declarative to write declarative SwiftUI-like code. You can also use F# if that's your cup of tea: https://github.com/fsprojects/Avalonia.FuncUI.

If you prefer GTK, there are rich GObject bindings that are a successor to GTK#: https://gircore.github.io/

Here are samples that demonstrate basic GTK4 usage scenarios: https://github.com/gircore/gir.core/tree/main/src/Samples/Gt...

All this should require less than 10 minutes including setup and such.

Lastly, I want to make a disclaimer that you do not need C# Dev Kit extension (which requires an account that annoys many people, including me) for VS Code, only the base C# one, which is what gives you language server, debugger, etc. If you are using VSCodium which cannot use closed-source vsdbg component that the base extension uses, you can replace it with https://github.com/muhammadsammy/free-vscode-csharp which uses open-source debugger from Samsung instead. It can be rough around the edges but works well enough in standard scenarios. Just don't use Debugger.WriteLine over Console. :D

Many of these components have been made part of the ecosystem long after they were introduced in Firefox. Also, the more platform-specific you go for each component, the more you're going to introduce subtle incompatibilities between Firefox running on different versions of Windows or in Firefox for Windows vs. macOS vs. Linux. Also, for a very, very long time, Microsoft had an extremely poor record in terms of security fixes. So what happens when you rely on a Microsoft http library and Microsoft takes a year or two to release a 0-day?

There are benefits to this approach, of course, but the costs would have been consequential.

> At the end of the day web browser is just bunch of parsers and compilers working together, and some video/audio

That's... an interesting reduction :) I guess it's about as true as saying that the Linux Kernel is a bunch of I/O and a scheduler?