4 ms·

Once you're done fighting with the compiler (Rust Analyzer), it's actually very enjoyable and one can be _relatively_ productive. The language allows so much fl

Once you're done fighting with the compiler (Rust Analyzer), it's actually very enjoyable and one can be _relatively_ productive. The language allows so much flexibility that it's very easy to produce well organized code... But the compiler is really slow. Even an incremental build on a mid size project is never below 10s, whereas on a similar size project, Golang will take me less than 1 second to build incrementally. Also, I find cross-compilation (from/to major platforms) really challenging on Rust, as opposed to Golang where it's for my use cases super straightforward

stefncb 4y ago
My personal issue with Rust isn't the borrow checker. I actually find it quite intuitive. What I don't like is the extreme complexity of everything. There's just so much... stuff. What I want is a Rust, but with almost everything stripped away. Complexity similar to Go.
- TylerE 4y ago
  nim comes the closest of anything I've found, the infrastructure just isn't quite there. ocaml has potential but I strongly dislike the numeric operators, and I'm not a huge fan of the syntax in general. OCaml with python like syntax would be damn near perfect. I could even overlook the operator thing.
- acedTrex 4y ago
  so you want Go then?
- oconnor663 4y ago
  It's worth pointing out that if you say "Go except with Rust's guarantees for thread safety", a _lot_ of the complexity comes back. You need to pull in lifetimes and move semantics and the no-mutable-aliasing rule. You need the Send and Sync traits. You probably want Deref-based smart pointers too. (And you'd need to make extensive use of the new generics features that are already in Go.)
  - stefncb 4y ago
    That's not what I'm saying. I want rust, but with the simplicity of go. I want a compiler that's super portable and it itself compiles in a few minutes. I want a straightforward build system that doesn't leave me confused. I want less language features. I also want a more lightweight syntax but beggars can't be choosers.
    - majewsky 4y ago
      You can only add so many constraints to a problem until it becomes unsolvable. It's like saying "I would like to have a non-volatile storage device that is as long-lasting as microfilm, as fast as an SSD and as cheap as a HDD." At some point, you have to renege on at least one of your constraints.
      - stefncb 4y ago
        Fair point, but I don't think my constraints are _that_ extreme. I think it's doable, but we'll never know unless someone seriously attempts it.
        nequo 4y ago
        What language features would you like to take away from Rust?
- the_mitsuhiko 4y ago
  I would be quite impressed if there was a way to have Rust with "less stuff". It's not like there is a lot stuff that can be removed without making the language quite useless.
- jug 4y ago
  I just use Go (or Nim) for native. It’s not comparable in goals and what Rust tries to do at all. But Go compiles super fast, is very fast, solves the glaring C safety issues, very keen on helping you with threads, and has a very fast garbage collector. If I run into performance problems, it’s not because of Go. But yeah Rust has its place in certain scenarios. I still hesitate to call it general purpose though — I think it’s best suited for stuff that underpins applications/usermode. And I don’t think it can be made much less obnoxious.
  - stefncb 4y ago
    Go is fast, cgo is slow. Cgo is also annoying to set up on windows. It kills the simplicity of a simple go build.
- nneonneo 4y ago
  Memory management is hard. Thread safety is hard. Go (and Java, Python, …) pushes the complexity of the former to a GC, which has its own drawbacks. Few popular languages actually tackle the latter - most languages have safety problems there such as race conditions (in Go, Python, Java, etc.) This is not to deny that Rust also has other sources of complexity. But, most of Rust’s complexity can be traced to its fundamental goals of safety and performance. If you’re willing to sacrifice one of those, there are much simpler and easier languages to use.
agumonkey 4y ago
I don't have much experience but after writing some tiny rust scripts and similar sized things in kotlin (trying kotlinc v1.7 that was supposed to be a lot faster than previous versions), rust managed to stay ahead. it's true golang is smoother, but the language is a lot messier (idioms and typechecking). Can't conclude anything yet, but it makes me think back of rust more often than others.
tcmart14 4y ago
The slow compile times I look at as a trade off. Rust does a lot more during it's compile phase than most other compilers and there is a cost. Do I do all this static analysis and eat time here to hopefully reduce runtime bugs and subsequently the time to debug runtime bugs? It takes me a whole lot longer to debug something with a debugger than if the compiler can catch it. I do 100% agree on your commends on cross compiling though. I also don't like how the target for linux has "unknown" in it.
- Thiez 4y ago
  For the vast majority of programs most time is spent in code generation/optimization. Rusts static analysis is not why compilation is slow.
  - zarzavat 4y ago
    Optimisation happens in release builds. I assume when people talk about compilation speed they mean debug builds because those are the ones you have to wait for. For me the biggest hurdle to adopting Rust is that rust-analyser turns my laptop's fans up to 11. I don't know whose problem that is, but it doesn't happen with other languages, and my black box impression of rust's compilation infrastructure is that it's fucked up.
  - josephg 4y ago
    Yeah … I’ve done a lot of optimization work. (I love that sort of thing). I have an instinct that there’s at least an order of magnitude compilation performance gain possible with a different architecture for the compiler. Especially if you didn’t bother implementing a lot of llvm’s optimizations. It’s just tricky because writing a new rust compiler is a monster amount of work because of how complex Rust is. And rearchitecting the existing compiler would also be a massive undertaking because there’s so much existing code, and it’s spread over rustc (written in rust) and llvm (in C++). A faster compiler probably wouldn’t bother with all of llvm’s intermediate representations. Refactoring across a code boundary that spans two languages (and two projects) sounds utterly exhausting.
    - 4y ago

