4 ms·

You've just listed "Compiled language" features. Only the 4th point has any specificity to Rust, and even then, is vague in a way that could be misinterpreted.

You've just listed "Compiled language" features. Only the 4th point has any specificity to Rust, and even then, is vague in a way that could be misinterpreted. Rust's predominant feature, the one that brings most of its safety and runtime guarantees, is borrow checking. There are things I love about Rust besides that, but the safety from borrow checking (and everything the borrow checker makes me do) is why I like programming in rust. Now, when I program elsewhere, I'm constantly checking ownership "in my head", which I think is a good thing.

zamalek 1y ago
- Rust is a nice language to use
gwbas1c 1y ago
Oh no, I'm directly criticizing C/C++/Java/C#: The heavyweight framework (and startup cost) that comes with Java and C# makes them challenging for widely-adopted lightweight command-line tools. (Although I love C# as a language, I find the Rust toolchain much simpler and easier to work with than modern dotnet.) Building C (and C++) is often a nightmare.
- ComputerGuru 1y ago
  New AOT C# is nice, but not fully doable with the most common dependencies. It addresses a lot of the old issues (size, bloat, startup latency, etc)
  - jiggawatts 1y ago
    Hilariously, the Microsoft SQL Client is the primary blocker for AOT for most potential usecases. Want fast startup for an Azure Function talking to Azure SQL Database? Hah… no. In all seriousness, that one dependency is the chain around the ankle of modern .NET because it’s not even fully async capable! It’s had critical performance regression bugs open for years. Microsoft’s best engineers are busy partying in the AI pool and forgot about drudgery like “make the basics components work”.
- hypeatei 1y ago
  > The heavyweight framework Do you mean the VM/runtime? If so, you might be able to eliminate that with an AOT build. > I find the Rust toolchain much simpler and easier to work with than modern dotnet What part of the toolchain? I find them pretty similar with the only difference being the way you install them (with dotnet coming from a distro package and Rust from rustup)
  - jillesvangurp 1y ago
    Exactly, natively compiled garbage collected languages (like Java with Graal; or as executed on Android) don't have a lot of startup overhead. In Java the startup overhead is mostly two things that usually conspire to make things worse: 1) dynamic loading of jar files 2) reflection Number 1 allows you to load arbitrary jar files with code and execute them. Number 2 allows you to programmatically introspect existing code and then execute logic like "Find me all Foo sub classes and create an instance of those and return the list of those objects". You can do that at any time but a lot of that kind of stuff happens at startup. That involves parsing, loading and introspecting thousands of class files in jar files that need to be opened and decompressed. Most of "Java is slow" is basically programs loading a lot of stuff at startup, and then using reflection to look for code to execute. You don't have to do those things. But a lot of popular web frameworks like Spring do. A lot of that stuff is actually remarkably quick considering what it is doing. You'd struggle to do this in many other languages. Or at all because many languages don't have reflection. If you profile it, there are millions of calls happening in the first couple of seconds. It's taking time yes. But that code has also been heavily optimized over the years. Dismissing what that does as "java is slow" and X is fast is usually a bit of an apples and oranges discussion. With Spring Boot, there are dozens of libraries that self initialize if you simply add the dependency or the right configuration to your project. We can argue about whether that's nice or not; I'm leaning to no. But it's a neat feature. I'm more into lighter weight frameworks these days. Ktor server is pretty nice, for example. It starts pretty quickly because it doesn't do a whole lot on startup. Loading a tiny garbage collector library on startup isn't a big deal. It will add a few microseconds to your startup time maybe. Probably not milliseconds. Kotlin has a nice native compiler. If you compile hello world with it it's a few hundred kilobytes for a self contained binary with the program, runtime, and the garbage collection. It's not a great garbage collector. For memory intensive stuff you are better off using the JVM. But if that's not a concern, it will do the job.
