52 ms·

Yes, LLVM is good these days. But look at the source code and decide for yourself what kind of code you'd rather read/work on. Personally, I'll stay away from R

Yes, LLVM is good these days. But look at the source code and decide for yourself what kind of code you'd rather read/work on. Personally, I'll stay away from Rust for the sake of my eyes: http://benchmarksgame.alioth.debian.org/u64/program.php?test=spectralnorm&lang=rust&id=3 http://benchmarksgame.alioth.debian.org/u64/program.php?test... (Go counterpart: http://benchmarksgame.alioth.debian.org/u64/program.php?test=spectralnorm&lang=go&id=1 http://benchmarksgame.alioth.debian.org/u64/program.php?test...) - Go code I've written will eventually perform better as the compiler is optimized, but optimized Rust will always be an ugly mess.

TheHydroImpulse 12y ago
It's highly unlikely Go will be able to compete in terms of compiler optimizations because of it's goal of fast compilation speeds. The majority of the time Rust spends compiling code is within LLVM last time I checked, because LLVM does quite a bit of optimizations. Then if you take into account the fact that Go's language features do not promote highly-performant code (GC, heap allocation, dynamic dispatching) that a few people in this thread has touched on. While better looking code is highly subjective, Rust has indeed traded off some aesthetics for safety, performance, etc... However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust.
- lazyjones 12y ago
  > It's highly unlikely Go will be able to compete in terms of compiler optimizations because of it's goal of fast compilation speeds. For a given piece of code as written today, its compilation speed will naturally improve over time as processors get faster. Optimizing it to a certain degree becomes faster for the same reason. Therefore, assuming a fixed threshold for what constitutes "fast [enough] compilation", potential for more optimizations becomes available over time. > However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust. That's true for many languages, including PHP or Perl. The problem is: once you use these languages more, you discover that most people don't do it (for various reasons, one of them often being that they're trying to be clever).
shadowmint 12y ago
If you judge your programming languages based on personal aesthetics of the 'beauty of the code', you're wondering off into lala land. Go has a better syntax that rust, objectively, because it refuses to create new operators that are not orthogonal to existing ones. That makes it easier to parse because there are fewer 'code synonyms' (eg. the rust Fn<(Arg1, Arg2), (Rtn)> is identical to Fn<Args, Arg2> -> Rtn; to be fair go has its share of these irritations as well; eg. x := 1, vs var x = 1; but fewer of them) It's got nothing to do with how pretty or ugly the code is.
- bwilliams 12y ago
  It also starts looking better aesthetically after writing a good bit of Rust code and understanding what everything is doing at a glance.
  - kid0m4n 12y ago
    The Rust code in this example looks extremely busy. A lot of cognitive load for the sake of performance and safety. Also what is stopping a LLVM backend for Go being developed?
arthursilva 12y ago
Most of the complexity in this code is due to parallelism and in fact it would be prettier these days (it's moving fast). A plain simple version (like the go) one is likely to be even simpler due to the functional aspect in rust.
- igouy 12y ago
  Please contribute what you consider to be plain simple Rust programs.

TheHydroImpulse 12y ago

It's highly unlikely Go will be able to compete in terms of compiler optimizations because of it's goal of fast compilation speeds. The majority of the time Rust spends compiling code is within LLVM last time I checked, because LLVM does quite a bit of optimizations. Then if you take into account the fact that Go's language features do not promote highly-performant code (GC, heap allocation, dynamic dispatching) that a few people in this thread has touched on. While better looking code is highly subjective, Rust has indeed traded off some aesthetics for safety, performance, etc... However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust.

lazyjones 12y ago
> It's highly unlikely Go will be able to compete in terms of compiler optimizations because of it's goal of fast compilation speeds. For a given piece of code as written today, its compilation speed will naturally improve over time as processors get faster. Optimizing it to a certain degree becomes faster for the same reason. Therefore, assuming a fixed threshold for what constitutes "fast [enough] compilation", potential for more optimizations becomes available over time. > However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust. That's true for many languages, including PHP or Perl. The problem is: once you use these languages more, you discover that most people don't do it (for various reasons, one of them often being that they're trying to be clever).

shadowmint 12y ago

If you judge your programming languages based on personal aesthetics of the 'beauty of the code', you're wondering off into lala land. Go has a better syntax that rust, objectively, because it refuses to create new operators that are not orthogonal to existing ones. That makes it easier to parse because there are fewer 'code synonyms' (eg. the rust Fn<(Arg1, Arg2), (Rtn)> is identical to Fn<Args, Arg2> -> Rtn; to be fair go has its share of these irritations as well; eg. x := 1, vs var x = 1; but fewer of them) It's got nothing to do with how pretty or ugly the code is.

bwilliams 12y ago
It also starts looking better aesthetically after writing a good bit of Rust code and understanding what everything is doing at a glance.
- kid0m4n 12y ago
  The Rust code in this example looks extremely busy. A lot of cognitive load for the sake of performance and safety. Also what is stopping a LLVM backend for Go being developed?

arthursilva 12y ago

Most of the complexity in this code is due to parallelism and in fact it would be prettier these days (it's moving fast). A plain simple version (like the go) one is likely to be even simpler due to the functional aspect in rust.

igouy 12y ago
Please contribute what you consider to be plain simple Rust programs.