3 ms·
Oh, yeah, definitely. I guess I was responding more to the "Rust isn't my favorite language" part of your comment- what would you like a language in that niche
by Rusky 11y ago
Oh, yeah, definitely. I guess I was responding more to the "Rust isn't my favorite language" part of your comment- what would you like a language in that niche to do differently than Rust? Or do you just prefer when you can get away without a C replacement? :)
- tombert 11y agoOh, my bad, I misunderstood. Lemme first state that I am not a systems developer; I mostly do servers. That said, some stuff that keeps Rust from being my favorite is a lack of tail-call optimization, the lack of the ability to say that a function is pure and impure (and have that enforced), and not having some concept of a green-threading library built-in. I realize that the last point can fairly easily be implemented with a library, but the first two points keep me using Haskell. And evidently, if I'm wrong about any of these points, don't hesitate to correct me! I'd love to have a chance to get better with the language. EDIT: Just a note, I know that Haskell isn't a systems language and not a direct replacement for Rust. That said, I find that a lot of the features I want in Rust are things I like in Haskell.
- Rusky 11y agoYeah, those are pretty common pain points in Rust. There is some potential to add tail calls in the future, though, through a reserved keyword "be" (since destructors + tail call optimization don't get along well).
- TheHydroImpulse 11y agoGreen threads are probably not going to be as useful in Rust as in other languages. Having something like await/async built into the compiler that transforms into state machine (like in C#) would be more powerful it seems.
- pcwalton 11y agoNote that Rust does do sibling call optimization, which covers TCO in most of the places where people want to use it. However, bear in mind that TCO and not having a GC are, if not incompatible per se, severely at odds.