- procaryote 1y ago
  Hello world in java is pretty fast. Not rust fast but a lot faster than you'd expect. Java starting slowly is mostly from all the cruft in the typical java app, with springboot, dependency injection frameworks, registries etc. You don't have to have those, it's just that most java devs use them and can't conceive of a world of low dependencies Still not great for commandline apps, but java itself is much better than java devs
  - kbolino 1y ago
    Java's biggest weakness in this area is its lack of value types. It's well known, Project Valhalla has been trying to fix it for years, but the JVM just wasn't built around such types and it's hard to bolt them on after the fact. Java's next biggest weakness (which will become more evident with value types) is its type-erased generics. Both of these problems lead to time wasted on unnecessary GC, and though they can be worked around with arrays and codegen, it's unwieldy to say the least.
    - pron 1y ago
      Project Valhalla will also specialise generics for value types. When you say, "it's hard to bolt on", the challenge isn't technical, but how to do this in a way that adds minimal language complexity (i.e. less than in other languages with explicit "boxed" and "inlined" values). Ideally, this should be done in a way that tells the compiler know which types can be inlined (e.g. they don't require identity) and then letting the compiler decide when it wants to actually inline an instance as a transparent optimisation. The challenge would not have been any smaller had Java done this from the beginning.
      - kbolino 1y ago
        Maybe I picked the wrong wording--I don't mean to diminish the ambitions or scope of Valhalla--but I definitely think the decision to eschew value types at the start has immense bearing on the difficulty of adding them now. Java's major competitors, C# and Go, both have had value types since day one and reified generics since they gained generics; this hasn't posed any major problems to either language (with the former being IMO already more complex than Java, but the latter being similarly or even less complex than Java). If the technical side isn't that hard, I'd have expected the JVM to have implemented value types already, making it available to other less conservative languages like Kotlin, while work on smoothly integrating it in Java took as long as needed. Project Valhalla is over a decade old, and it still hasn't delivered, or even seems close to delivering, its primary goals yet. Just to be clear, I don't think every language needs to meet every need. The lack of value types is not a critical flaw of Java in general, as it only really matters when trying to use Java for certain purposes. After all, C# is very well suited to this niche; Java doesn't have to fit in it too.
- quotemstr 1y ago
  Heavyweight startup? What are you talking about? A Graal-compiled Java binary starts in a few milliseconds. Great example of how people don't update prejudices for decades.
- pjmlp 1y ago
  Only for those that don't know how to use AOT compilation tools for Java and C#.
  - jraph 1y ago
    GraalVM indeed do wonders wrt startup times and in providing a single binary you can call.
    - pjmlp 1y ago
      Open J9 as well. Then there are all the others that used to be commercial like ExcelsiorJET, or surviving ones like PTC and Aicas.
  - paulddraper 1y ago
    Compiling Java AOT doesn’t obviate the need for the JVM. At least not for Graal. https://stackoverflow.com/questions/75316542/why-do-i-need-jvm-to-run-an-aot-compiled-code https://stackoverflow.com/questions/75316542/why-do-i-need-j...
    - gudzpoz 1y ago
      ... That post you linked was from two years ago, discussing JEP 295, which was delivered eight years ago. Graal-based AOT has evolved a lot ever since. And the answer even explicitly recommended using native images: > I think what you actually want to do, is to compile a native image of your program. This would include all the implications like garbage collection from the JVM into the executable. And it is this "native image" that all the comments above in this thread have been discussing, not JEP 295. (And Graal-based AOT in native images does remove the need to bundle a whole JRE.)
    - pjmlp 1y ago
      Because it is user problem, instead of compiling with native image, they produced a shared library out of the Jar. As you can see, it has nothing to do with that Stack Overflow question, https://www.graalvm.org/jdk25/reference-manual/native-image/ https://www.graalvm.org/jdk25/reference-manual/native-image/
