4 ms·

Ignore the drama. The language in its current state is great, and will survive bureaucratic spats. Other languages may be more ergonomic or have more batteries

Ignore the drama. The language in its current state is great, and will survive bureaucratic spats. Other languages may be more ergonomic or have more batteries included, but none of them can offer the holy grail of memory safety without garbage connection.

Zababa 5y ago
The holy grail isn't always memory safety without garbage collection, especially in standalone apps. If you have a magic garbge collector that runs instantly while taking no memory, then there's no reason to not use it. That also means that if a GC language gets as performant as Rust, Rust would lose part of it advantage. For example, OCaml is getting multicore and effects, and can serve almost as much HTTP requests as a Rust server based on Hyper. C# is getting performance improvements too, and lots of them.
- littlestymaar 5y ago
  No other languages (except Pony, but it unfortunately never became popular) offers compile-time thread safety comparable to Rust, and this is an issue it cannot be solved with a garbage collector. It isn't discussed as much nowadays, because people more focus on the memory management side of Rust's benefit, but it was the reason Rust was designed in the first place, and it has no competitor in this area: if you need to do any kind of significant multi-threading in you application, then Rust is a game changer.
  - Zababa 5y ago
    Fair point, that's why I said that Rust would only lose part of its appeal and not all of it. I mostly do web stuff so my vision is influenced by that. In that context, Rust's strength is that you can get C++ like performance without the footguns. But in those cases, if you have a language that's easier to use and that doesn't use that much more resources than Rust, Rust would lose a part of its appeal.
- ibraheemdev 5y ago
  > can serve almost as much HTTP requests as a Rust server based on Hyper Do you have a link to a benchmark showing this?
  - Zababa 5y ago
    I do. The benchmark results itself is here: https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/b/bb7fc0a89f144c0a81224aa49bb46ffc55917522_2_690x409.jpeg https://aws1.discourse-cdn.com/standard11/uploads/ocaml/opti.... This comes from the OCaml multicore monthly news, the october 2021 edition: https://discuss.ocaml.org/t/multicore-ocaml-october-2021/8822 https://discuss.ocaml.org/t/multicore-ocaml-october-2021/882.... The benchmark's repo is here: https://github.com/ocaml-multicore/retro-httpaf-bench https://github.com/ocaml-multicore/retro-httpaf-bench. However that image is not the whole story, and there's a bit more info here: https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89 https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5.... In that video, the author says that the result vary depending on the load (sometimes Rust Hyper can end up above OCaml httpaf eio), that OCaml currently uses an io-uring backend while Rust doesn't, and that the results are for single core as previous OCaml implementations are single-core themselves. I do feel that this benchmark is incomplete. I'd like it to see the results while using all of the cores of a machine, and I'd like to see different type of loads. I do think that the results are impressive: performance between Go and Rust is great. I do hope that it stays this way with multicore.

Zababa 5y ago

The holy grail isn't always memory safety without garbage collection, especially in standalone apps. If you have a magic garbge collector that runs instantly while taking no memory, then there's no reason to not use it. That also means that if a GC language gets as performant as Rust, Rust would lose part of it advantage. For example, OCaml is getting multicore and effects, and can serve almost as much HTTP requests as a Rust server based on Hyper. C# is getting performance improvements too, and lots of them.

littlestymaar 5y ago
No other languages (except Pony, but it unfortunately never became popular) offers compile-time thread safety comparable to Rust, and this is an issue it cannot be solved with a garbage collector. It isn't discussed as much nowadays, because people more focus on the memory management side of Rust's benefit, but it was the reason Rust was designed in the first place, and it has no competitor in this area: if you need to do any kind of significant multi-threading in you application, then Rust is a game changer.
- Zababa 5y ago
  Fair point, that's why I said that Rust would only lose part of its appeal and not all of it. I mostly do web stuff so my vision is influenced by that. In that context, Rust's strength is that you can get C++ like performance without the footguns. But in those cases, if you have a language that's easier to use and that doesn't use that much more resources than Rust, Rust would lose a part of its appeal.
ibraheemdev 5y ago
> can serve almost as much HTTP requests as a Rust server based on Hyper Do you have a link to a benchmark showing this?
- Zababa 5y ago
  I do. The benchmark results itself is here: https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/b/bb7fc0a89f144c0a81224aa49bb46ffc55917522_2_690x409.jpeg https://aws1.discourse-cdn.com/standard11/uploads/ocaml/opti.... This comes from the OCaml multicore monthly news, the october 2021 edition: https://discuss.ocaml.org/t/multicore-ocaml-october-2021/8822 https://discuss.ocaml.org/t/multicore-ocaml-october-2021/882.... The benchmark's repo is here: https://github.com/ocaml-multicore/retro-httpaf-bench https://github.com/ocaml-multicore/retro-httpaf-bench. However that image is not the whole story, and there's a bit more info here: https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89 https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5.... In that video, the author says that the result vary depending on the load (sometimes Rust Hyper can end up above OCaml httpaf eio), that OCaml currently uses an io-uring backend while Rust doesn't, and that the results are for single core as previous OCaml implementations are single-core themselves. I do feel that this benchmark is incomplete. I'd like it to see the results while using all of the cores of a machine, and I'd like to see different type of loads. I do think that the results are impressive: performance between Go and Rust is great. I do hope that it stays this way with multicore.