Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust panics under the hood, and implementing them in .NET

fractalfir.github.io

Post reply on HN
Print view View original

81–83 of 83 posts

Re: Rust panics under the hood, and implementing them in .NET

#81

Post by Nullabillity »

neonsunset wrote: post #80
Nullabillity wrote: post #78

Earlier quoted context omitted.

> the closed component, that is a debugger, is free as well. Iff you use Microsoft's builds of VS Code. Just like back in 2018. > At the same time, Rider uses its own homegrown debugger, that works even better and has nice time-travel capability. So... still useless for the rest of us.

> So... still useless for the rest of us. Why? How does the situation look in Java? It also seems you have not read the original reply. So to reiterate, there is https://github.com/Samsung/netcoredbg too. In any case, I assume none of this has any use to you and the reply is posted simply as bad faith engagement, as it continues to happen whenever a piece of software that uses .NET is mentioned, because usually very…

> Why? How does the situation look in Java?

jdb is part of OpenJDK, and doesn't try to implement any such restrictions. Neither does gdb, for that matter.

But there is also a cultural difference. .NET libraries (including the standard library) are notoriously poor at implementing useful .ToString() overrides, because it's all designed to assume that you will use a debugger.

For comparison, Scala and Rust have cultures that emphasize printf-friendliness, and I rarely have to reach for a debugger at all. The difference it makes for my sanity is immense (as someone who wasted years on the shitshow that is .NET).

> It also seems you have not read the original reply. So to reiterate, there is https://github.com/Samsung/netcoredbg too.

I spent way too long trying to get netcoredbg to work, and couldn't get it to do much of anything. Maybe it's less of a shitshow now? Given that your original reply wasn't "yeah nobody uses the MS debugger anyway", I somehow doubt it.

> and the reply is posted simply as bad faith engagement

I mostly get annoyed when I see bad faith arguments that old problems are irrelevant because they're old, even if the problem has never actually been addressed.

Re: Rust panics under the hood, and implementing them in .NET

#82

Post by neonsunset »

Nullabillity wrote: post #81
neonsunset wrote: post #80

Earlier quoted context omitted.

> So... still useless for the rest of us. Why? How does the situation look in Java? It also seems you have not read the original reply. So to reiterate, there is https://github.com/Samsung/netcoredbg too. In any case, I assume none of this has any use to you and the reply is posted simply as bad faith engagement, as it continues to happen whenever a piece of software that uses .NET is mentioned, because usually very…

> Why? How does the situation look in Java? jdb is part of OpenJDK, and doesn't try to implement any such restrictions. Neither does gdb, for that matter. But there is also a cultural difference. .NET libraries (including the standard library) are notoriously poor at implementing useful .ToString() overrides, because it's all designed to assume that you will use a debugger. For comparison, Scala and Rust have culture…

> I spent way too long trying to get netcoredbg to work, and couldn't get it to do much of anything. Maybe it's less of a shitshow now? Given that your original reply wasn't "yeah nobody uses the MS debugger anyway", I somehow doubt it.

This got me curious. Turns out there exists an actively maintained fork of the official C# extension that comes with NetCoreDbg instead: https://github.com/muhammadsammy/free-vscode-csharp

I was able to successfully debug simple async code with it after installing the vsix, disabling the official one and restarting VS Code without changing any other settings.

So, for the trivial case it works. Submitted issues do indicate further compatibility problems like not supporting "Debug.Write*" methods (just use a logger or Console.Write* I guess?) or instability when bridging this extension to something that isn't VS Code.

Still, someone even managed to get it to work with Cursor: https://github.com/dgokcin/dotnet-cursor-debugging-with-brea...

> For comparison, Scala and Rust have cultures that emphasize printf-friendliness, and I rarely have to reach for a debugger at all. The difference it makes for my sanity is immense (as someone who wasted years on the shitshow that is .NET).

This is the first time I hear someone tout print-based debugging as an advantage. The approach F# takes with printfn "%A" might be more to your taste. Otherwise, DebuggerDisplay and DebuggerTypeProxy are there for a reason, and I don't understand the case for not using a debugger. But if you really want to, there are many ways to make the output pretty. Making a simple '.Print()' extension method that will do indented JsonSerializer.Serialize is already a start. Records also come with default ToString implementation.

Re: Rust panics under the hood, and implementing them in .NET

#83

Post by radicalbyte »

phs2501 wrote: post #54
radicalbyte wrote: post #42

Earlier quoted context omitted.

Rust is a step back with respect to being error prone, unless you're doing manual memory management in .Net (i.e. unsafe). The use cases I see are going to be things such as sharing a library over multiple platforms. I've done that with Go in the past via cgo.

Rust is a step sideways if anything. Yeah, you don't have manual memory management headaches in .NET, but you also don't have Rust's fairly strong compile-time guarantees about memory sharing and thread safety. Which enables stuff like rayon where you can basically blindly replace map with parallel map and if it compiles, it _should_ be safe to run. (I'm not super familiar with the .NET ecosystem, so it's quite possi…

As @neosunset says we have a lot of good options but I've not come across anything which strictly guarantees thread safety. In practise issues are uncommon and easy to identify / fix.

Honestly I'm more interested in code contracts than Rust, as they allow you to make a set of statements of your system which can then be validated statically. I've had very good results using them (and am forever grateful to the colleague who introduced me to them)... and I am interested in Rust (having dabbled with it, only I'm yet to use it in a paying or production project).

So sideways as you said - with C# you can usually rely on the GC for memory management, have fast compile times and what I feel is a more flexible model.. and top tier tooling and a huge and wide range of libraries. Rust can be much more efficient and has much better language-level properties wrt threat safety and a more mature story around native code.

I'd use Rust for system-level code or places where I'd otherwise think of using C++. I keep having discussions with people who want to use Rust for everything - CLI tools, web services (which are doing pumping), business logic and the like. It's getting tiring. The trade-offs are bad. C#, Go and Java are all far better suited & cover pretty much all the niches.

Does Rust have anything to spot resource leaks (i.e. the infamous IDisposable in C#)?

Post reply on HN