Hacker News Reader

Comment by WinstonSmith84 | Hacker News Reader

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

View on HN

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.

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.

so you want Go then?

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.)

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.

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.

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.

What language features would you like to take away from Rust?

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.

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.

Go is fast, cgo is slow. Cgo is also annoying to set up on windows. It kills the simplicity of a simple go build.

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.

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.

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.

For the vast majority of programs most time is spent in code generation/optimization. Rusts static analysis is not why compilation is slow.

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.

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.

It seems obvious to me that eventually someone is going to write a compiler for a language that delivers on rust's main value propositions (fast native code/memory safety/data race protection) but that compiles at least 10x faster than rust for most problems. Initially the generated code might be somewhat slower than rust on average, but I think developers will find they would happily trade some runtime perf for such a dramatic compile time improvement. The runtime performance gap will also narrow over time and eventually probably even supplant rust for most common problems. Rust itself is already too complex and weighed down by many competing interests that will prevent it from being the best possible version of itself. But it also has many self owns such as objectively bad syntactic decisions (like angle brackets for generics) that were made to appease intransigent c programmers.

Yeah; a simpler language would also be easier to learn. Rust is experimenting with an awful lot of new ideas. I imagine rust's successor (whenever that happens) will take the best ideas from rust - including the best design for a borrow checker - and build a much simpler language around that.

Rust is the first language in its category. It won't be the best language we ever make in that category.

Reply on news.ycombinator.com