5 ms·

Given your username I suspect you're quite a bit older. I've mentored several grey beards on Rust and they weren't at all happy about it, at first. After a fe

• candiddevmike 3y ago
  What pain does it save most folks from that are using GC languages (as GP alluded to)? Genuinely curious.
  • deleted 3y ago
    [deleted]
  • williamdclt 3y ago
    GC _is_ the pain. Lots of use-cases where precise memory management is critical, or real-time guarantees are needed that are difficult with GC.
    • nycdotnet 3y ago
      “The garbage comes from somewhere” -David Fowler
    • pjmlp 3y ago
      Hence why real time GC exists in first place.
  • yazaddaruvala 3y ago
    Oh man, GC is amazingly nice but when it fails sure does it fail. It also typically fails when your biggest task is reducing overall resource spend, or getting that extra 9 after 3+ 9s of latency reduced. On multiple teams of FAANG engineers, Ive seen the GC be a big part of some meltdown and none of us knew a good way around it. Tuning only goes so far. Otherwise, you just have to give it more memory and CPUs (horizontally or vertically). Almost always the answer was, this might need to be reworked in C++ entirely or JNI. In same cases it even got funded and was a tremendous success (like 10x fewer resources). However, then you’re dealing with C++ and all of its issues. I’m looking forward to more value types in Java but managing the heap will always be a bottleneck eventually.
    • tracker1 3y ago
      Nothing like a game server engine in C# that would freeze for 15-30 seconds now and then for garbage collection...
      • pjmlp 3y ago
        Or like one locking the cache every few seconds a COM counter has to be updated, with a major freeze when a domino effect of objects reaching zero happen, when using DirectX, badly coded.
  • josephg 3y ago
    Weirdly enough, some of the worst memory leaks I’ve debugged in my career were in GCed languages. Because any object can reference anything, retaining references can hide anywhere in the code. (Including via closures and other exotic things you forget about). And because in GC languages we don’t often have a destructor (or anything like it), it’s very common for people to forget to clean up resources. (Eg filesystem handles, sockets, wasm object references, and so on). One weird thing about rust is that network sockets and file handles are automatically closed when the handle drops out of scope. The borrow checker takes care of that. If you do the same thing in JavaScript (open a socket then do nothing), the program won’t even quit on its own and you’ll have no idea why.
    • xigoi 3y ago
      > And because in GC languages we don’t often have a destructor (or anything like it), it’s very common for people to forget to clean up resources. (Eg filesystem handles, sockets, wasm object references, and so on). > One weird thing about rust is that network sockets and file handles are automatically closed when the handle drops out of scope. The borrow checker takes care of that. If you do the same thing in JavaScript (open a socket then do nothing), the program won’t even quit on its own and you’ll have no idea why. That’s not an inherent problem of GC. You can have linear types or destructors in a GC language.
      • thfuran 3y ago
        The first sentence you quoted acknowledged that it's a tendency rather than a fact of GC.
    • ClimaxGravely 3y ago
      If I understand correctly, what you are describing would often be done with a using scope block in C#. EX using (SomeKindOfHandle handle) { // handle releases when the scope ends }
    • tracker1 3y ago
      In IE6 it was really easy to lay memory with long lived apps. Any HTML object could have a JS event attached and give versa for object references in JS. Done it was across the COM boundary, if you removed an element from the DOM it would stick around if referenced in JS and give versa for inline JS on* attributes... I worked on an application with extjs that the workers had to close and reopen at least once a day. Or unofficial instructions were portable Firefox.
  • xedrac 3y ago
    Not all GC languages are created equal. The best of the GC languages in my opinion is Haskell. So if a project is well suited to the limitations of a GC language, like Haskell, then the benefits of Rust may be limited to things like its nicer tooling and more polished ecosystem, etc..., while also having a few downsides. But if we make the same comparison to Go or Python, the list of advantages gets a lot bigger.
  • tracker1 3y ago
    Depends on the language and platform/Runtime... For C# a single executable over a directory of files. For that and Java, a massive runtime, generally slow cold starts, high initial memory use, reduced relative effectiveness for smaller platforms (RPi and similar). For JavaScript and Python, slow introp, in addition to the negatives above. It's also possible to leak memory like a sieve in any language.
    • neonsunset 3y ago
      - Native interop in Java is surprisingly slow and very clunky (C# interop with C/C++ can be as cheap as direct calls nowadays) - .NET had been able to produce single-file (and self-contained when needed) executables way before NativeAOT was introduced - RPi is a fairly large platform compared to e.g. Arduino (for which Rust should be awesome) and can be well-served by NativeAOT (today). I might still use Rust for that one in the long run but using C# wouldn't be an issue both in terms of resource usage and OS since it's just an arm64 musl flavour of Linux usually with 1GB of RAM or more which is a lot for .NET (for context ~256MiB containers with ASP.NET Core image is a popular target for back-ends)
      • pjmlp 3y ago
        Java also has had possibility to do AOT since around 2000, the difference being that unlike NGEN, it was only available in commercial compilers like Excelsior JET, Aonix, and many others. PTC, Aicas and microEJ are still around, placing Java in hardware that .NET will never be, even with Meadows. Panama main goal is to replace JNI performance warts, while Java / ART has had mechanisms to do fast interop (@FastNative and @CriticalNative).
        • neonsunset 3y ago
          Panama appears to be solving the abysmal UX of JNI but puts the final performance nowhere near close .NET (without even measuring direct P/Invokes which are literal direct C calls if you statically link AOT binary). Do you have references that say otherwise? (I know you don't, it has JNI level of performance) p.s.: you have to be insane to use Java today on those listed platforms, which are much better served by C and now Rust. RPi is as small as it gets and on that I'd rather never touch any Java tooling because liking it is literal Stockholm syndrome - it is as low bar as it gets and almost anything else is better. p.p.s: for anyone's interested, here's the JEP for Panama: https://openjdk.org/jeps/424 https://openjdk.org/jeps/424 do give it a read, then look at C# spans and interop API and ask yourself whether you want to look again at Panama without gouging your eyes out.
  • IshKebab 3y ago
    * Ownership is very clear. In most GC languages ownership of objects is shared between everyone that can access it. That encourages bugs. * You can trivially make objects immutable. That feature is tacked on to most GC languages (e.g. Object.freeze) and rarely used, if it's even available. Again mutability of everything encourages bugs. * You can easily copy values. * You can use RAII to deterministically and automatically clean up resources, and guard things (e.g. using mutexes). These features are all in C++ too but Rust lets you have all that and memory safety (and it's better designed than C++). A classic bug that you wouldn't see in Rust might be passing a list into a function and the function mutating it when you weren't expecting it to. Basically impossible in Rust.
• secondcoming 3y ago
  Just like Jesus!
  • xedrac 3y ago
    Haha, that's some high praise!
• tracker1 3y ago
  As a gray beard... I'd rather work in rust moving forward for a lot of things.