stefncb 4y ago

My personal issue with Rust isn't the borrow checker. I actually find it quite intuitive. What I don't like is the extreme complexity of everything. There's just so much... stuff. What I want is a Rust, but with almost everything stripped away. Complexity similar to Go.

TylerE 4y ago
nim comes the closest of anything I've found, the infrastructure just isn't quite there. ocaml has potential but I strongly dislike the numeric operators, and I'm not a huge fan of the syntax in general. OCaml with python like syntax would be damn near perfect. I could even overlook the operator thing.
acedTrex 4y ago
so you want Go then?
oconnor663 4y ago
It's worth pointing out that if you say "Go except with Rust's guarantees for thread safety", a _lot_ of the complexity comes back. You need to pull in lifetimes and move semantics and the no-mutable-aliasing rule. You need the Send and Sync traits. You probably want Deref-based smart pointers too. (And you'd need to make extensive use of the new generics features that are already in Go.)
- stefncb 4y ago
  That's not what I'm saying. I want rust, but with the simplicity of go. I want a compiler that's super portable and it itself compiles in a few minutes. I want a straightforward build system that doesn't leave me confused. I want less language features. I also want a more lightweight syntax but beggars can't be choosers.
  - majewsky 4y ago
    You can only add so many constraints to a problem until it becomes unsolvable. It's like saying "I would like to have a non-volatile storage device that is as long-lasting as microfilm, as fast as an SSD and as cheap as a HDD." At some point, you have to renege on at least one of your constraints.
    - stefncb 4y ago
      Fair point, but I don't think my constraints are _that_ extreme. I think it's doable, but we'll never know unless someone seriously attempts it.
      - nequo 4y ago
        What language features would you like to take away from Rust?
the_mitsuhiko 4y ago
I would be quite impressed if there was a way to have Rust with "less stuff". It's not like there is a lot stuff that can be removed without making the language quite useless.
jug 4y ago
I just use Go (or Nim) for native. It’s not comparable in goals and what Rust tries to do at all. But Go compiles super fast, is very fast, solves the glaring C safety issues, very keen on helping you with threads, and has a very fast garbage collector. If I run into performance problems, it’s not because of Go. But yeah Rust has its place in certain scenarios. I still hesitate to call it general purpose though — I think it’s best suited for stuff that underpins applications/usermode. And I don’t think it can be made much less obnoxious.
- stefncb 4y ago
  Go is fast, cgo is slow. Cgo is also annoying to set up on windows. It kills the simplicity of a simple go build.
nneonneo 4y ago
Memory management is hard. Thread safety is hard. Go (and Java, Python, …) pushes the complexity of the former to a GC, which has its own drawbacks. Few popular languages actually tackle the latter - most languages have safety problems there such as race conditions (in Go, Python, Java, etc.) This is not to deny that Rust also has other sources of complexity. But, most of Rust’s complexity can be traced to its fundamental goals of safety and performance. If you’re willing to sacrifice one of those, there are much simpler and easier languages to use.

agumonkey 4y ago

I don't have much experience but after writing some tiny rust scripts and similar sized things in kotlin (trying kotlinc v1.7 that was supposed to be a lot faster than previous versions), rust managed to stay ahead. it's true golang is smoother, but the language is a lot messier (idioms and typechecking). Can't conclude anything yet, but it makes me think back of rust more often than others.

tcmart14 4y ago

The slow compile times I look at as a trade off. Rust does a lot more during it's compile phase than most other compilers and there is a cost. Do I do all this static analysis and eat time here to hopefully reduce runtime bugs and subsequently the time to debug runtime bugs? It takes me a whole lot longer to debug something with a debugger than if the compiler can catch it. I do 100% agree on your commends on cross compiling though. I also don't like how the target for linux has "unknown" in it.

Thiez 4y ago
For the vast majority of programs most time is spent in code generation/optimization. Rusts static analysis is not why compilation is slow.
- zarzavat 4y ago
  Optimisation happens in release builds. I assume when people talk about compilation speed they mean debug builds because those are the ones you have to wait for. For me the biggest hurdle to adopting Rust is that rust-analyser turns my laptop's fans up to 11. I don't know whose problem that is, but it doesn't happen with other languages, and my black box impression of rust's compilation infrastructure is that it's fucked up.
- josephg 4y ago
  Yeah … I’ve done a lot of optimization work. (I love that sort of thing). I have an instinct that there’s at least an order of magnitude compilation performance gain possible with a different architecture for the compiler. Especially if you didn’t bother implementing a lot of llvm’s optimizations. It’s just tricky because writing a new rust compiler is a monster amount of work because of how complex Rust is. And rearchitecting the existing compiler would also be a massive undertaking because there’s so much existing code, and it’s spread over rustc (written in rust) and llvm (in C++). A faster compiler probably wouldn’t bother with all of llvm’s intermediate representations. Refactoring across a code boundary that spans two languages (and two projects) sounds utterly exhausting.
  - 4y ago