5 ms·

I'm ambivalent about it. In my opinion, Rust is optimized to be a systems programming language. As such, we'd expect that it shouldn't really be your first cho

I'm ambivalent about it. In my opinion, Rust is optimized to be a systems programming language. As such, we'd expect that it shouldn't really be your first choice for writing an "application". (I'm not referring to the OP at all here) HOWEVER, Rust is such an excellent language that we all want to use it to write applications ANYWAY. That's kind of amazing in and of itself- that people want to deal with a non-GC'd language at all to write applications. Because, really, garbage collection is awesome and there's almost zero reason to avoid it unless you need extremely predictable performance, or very low runtime overhead, etc. As far as wrapping everything in Arcs and Mutexes is concerned: Yes, that's ugly and it's a lot of extra typing. On the other hand, your performance is still likely to be orders of magnitude faster than Python for some general application-type tasks, and it will likely avoid headaches with the borrow checker, etc. So, honestly, I don't know if I recommend doing that or not. Want I want is to be able to tell people to not use Rust for what they're doing. I'd like to have a different recommendation for a "garbage collected Rust" but there really isn't anything that I think is good enough for the title. Maybe Scala 3 (I haven't played with it yet) or OCaml when its multi-core stuff is done. Maybe F# or C# are good enough, too.

Zababa 5y ago
The problem with OCaml is not multicore. If it had an easier to use build system and a larger community (so more libraries), it could be great for server-side software. But dune is way harder to use than Cargo and you can often miss libraries. Here's an example of Dark moving away from OCaml to F# https://blog.darklang.com/leaving-ocaml/ https://blog.darklang.com/leaving-ocaml/, which doesn't have as much this problem because you can use C# stuff. Scala also doesn't suffer as much from it, part of it because it was really popular at some point, and part of it because you can use Java anyways. I hope at some point we'll have this "garbage collected Rust", but for now OCaml, Scala and F# all have a worse developer experience than Rust. I could add Haskell to that too. I've been thinking for some time that something like Go but based on a ML would fill this "garbage collected Rust" niche quite well. Maybe something built over Rust itself to leverage all the ecosystem? You could write all of the glue code in this language, have access to a large ecosystem of libraries and have an option for high performance code. This would also complement Rust nicely: I know that OCaml has a really fast compiler, which would be a breath of fresh air for the community.
- nicoburns 5y ago
  I think you're talking about Swift. Alas it doesn't seem to have caught on outside of the Apple ecosystem, so library support isn't great there either. I do agree that language built on top of the Rust ecosystem (kind of like how PHP exposes a lot of C libraries) could make a lot of sense.
  - Zababa 5y ago
    I don't think I am talking about Swift. The compilation is slow because of LLVM and you still have to handle cyclic references because of ref counting. As you said too, library support isn't great. I don't know how exactly is the dev experience too, at least outside of XCode. Last time I played a bit with it, adding the language server to VSCode was a bit of a pain. Still, I think Swift is a step in the right direction. I've heard good things about Nim too for this niche but never tried it. I think it'll suffer from the same problem of not being able to leverage an existing ecosystem though.
    - kinjba11 5y ago
      Nim compiles to C (through C?), so at least leveraging the C/C++ ecosystem is straightforward/first class. It is certainly difficult to justify breaking away from the huge established multiple decade ecosystems and standard libraries seen with the JVM/.NET/Python platforms for instance. https://nim-lang.org/docs/backends.html#interfacing https://nim-lang.org/docs/backends.html#interfacing
      - Zababa 5y ago
        OCaml is also pretty good at leveraging the C ecosystem, but that's not what people are looking for in a "garbage collected Rust". If they want something close to C they'll just use Rust. What they're looking for is something easier to write that still looks like Rust and having all the developer experience that Rust has. For this, the Nim ecosystem is way too small and can't leverage an existing platform. The same do apply to OCaml and Swift so it's not a Nim specific problem, it's just that Nim doesn't bring much compared to OCaml.
dexwiz 5y ago
> HOWEVER, Rust is such an excellent language that we all want to use it to write applications ANYWAY. Is this really the reason, or is it because people think they will get free performance wins by choosing the correct language? The plethora of articles detailing a developer's story trying to write X-style language in Rust shows that most are not approaching Rust with the correct mindset. I have limited experience is Rust, but seems like most people are attracted by shiny new toys in the language. Many people have issues with OO languages, and the separation of data and function is attractive. But it lacks the run time most application developers have come to know, specifically GC and easy references.
- steveklabnik 5y ago
  I'm sure there's a bit of both. Many people talk about how they love the tooling, the type system, enums, traits... stuff unrelated to performance.
