2 ms·

This is pure bs considering the massive amount of large commercial projects written in C# that depends on a lot of community-made packages.

• alightsoul 2y ago
  C# and other high level languages like Java are much safer than any low level language including Rust, in those languages you don't even have an unsafe mode
  • neonsunset 2y ago
    .NET languages have always had access to unsafe feature subsets at multiple levels of abstraction with varying degrees of "unsafety". .NET has also been slowly leaning more into its systems-programming side. It is now at a strange crossroads where it is not like C or C++, or as a much better replacement, Rust but not like Java or Go either.
  • debrutal 2y ago
    Have you ever heard of Java native Interface or Java native abstractions? Thats unsafe AF. Same goes for native implementations. Whenever something needs to be done fast, the jvm implements native code. Have you ever debugged that magic bs? Guess why people chose a high level language, because they don't want to bother with complicated stuff. Still those abstractions on these languages are not better, even worse considering their APIs, than rusts. Working with thread locals or synchronized keywords, non atomic members and all the bad concurrency mechanisms inside Java is unsafe shy default. Runtime exceptions is what I consider a bad practice and it's spread everywhere in Java... Also the language evolutions are not really that good. So bringing errors/exception to the compilation time is a safety net. Despite the fact that languages with managed memory safety bring a lot of potential for abusively high memory consumption, random GC stop the world situations and worse like oom. Whenever I had to analyze a memory issue with an application it was no fun at all, despite the challenge. The jvm specifications are so flawed considering security... Creating classes at runtime from a stream using reflections, which is totally spec compliant gave us log4shell. Why even load serialized classes from remote?! Fail by design. So safety is still context sensitive and depends on the requirements. If you write bad software you can ignore some of the mentioned aspects, though it still lacks of 'security' Just my 2 cents here
  • nipah 2y ago
    C# absolutely have an unsafe mode, basically since version 1. You can use pointers, deal with stackallocated memory and all of that, in recent versions you can even natively allocate and deallocate memory using the `NativeMemory` type. Of course, it is harder to cause problems and the `unsafe` isolated areas provide a similar unsafety abstraction mechanism as Rust does, but it is still possible. And in the edge, both C# and Java have FFI and can call directly into C/C++ (or basically any native language) code, so you can still open a big security hole in your application (and nuget makes it very convenient to even ship native binaries in your packages, as you can see with the many wrappers around things like libsodium, raylib, windows/linux API's and more). In the end of the day, C# had the same ideas of isolating unsafety that Rust has, and provides many safe wrappers around good libs, like Skia (SkiaSharp, very famous and widely used) for example. So those ideas are kinda market proven as well.