jrop 1y ago
Just going to jump in here and say that there's another reason I might want Rust with a Garbage Collector: The language/type-system/LSP is really nice to work with. There have indeed been times that I really miss having enums + traits, but DON'T miss the borrow checker.
- tuveson 1y ago
  Maybe try a different ML-influenced language like OCaml or Scala. The main innovation of Rust is bringing a nice ML-style type system to a more low level language.
  - Yoric 1y ago
    Jane Street apparently has a version of OCaml extended with affine types. I'd like to test that, because that would (almost) be the best of all worlds.
    - nobleach 1y ago
      I think you're referring to OxCaml. I'd love to see this make a huge splash. Right now one of the biggest shortcomings of OCaml, is one is still stuck implementing so much stuff from scratch. Languages like Rust, Go and Java have HUGE ecosystems. OCaml is just as old (even older than Rust since OCaml inspired Rust and its original compiler was written in OCaml) as these languages. Since it's not been as popular, it's hard to find well-supported libraries.
      - debugnik 1y ago
        I too wish that some OxCaml features bring new blood to OCaml. I've been using OCaml for a few years for personal projects and I find the language really simple and powerful at the same time, but I had to implement me some foundational libraries (e.g. proper JSON, parser combinators), and now I'm considering porting one of those projects to Rust just so I can have unboxed types and better Windows support. > even older than Rust That's an understatement, (O)Caml is between 17 and 25 years older than Rust 0.1 depending on which Caml implementation you start counting from.
tayo42 1y ago
What other language has modern features like rust and is compiled?
- procaryote 1y ago
  it depends completely on what you put in "modern features"
  - tayo42 1y ago
    Pattern matching, usable abstractions, non null types, tagged unions or w/e enums are, build tools etc
    - munificent 1y ago
      I'm not sure what you mean by "usable abstractions" and tagged unions are a little verbose because they are defined in terms of closed sets of subtypes, but otherwise Dart has all of those.
      - tayo42 1y ago
        Nothing like "oh you can do that but with this weird work around" or if they're clunky to use
    - procaryote 1y ago
      This sounds more like "this is what I like in rust" than "features any modern language should have" though If you like rust, use rust. It's very likely the best rust
      - lmm 1y ago
        > This sounds more like "this is what I like in rust" than "features any modern language should have" though Good build tooling has been around since 2004, and all of the rest of those features have been around since the late 1970s. There's really no excuse for a language not having all of them.

zamalek 1y ago

- Rust is a nice language to use

gwbas1c 1y ago

Oh no, I'm directly criticizing C/C++/Java/C#: The heavyweight framework (and startup cost) that comes with Java and C# makes them challenging for widely-adopted lightweight command-line tools. (Although I love C# as a language, I find the Rust toolchain much simpler and easier to work with than modern dotnet.) Building C (and C++) is often a nightmare.

ComputerGuru 1y ago
New AOT C# is nice, but not fully doable with the most common dependencies. It addresses a lot of the old issues (size, bloat, startup latency, etc)
- jiggawatts 1y ago
  Hilariously, the Microsoft SQL Client is the primary blocker for AOT for most potential usecases. Want fast startup for an Azure Function talking to Azure SQL Database? Hah… no. In all seriousness, that one dependency is the chain around the ankle of modern .NET because it’s not even fully async capable! It’s had critical performance regression bugs open for years. Microsoft’s best engineers are busy partying in the AI pool and forgot about drudgery like “make the basics components work”.