- ragnese 5y ago
  I can only speak for myself, obviously. But, I think it's obviously about more than performance. Otherwise, people have always had C, C++, LISP, and even Java and Go that will be generally faster than Python, PHP, and JavaScript. I'd say there are three things that most people rave about with Rust: * traits as type classes (even if they don't know the term "type class") * enums and pattern matching (not even as flexible as some other languages like MLs, but way more than is possible in most popular languages with only Swift coming close) * the Iterator trait. I might write a sonnet about how much I love Iterator in Rust. It's lazy iteration, but it's also optimized at compile time to basically just be turned into a for loop.
amyjess 5y ago
> I'd like to have a different recommendation for a "garbage collected Rust" but there really isn't anything that I think is good enough for the title. D and Nim are both good candidates IMO.
- Zababa 5y ago
  Could you expand on that? They both seem like nice language, but why them over other proposed languages such as OCaml, Scala and F#?
  - Gene_Parmesan 5y ago
    Not the person you replied to, but OCaml, Scala, and F# all suffer from the potential drawback of being functional-first, and thus difficult for people to adapt to. If you are someone who is an OO programmer and are considering Rust for its potential performance and different model, it would be hard for me to recommend a language whose model is as different as OCaml's. Learning Rust entails learning the borrow checker and unlearning some of your OO habits; learning OCaml requires a sea change in your whole mentality & approach to programming if you've never experienced a functional lang before. Meanwhile, both D and Nim have the benefits of being procedurally grounded, and hence more familiar to someone coming from (say) C# or Java. Having said that, I think both of those languages may suffer from a lack of tooling/library breadth & depth. Nim in particular seems really cool, but it seems to be struggling to catch enough attention & interest to build a larger community -- probably in large part because it targets many of the same people who are currently high on Rust.
    - Zababa 5y ago
      I don't really agree here, even if they're not used much by the community OCaml can be written as a regular procedural or OO language. There are a few thing that can look weird for people new to this (immutable by default, the type system) but they're precisely what people looking for a GC'd Rust want I think. Rust also takes a lot from functional languages, and idiomatic Rust code usually looks like functional code. I think the biggest shock coming from Rust to OCaml would be the compiler errors and the quantity of online resources. There's a world of difference between the two, and they matter a lot when learning. I think the same is true for Scala. I don't know if F# is the same but since it takes from OCaml it may still have the procedural capabilities, and it seems it still has the OO features of OCaml. I do agree that D and Nim may be easier to approach from C# or Java, or even Python for Nim or C and C++ for D. These already represent a huge chunk of programmers, but not really what the typical person looking for a "garbage collected Rust" is, in my opinion. Especially since Java and C# programmers already have Scala and F#. While they're both different from what they're used to, they leverage the same plateform and can use the same libraries which is a huge plus. I agree with your conclusion too, and I think OCaml suffers from this too. Scala and F# have at least the libraries part covered.
xpressvideoz 5y ago
> I'd like to have a different recommendation for a "garbage collected Rust" I have exactly the same problem. Rust is nearly perfect to me, due to its non-nullable type, traits, package manager. It's just that losing garbage collection is not justifiable in my use cases. I've researched several languages but nothing "clicks" unlike what Rust did to me several years ago. C# might be my best bet but it lacks statically compiled binary. Go is my next bet but it lacks a sophisticated typesystem. Kotlin is my third bet but the Java toolchains are slow and too "enterprise-y". Swift is too Apple-centric and has weird corner cases like you can't change the order of the keyword parameters, due to its Objective-C origin. Life is full of trade-offs, I guess!
- metaltyphoon 5y ago
  Seems like c# is gaining lots of traction on AOT stuff very soon.

Zababa 5y ago

The problem with OCaml is not multicore. If it had an easier to use build system and a larger community (so more libraries), it could be great for server-side software. But dune is way harder to use than Cargo and you can often miss libraries. Here's an example of Dark moving away from OCaml to F# https://blog.darklang.com/leaving-ocaml/ https://blog.darklang.com/leaving-ocaml/, which doesn't have as much this problem because you can use C# stuff. Scala also doesn't suffer as much from it, part of it because it was really popular at some point, and part of it because you can use Java anyways. I hope at some point we'll have this "garbage collected Rust", but for now OCaml, Scala and F# all have a worse developer experience than Rust. I could add Haskell to that too. I've been thinking for some time that something like Go but based on a ML would fill this "garbage collected Rust" niche quite well. Maybe something built over Rust itself to leverage all the ecosystem? You could write all of the glue code in this language, have access to a large ecosystem of libraries and have an option for high performance code. This would also complement Rust nicely: I know that OCaml has a really fast compiler, which would be a breath of fresh air for the community.

nicoburns 5y ago
I think you're talking about Swift. Alas it doesn't seem to have caught on outside of the Apple ecosystem, so library support isn't great there either. I do agree that language built on top of the Rust ecosystem (kind of like how PHP exposes a lot of C libraries) could make a lot of sense.
- Zababa 5y ago
  I don't think I am talking about Swift. The compilation is slow because of LLVM and you still have to handle cyclic references because of ref counting. As you said too, library support isn't great. I don't know how exactly is the dev experience too, at least outside of XCode. Last time I played a bit with it, adding the language server to VSCode was a bit of a pain. Still, I think Swift is a step in the right direction. I've heard good things about Nim too for this niche but never tried it. I think it'll suffer from the same problem of not being able to leverage an existing ecosystem though.
  - kinjba11 5y ago
    Nim compiles to C (through C?), so at least leveraging the C/C++ ecosystem is straightforward/first class. It is certainly difficult to justify breaking away from the huge established multiple decade ecosystems and standard libraries seen with the JVM/.NET/Python platforms for instance. https://nim-lang.org/docs/backends.html#interfacing https://nim-lang.org/docs/backends.html#interfacing
    - Zababa 5y ago
      OCaml is also pretty good at leveraging the C ecosystem, but that's not what people are looking for in a "garbage collected Rust". If they want something close to C they'll just use Rust. What they're looking for is something easier to write that still looks like Rust and having all the developer experience that Rust has. For this, the Nim ecosystem is way too small and can't leverage an existing platform. The same do apply to OCaml and Swift so it's not a Nim specific problem, it's just that Nim doesn't bring much compared to OCaml.

dexwiz 5y ago

> HOWEVER, Rust is such an excellent language that we all want to use it to write applications ANYWAY. Is this really the reason, or is it because people think they will get free performance wins by choosing the correct language? The plethora of articles detailing a developer's story trying to write X-style language in Rust shows that most are not approaching Rust with the correct mindset. I have limited experience is Rust, but seems like most people are attracted by shiny new toys in the language. Many people have issues with OO languages, and the separation of data and function is attractive. But it lacks the run time most application developers have come to know, specifically GC and easy references.

steveklabnik 5y ago
I'm sure there's a bit of both. Many people talk about how they love the tooling, the type system, enums, traits... stuff unrelated to performance.
ragnese 5y ago
I can only speak for myself, obviously. But, I think it's obviously about more than performance. Otherwise, people have always had C, C++, LISP, and even Java and Go that will be generally faster than Python, PHP, and JavaScript. I'd say there are three things that most people rave about with Rust: * traits as type classes (even if they don't know the term "type class") * enums and pattern matching (not even as flexible as some other languages like MLs, but way more than is possible in most popular languages with only Swift coming close) * the Iterator trait. I might write a sonnet about how much I love Iterator in Rust. It's lazy iteration, but it's also optimized at compile time to basically just be turned into a for loop.

amyjess 5y ago

> I'd like to have a different recommendation for a "garbage collected Rust" but there really isn't anything that I think is good enough for the title. D and Nim are both good candidates IMO.

Zababa 5y ago
Could you expand on that? They both seem like nice language, but why them over other proposed languages such as OCaml, Scala and F#?
- Gene_Parmesan 5y ago
  Not the person you replied to, but OCaml, Scala, and F# all suffer from the potential drawback of being functional-first, and thus difficult for people to adapt to. If you are someone who is an OO programmer and are considering Rust for its potential performance and different model, it would be hard for me to recommend a language whose model is as different as OCaml's. Learning Rust entails learning the borrow checker and unlearning some of your OO habits; learning OCaml requires a sea change in your whole mentality & approach to programming if you've never experienced a functional lang before. Meanwhile, both D and Nim have the benefits of being procedurally grounded, and hence more familiar to someone coming from (say) C# or Java. Having said that, I think both of those languages may suffer from a lack of tooling/library breadth & depth. Nim in particular seems really cool, but it seems to be struggling to catch enough attention & interest to build a larger community -- probably in large part because it targets many of the same people who are currently high on Rust.
  - Zababa 5y ago
    I don't really agree here, even if they're not used much by the community OCaml can be written as a regular procedural or OO language. There are a few thing that can look weird for people new to this (immutable by default, the type system) but they're precisely what people looking for a GC'd Rust want I think. Rust also takes a lot from functional languages, and idiomatic Rust code usually looks like functional code. I think the biggest shock coming from Rust to OCaml would be the compiler errors and the quantity of online resources. There's a world of difference between the two, and they matter a lot when learning. I think the same is true for Scala. I don't know if F# is the same but since it takes from OCaml it may still have the procedural capabilities, and it seems it still has the OO features of OCaml. I do agree that D and Nim may be easier to approach from C# or Java, or even Python for Nim or C and C++ for D. These already represent a huge chunk of programmers, but not really what the typical person looking for a "garbage collected Rust" is, in my opinion. Especially since Java and C# programmers already have Scala and F#. While they're both different from what they're used to, they leverage the same plateform and can use the same libraries which is a huge plus. I agree with your conclusion too, and I think OCaml suffers from this too. Scala and F# have at least the libraries part covered.

xpressvideoz 5y ago

> I'd like to have a different recommendation for a "garbage collected Rust" I have exactly the same problem. Rust is nearly perfect to me, due to its non-nullable type, traits, package manager. It's just that losing garbage collection is not justifiable in my use cases. I've researched several languages but nothing "clicks" unlike what Rust did to me several years ago. C# might be my best bet but it lacks statically compiled binary. Go is my next bet but it lacks a sophisticated typesystem. Kotlin is my third bet but the Java toolchains are slow and too "enterprise-y". Swift is too Apple-centric and has weird corner cases like you can't change the order of the keyword parameters, due to its Objective-C origin. Life is full of trade-offs, I guess!

metaltyphoon 5y ago
Seems like c# is gaining lots of traction on AOT stuff very soon.