Go has the same distinction (stack vs heap), but the GC means you don't need to care about the lifetime of the data.
To your other point, it saddens me that Rust isn't well-suited to higher level applications. You need very strict performance requirements before it makes sense to pick Rust over Go (you can squeeze a lot of performance out of Go, and even optimizing Go is friendlier than writing naive Rust IMHO).
I think this might depend a lot on how you approach Rust. I find the functional/procedural mixture to work nicely, and find I'm much more productive in Rust than Go (or Python or Java, modulo available libraries). I'm writing web services and code generators, so not particularly low-level code.
I've written a decent bit of Go, and I understand why a lot of people like it, but I don't think it's inherently better for application development.
Maybe, but I think your case is atypical. I came from a C++ background, so I'm well-acquainted with navigating a huge feature matrix and thinking about memory management, but I'm still much more productive in Go simply because the feature matrix is always very small and I only need to think about memory management in hot paths.
I want to be comparatively productive in Rust, I just never seem to get there because of the huge volume of decisions (even if the decisions are mostly easy) that need to be made for even straightforward code units. I think what I really want is Rust lite, or Go with generics and abstract data types.
I could absolutely be atypical; prior to using Go and Rust as my main tools, I primarily wrote Scala, and I'm sure the functional and type-driven approaches have left deep grooves. But that would still be a way of approaching working with Rust, wouldn't it?
None of that is to make a value judgement, just an observation; but I would still argue that the language can be used in a highly productive manner. Nonetheless, it's perfectly reasonable to argue it's not worth adapting to it, especially if Go is already solving your problems and keeping you productive. I switched because Go's design doesn't seem to fit me very well, and I continually tripped on issues that I don't encounter in Rust. (So yes, perhaps I'm quite odd.)
I do understand the want for a Rust-lite; the thought has crossed my mind more than once. So far, Swift seems closest in many ways and may get close once the Linux/cross-platform story starts looking good.
> I could absolutely be atypical; prior to using Go and Rust as my main tools, I primarily wrote Scala.
I'm not saying Rust is easy, but I have also a long Scala and some Haskell background which made it easier to learn Rust. For me the hardest part was that I've never really wrote any proper C++ or C, although I could read them quite good. Refereneces and RAII caused some gray hairs, the type system not that much.
> I just never seem to get there because of the huge volume of decisions (even if the decisions are mostly easy) that need to be made for even straightforward code units.
Well this is true for all languages! You need to think hard for every decision you take with languages like Ruby or Python. Things like how will this look like after a year, will the junior developer be able to extend it, will there be data races and so on.
Rust just enforces you to do this. And it makes life much easier when you don't need to worry about some silly mistakes you made, because the compiler will catch them.
Rust has a brilliant solution for some really burdensome issues that C++ developers have. A lot of C++ code tends to make assumptions about ownership and lifetimes that are not formally spelled out anywhere in the code. It's all over the place, it increases cognitive load, it makes the code brittle and less modular than it could be. Rust fixes that without negatively affecting performance whereas all C++ workarounds like shared_ptr and defensive copying are incomplete and/or have a negative performance impact.
But Rust also insists on enforcing its ownership rules between variables within the local scope where it doesn't help much and feels needlessly restrictive and convoluted. I can't say I know Rust well enough to tell whether working under these restrictions can become second nature and stop being a burden.
Also, users of garbage collected languages don't have many of the ownership and lifetime issues that C++ developers are forced to think about. Especially where objects are immutable, ownership is not a concern at all.
So I think Rust is an answer to one question: How can I have detailed control over resources like in C++ without inheriting all the hazards of C++ as well.
While I agree that programming necessarily involves a lot of decisions, I hope we can agree that there is a spectrum of complexity among programming languages. My point is that the likes of Rust and C++ introduce a huge volume of decisions that wouldn't exist in a simpler language, like Go. That said, if you think all languages are as complex as C++, I'm not sure we can agree on much...
Yes, it does have the distinction. From your link:
> When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors.
As you can see, Go uses both the stack and the heap; however, unlike Rust, it doesn't require users to know where their variables live to write correct programs.
I believe, the distinction that orclev mentioned was that in Rust, you specifically have to be aware when something is allocated to the stack or heap, but in Go, you don't have to since the compiler deals with it. Obviously Go allocates to both stack and heap, it's just that the user doesn't need to know which.
Fair enough. I simply meant that Go's semantics let you reason about what lives on the stack vs what lives on the heap much like you can in Rust (though in Rust it's clearer still because there is no escape analysis at all). While you don't need to know from a correctness perspective, you can reliably reason about what will live on the stack vs heap in a way you can't in, say, Java.
No, you can't really reason properly about what lives on the stack. As the Go FAQ say, you can safely assume a variable will be allocated on the stack if you never take a reference of it, but that's not always clear as it seems. For instance, if you call a method on your variable, you can't immediately know by looking at the method whether the receiver is by-reference (pointer receiver) or by value. If you're using a pointer receiver, the variable's address may be taken, so the compiler has to perform escape analysis.
Once you take the address and escape analysis is performed, you've got no way to easily reason about what's on the stack vs. what's on the heap, without delving into the gory implementation details which may be changed in future versions.
Since Go isn't C++ and doesn't have a huge and complicated standard that guarantees compiler optimizations, you can't really reason about what's going on.
This is essentially the same situation as Java, although the Hotspot JVM's escape analysis is probably less 'basic'.
That is one reason to choose Rust, but that is far from the only reason to prefer Rust over Go. I've found that algebraic data types and pattern matching have become irreplaceable parts of my programming toolbox, to the point it is painful to work without them. Rust also has a powerful macro system that Go cannot match.
This is not to say that Rust is better than Go in every way, but performance is far from the only facet when I compare the two.
To your other point, it saddens me that Rust isn't well-suited to higher level applications. You need very strict performance requirements before it makes sense to pick Rust over Go (you can squeeze a lot of performance out of Go, and even optimizing Go is friendlier than writing naive Rust IMHO).