metaltyphoon

> Python lets library authors write __enter__ and __exit__ dunder methods to ensure that memory deallocation is handled correctly via Python context managers, which is a much more elegant abstraction

Whats stopping you from writing a WrapperPtr and the drop trait for it in Rust? This would achieve the same as the dunder methods in python

> nfs mounted fs

Anything doing locks on nfs, including trying to use sqlite, is a mistake. This is not a cargo problem this is a nsf problem.

Is this backed by real evidence?

What was the rationale to not use cargo? By the way, I really enjoy when you are a guest on the fallthrough podcast.

Unless someone is vetting code, nothing.

> and similar package ecosystems altogether

Realistically, this is impossible.

I truly despise the damage those books did to the SWE as a whole.

It’s this simple in .NET

   ArrayPool<T>

> many devs keep ignoring

And thats why Zig don’t offer much. Devs will just ignore it.

What are you trying to imply?

I don't consider C# a very large language. Most of what has been added removed boilerplate code. Swift, a much younger language, is way more complicated IMO

> Those two aren’t natively compiled

Idk how up to date ou are in .NET but so you can have an idea how trivial it is in C#:

   echo ‘Console.WriteLine(“hello world”);’ >> app.cs
   dotnet publish app.cs

That’s it. By default C# is natively compiling.

> Minecraft

Typo?

Out of all those only Java and Kotlin captured significant market like OP mentioned

‘static

> I am almost certain that the zig project will somehow manage to survive anyway without you following them.

It took longer than expected for this comment to show up.

C#?

>zero actual dependencies

on Linux only with CGO_ENABLED=0 and good luck using some non web related 3rd party module which can be used with CGO disabled.

This is exactly the problem, thread safety. The function being supplied with std.Io needs to understand what implementation is being used to take precautions with thread safety, in case a std.Io.Threaded is used. What if this function was designed with synchrony in mind, how do you prevent it taking a penalty guarding against a threaded version of IO?

Why? Asynchrony has nothing to do with multiple threads. In fact you can have async with only a single thread!

Except that now your library code lost context on how it runs. If you meant it to be sync and the caller gives you an multi threaded IO your code can fail in unexpected ways.

In C# that Task is ALWAYS hot, aka scheduled to run.

Attribute, lambda and turbofish?

Thats not the point OP was mentioning as in “battle tested” doesn’t mean free of bugs.

This is a reason why so many enterprises use C#. Most of the time you just use Microsoft made libraries and rarely brings in 3rd party.

Yes it's meant to be used in test code. If you're sure it can't fail do then use .expect() that way it shows you made a choice and it wasn't just a dev oversight.

> Well Rust won't save you from the usual programming mistake

This is not a Rust problem. Someone consciously chose to NOT handle an error, possibly thinking "this will never happen". Then someone else conconciouly reviewed (I hope so) a PR with an unwrap() and let it slide.

Rust isn’t that complicated if you have some background in non GC languages.

> As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly complicated trick https://lobste.rs/s/emvkea/why_we_didn_t_rewrite_our_feed_ha...

Nitpicking? Let’s show an example on creating an interface in Zig to see all complicated tricks.

> It's interesting how much Rust has slowed down

Rust has a SDK from the 3 big cloud providers, Rust IS mainstream.