hypeatei 1y ago
> The heavyweight framework Do you mean the VM/runtime? If so, you might be able to eliminate that with an AOT build. > I find the Rust toolchain much simpler and easier to work with than modern dotnet What part of the toolchain? I find them pretty similar with the only difference being the way you install them (with dotnet coming from a distro package and Rust from rustup)
- jillesvangurp 1y ago
  Exactly, natively compiled garbage collected languages (like Java with Graal; or as executed on Android) don't have a lot of startup overhead. In Java the startup overhead is mostly two things that usually conspire to make things worse: 1) dynamic loading of jar files 2) reflection Number 1 allows you to load arbitrary jar files with code and execute them. Number 2 allows you to programmatically introspect existing code and then execute logic like "Find me all Foo sub classes and create an instance of those and return the list of those objects". You can do that at any time but a lot of that kind of stuff happens at startup. That involves parsing, loading and introspecting thousands of class files in jar files that need to be opened and decompressed. Most of "Java is slow" is basically programs loading a lot of stuff at startup, and then using reflection to look for code to execute. You don't have to do those things. But a lot of popular web frameworks like Spring do. A lot of that stuff is actually remarkably quick considering what it is doing. You'd struggle to do this in many other languages. Or at all because many languages don't have reflection. If you profile it, there are millions of calls happening in the first couple of seconds. It's taking time yes. But that code has also been heavily optimized over the years. Dismissing what that does as "java is slow" and X is fast is usually a bit of an apples and oranges discussion. With Spring Boot, there are dozens of libraries that self initialize if you simply add the dependency or the right configuration to your project. We can argue about whether that's nice or not; I'm leaning to no. But it's a neat feature. I'm more into lighter weight frameworks these days. Ktor server is pretty nice, for example. It starts pretty quickly because it doesn't do a whole lot on startup. Loading a tiny garbage collector library on startup isn't a big deal. It will add a few microseconds to your startup time maybe. Probably not milliseconds. Kotlin has a nice native compiler. If you compile hello world with it it's a few hundred kilobytes for a self contained binary with the program, runtime, and the garbage collection. It's not a great garbage collector. For memory intensive stuff you are better off using the JVM. But if that's not a concern, it will do the job.
procaryote 1y ago
Hello world in java is pretty fast. Not rust fast but a lot faster than you'd expect. Java starting slowly is mostly from all the cruft in the typical java app, with springboot, dependency injection frameworks, registries etc. You don't have to have those, it's just that most java devs use them and can't conceive of a world of low dependencies Still not great for commandline apps, but java itself is much better than java devs
- kbolino 1y ago
  Java's biggest weakness in this area is its lack of value types. It's well known, Project Valhalla has been trying to fix it for years, but the JVM just wasn't built around such types and it's hard to bolt them on after the fact. Java's next biggest weakness (which will become more evident with value types) is its type-erased generics. Both of these problems lead to time wasted on unnecessary GC, and though they can be worked around with arrays and codegen, it's unwieldy to say the least.
  - pron 1y ago
    Project Valhalla will also specialise generics for value types. When you say, "it's hard to bolt on", the challenge isn't technical, but how to do this in a way that adds minimal language complexity (i.e. less than in other languages with explicit "boxed" and "inlined" values). Ideally, this should be done in a way that tells the compiler know which types can be inlined (e.g. they don't require identity) and then letting the compiler decide when it wants to actually inline an instance as a transparent optimisation. The challenge would not have been any smaller had Java done this from the beginning.
    - kbolino 1y ago
      Maybe I picked the wrong wording--I don't mean to diminish the ambitions or scope of Valhalla--but I definitely think the decision to eschew value types at the start has immense bearing on the difficulty of adding them now. Java's major competitors, C# and Go, both have had value types since day one and reified generics since they gained generics; this hasn't posed any major problems to either language (with the former being IMO already more complex than Java, but the latter being similarly or even less complex than Java). If the technical side isn't that hard, I'd have expected the JVM to have implemented value types already, making it available to other less conservative languages like Kotlin, while work on smoothly integrating it in Java took as long as needed. Project Valhalla is over a decade old, and it still hasn't delivered, or even seems close to delivering, its primary goals yet. Just to be clear, I don't think every language needs to meet every need. The lack of value types is not a critical flaw of Java in general, as it only really matters when trying to use Java for certain purposes. After all, C# is very well suited to this niche; Java doesn't have to fit in it too.
quotemstr 1y ago
Heavyweight startup? What are you talking about? A Graal-compiled Java binary starts in a few milliseconds. Great example of how people don't update prejudices for decades.
pjmlp 1y ago
Only for those that don't know how to use AOT compilation tools for Java and C#.
- jraph 1y ago
  GraalVM indeed do wonders wrt startup times and in providing a single binary you can call.
  - pjmlp 1y ago
    Open J9 as well. Then there are all the others that used to be commercial like ExcelsiorJET, or surviving ones like PTC and Aicas.
- paulddraper 1y ago
  Compiling Java AOT doesn’t obviate the need for the JVM. At least not for Graal. https://stackoverflow.com/questions/75316542/why-do-i-need-jvm-to-run-an-aot-compiled-code https://stackoverflow.com/questions/75316542/why-do-i-need-j...
  - gudzpoz 1y ago
    ... That post you linked was from two years ago, discussing JEP 295, which was delivered eight years ago. Graal-based AOT has evolved a lot ever since. And the answer even explicitly recommended using native images: > I think what you actually want to do, is to compile a native image of your program. This would include all the implications like garbage collection from the JVM into the executable. And it is this "native image" that all the comments above in this thread have been discussing, not JEP 295. (And Graal-based AOT in native images does remove the need to bundle a whole JRE.)
  - pjmlp 1y ago
    Because it is user problem, instead of compiling with native image, they produced a shared library out of the Jar. As you can see, it has nothing to do with that Stack Overflow question, https://www.graalvm.org/jdk25/reference-manual/native-image/ https://www.graalvm.org/jdk25/reference-manual/native-image/

jrop 1y ago

Just going to jump in here and say that there's another reason I might want Rust with a Garbage Collector: The language/type-system/LSP is really nice to work with. There have indeed been times that I really miss having enums + traits, but DON'T miss the borrow checker.

tuveson 1y ago
Maybe try a different ML-influenced language like OCaml or Scala. The main innovation of Rust is bringing a nice ML-style type system to a more low level language.
- Yoric 1y ago
  Jane Street apparently has a version of OCaml extended with affine types. I'd like to test that, because that would (almost) be the best of all worlds.
  - nobleach 1y ago
    I think you're referring to OxCaml. I'd love to see this make a huge splash. Right now one of the biggest shortcomings of OCaml, is one is still stuck implementing so much stuff from scratch. Languages like Rust, Go and Java have HUGE ecosystems. OCaml is just as old (even older than Rust since OCaml inspired Rust and its original compiler was written in OCaml) as these languages. Since it's not been as popular, it's hard to find well-supported libraries.
    - debugnik 1y ago
      I too wish that some OxCaml features bring new blood to OCaml. I've been using OCaml for a few years for personal projects and I find the language really simple and powerful at the same time, but I had to implement me some foundational libraries (e.g. proper JSON, parser combinators), and now I'm considering porting one of those projects to Rust just so I can have unboxed types and better Windows support. > even older than Rust That's an understatement, (O)Caml is between 17 and 25 years older than Rust 0.1 depending on which Caml implementation you start counting from.

tayo42 1y ago

What other language has modern features like rust and is compiled?

procaryote 1y ago
it depends completely on what you put in "modern features"
- tayo42 1y ago
  Pattern matching, usable abstractions, non null types, tagged unions or w/e enums are, build tools etc
  - munificent 1y ago
    I'm not sure what you mean by "usable abstractions" and tagged unions are a little verbose because they are defined in terms of closed sets of subtypes, but otherwise Dart has all of those.
    - tayo42 1y ago
      Nothing like "oh you can do that but with this weird work around" or if they're clunky to use
  - procaryote 1y ago
    This sounds more like "this is what I like in rust" than "features any modern language should have" though If you like rust, use rust. It's very likely the best rust
    - lmm 1y ago
      > This sounds more like "this is what I like in rust" than "features any modern language should have" though Good build tooling has been around since 2004, and all of the rest of those features have been around since the late 1970s. There's really no excuse for a language not having all of them.