5 ms·

I don't know how to put this politely. There's nothing simple about Rust. The compiler is complex and slow. The borrower semantics is anything but simple. I

by hu3 7y ago

I don't know how to put this politely. There's nothing simple about Rust. The compiler is complex and slow. The borrower semantics is anything but simple. It isn't uncommon for the syntax to look arcane. The standard library is shallow often making developers have to resort to third party libraries for trivial things. Rust improved upon languages like Cyclone but it's a far cry from being the next C/C++ when it comes to potential market adoption.

samatman 7y ago
I upvoted you for the first six lines, while feeling compelled to chime in that cargo is great, an example of Rust doing things right imho. I'd rather have a thriving and single (looking at you Python) ecosystem of third-party packages, than a standards-driven pile-on of standard libraries, with all the footguns and deprecation that tends to come with it.
roblabla 7y ago
Rust definitely has a lot to improve on. I'm a daily Rust user, and the compile times are still absolutely terrible, and I have to agree it isn't a simple language for any sane definition of simple. That said: almost all your points apply to C++. There's nothing simple about C++. it can be incredibly complex and slow (though faster than Rust, but that's not much of an achievement). The rules around what constitutes valid (non-UB) code is anything but simple. It isn't uncommon for the syntax to look arcane (IMO much more so than Rust, although obviously YMMV). The standard library is extremely shallow, making developers have to resort to third party libraries for trivial things, except there's no package manager or standard build system, so good luck with that. And yet, here we are, with C++ dominating the market. So I don't think any of those reasons are dealbreakers at all. I believe Rust has the potential for market adoption as a serious C++ competitor. It still has a long road to get there, but C++ didn't reach this point in a day either. We see more and more adoption in big companies of Rust. Microsoft recently expressed interest in using rust in critical components to reduce security bugs for instance. More and more companies are experimenting with Rust, and some are even using it in production. Besides, there's another victory to Rust: more and more languages are looking into integrating borrow semantics in their own language, like swift[0]. This is proof that Rust's core ideas work. If those trickle down to other languages, the "complexity" of borrows will probably become just one of the other things you just have to get used to to learn programming. [0]: https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md https://github.com/apple/swift/blob/master/docs/OwnershipMan...
- fao_ 7y ago
  > That said: almost all your points apply to C++. And nobody here said C++ was a good language. Actually, is it even considered a systems programming language?
  - kllrnohj 7y ago
    > Actually, is it even considered a systems programming language? Yes, absolutely. It's really not even under any sort of doubt at all..?
  - jandrewrogers 7y ago
    C++ is absolutely a systems language and widely used for that purpose. Indeed, I would argue it is the primary use case for which it is well-suited these days. In 2019 there are few if any reasonable alternatives for writing software like high-performance database engines, so C++ essentially wins by default.
Diggsey 7y ago
> The compiler is complex and slow. It doesn't mean that the language is complex. > The borrower semantics is anything but simple. The borrow checker doesn't change the meaning of the program in any way. You can perfectly understand Rust code without any knowledge of the borrow checker (there is a working Rust compiler that doesn't even have a borrow checker), so it cannot make the semantics of the language more complicated. > It isn't uncommon for the syntax to look arcane. Again, I did call out the syntax has being moderately complicated. The great thing about syntax is that it's superficial. Syntax has to be pretty bad to continue being an issue beyond the initial stages of learning a language, and I don't think Rust's syntax is close to being that bad, it just has some unfamiliar elements to a lot of people. > The standard library is shallow often making developers have to resort to third party libraries for trivial things. This sits on the "Rust is simple" side. > Rust improved upon languages like Cyclone but it's a far cry from being the next C/C++ when it comes to potential market adoption. In terms of actual market adoption I'd agree. But you said potential market adoption, so I don't.
- wbl 7y ago
  You don't think the type system is part of language semantics?
  - Tuna-Fish 7y ago
    The borrow/lifetime system never changes the behavior of any program, the only thing it can do is to disallow some programs from compiling. This is not how the rest of the type system works. This means that it's possible to write a compiler that correctly compiles all correct rust programs without having a lifetime system at all. It also means that having the lifetime system in makes writing programs more complicated, but it makes reading them, and understanding what a program does, easier.
    - wbl 7y ago
      Ownership is linear types. It's part of the type system.
lyricaljoke 7y ago
The borrower semantics is anything but simple. I keep seeing people saying this when discussing Rust in relation to C++. It's not untrue, but I would counter by saying that people who were writing C++ without having a full understanding of ownership and lifetime semantics were writing buggy code. Rust just makes understanding those semantics required to get your code to compile.
- atombender 7y ago
  There are many other instances where ownership/lifetimes kick in in ways that would not be a problem in a different language. Anywhere you have any kind of containment hiearchy, Rust starts becoming more invasive than other languages. In languages like Go, you can have complex graphs of objects referring to each other, and you can — often arguably safely — work with these structures without thinking about who owns what. As an example of something that got me stuck, I recently had some code that populated a map of mutable buffers: struct Builder { buffers: BTreeMap<Term, RefCell<PostingBuffer>>, } At the end of the building, it needs to flush the buffers, in key order, to a file and then empty the map so it can be reused. Turns out this is trickier than expected because the map owns its contents, so you can't take ownership of the RefCell that wraps the buffers: for (term, buf) in &self.buffers { // into_inner consumes buf, so it moves; fails with "Cannot move out of borrowed context" let data = buf.into_inner().get_data(); w.write(term, data)?; } self.buffers = BTreeMap::new(); In the end, the trick was to replace the map for the iteration: for (term, v) in std::mem::replace(&mut self.buffers, BTreeMap::new()) { let data = v.into_inner().get_data(); w.write(term, data)?; } Initially I used a HashMap to optimize for build speed, then sorted its keys at the end. This was also a challenge, because maps apparently have no way of getting a copy of the keys by value. (There might be an easier way, but again, this just illustrates the learning curve for new developers.) In the end, I chose BTreeMap so the keys are already sorted. This is all probably entirely obvious to Rust experts, but not so to new developers. Swapping out the entire map with std::mem::replace() would never have occurred to me. Even if you understand borrowing in principle, you have think about a container means in terms of borrowing, and how stuff will move in and out of a container. And you have to design the way you interact with them accordingly. In principle, I think this awareness is a good thing, and that the resultant code will be smarter and more optimal as a result, but at the same time, it doesn't make for such an ergonomic developer experience; so far it's been a drain on my productivity more than a gain. I like to say that Rust "scales down" towards the low levels, but does less well "scaling up"; you can't write high-level code without also thinking about the low levels, when even things like the size of your data type is always in your face. My solution above may not even be the most optimal, idiomatic way of doing things. I'm sure someone will come along and point out that there's a trick involving using something other than RefCell or whatever that simplifies everything. Not necessarily a criticism of Rust, just a data point in terms of complexity and learning curve.
gameswithgo 7y ago
I agreed with everything you said except: >but it's a far cry from being the next C/C++ when it comes to potential market adoption. Because C++ is very similarly complex/arcane etc.
ernst_klim 7y ago
>Rust improved upon languages like Cyclone but it's a far cry from being the next C/C++ I was with you till this point. Rust is ugly, complex, but far batter that C++ in this regards. * Functions instead of 666 constructors with obscure rules of which you should implement in pairs * Hygienic macros instead of that ugly unsafe mess in C and C++ called macro and templates * Move by default and Copy by calling a copy() function * Everything is so explicit
kzrdude 7y ago
For a C programmer, Rust's standard library is gigantic. And the cargo story is one of Rust's strongest points, how easy it is to handle dependencies. But the best parts of Rust are its move semantics, enum datatypes and traits, everything that makes programs a joy to express.

by hu3 7y ago

samatman 7y ago

I upvoted you for the first six lines, while feeling compelled to chime in that cargo is great, an example of Rust doing things right imho. I'd rather have a thriving and single (looking at you Python) ecosystem of third-party packages, than a standards-driven pile-on of standard libraries, with all the footguns and deprecation that tends to come with it.

roblabla 7y ago

Rust definitely has a lot to improve on. I'm a daily Rust user, and the compile times are still absolutely terrible, and I have to agree it isn't a simple language for any sane definition of simple. That said: almost all your points apply to C++. There's nothing simple about C++. it can be incredibly complex and slow (though faster than Rust, but that's not much of an achievement). The rules around what constitutes valid (non-UB) code is anything but simple. It isn't uncommon for the syntax to look arcane (IMO much more so than Rust, although obviously YMMV). The standard library is extremely shallow, making developers have to resort to third party libraries for trivial things, except there's no package manager or standard build system, so good luck with that. And yet, here we are, with C++ dominating the market. So I don't think any of those reasons are dealbreakers at all. I believe Rust has the potential for market adoption as a serious C++ competitor. It still has a long road to get there, but C++ didn't reach this point in a day either. We see more and more adoption in big companies of Rust. Microsoft recently expressed interest in using rust in critical components to reduce security bugs for instance. More and more companies are experimenting with Rust, and some are even using it in production. Besides, there's another victory to Rust: more and more languages are looking into integrating borrow semantics in their own language, like swift[0]. This is proof that Rust's core ideas work. If those trickle down to other languages, the "complexity" of borrows will probably become just one of the other things you just have to get used to to learn programming. [0]: https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md https://github.com/apple/swift/blob/master/docs/OwnershipMan...

fao_ 7y ago
> That said: almost all your points apply to C++. And nobody here said C++ was a good language. Actually, is it even considered a systems programming language?
- kllrnohj 7y ago
  > Actually, is it even considered a systems programming language? Yes, absolutely. It's really not even under any sort of doubt at all..?
- jandrewrogers 7y ago
  C++ is absolutely a systems language and widely used for that purpose. Indeed, I would argue it is the primary use case for which it is well-suited these days. In 2019 there are few if any reasonable alternatives for writing software like high-performance database engines, so C++ essentially wins by default.

Diggsey 7y ago

> The compiler is complex and slow. It doesn't mean that the language is complex. > The borrower semantics is anything but simple. The borrow checker doesn't change the meaning of the program in any way. You can perfectly understand Rust code without any knowledge of the borrow checker (there is a working Rust compiler that doesn't even have a borrow checker), so it cannot make the semantics of the language more complicated. > It isn't uncommon for the syntax to look arcane. Again, I did call out the syntax has being moderately complicated. The great thing about syntax is that it's superficial. Syntax has to be pretty bad to continue being an issue beyond the initial stages of learning a language, and I don't think Rust's syntax is close to being that bad, it just has some unfamiliar elements to a lot of people. > The standard library is shallow often making developers have to resort to third party libraries for trivial things. This sits on the "Rust is simple" side. > Rust improved upon languages like Cyclone but it's a far cry from being the next C/C++ when it comes to potential market adoption. In terms of actual market adoption I'd agree. But you said potential market adoption, so I don't.

wbl 7y ago
You don't think the type system is part of language semantics?
- Tuna-Fish 7y ago
  The borrow/lifetime system never changes the behavior of any program, the only thing it can do is to disallow some programs from compiling. This is not how the rest of the type system works. This means that it's possible to write a compiler that correctly compiles all correct rust programs without having a lifetime system at all. It also means that having the lifetime system in makes writing programs more complicated, but it makes reading them, and understanding what a program does, easier.
  - wbl 7y ago
    Ownership is linear types. It's part of the type system.

lyricaljoke 7y ago

The borrower semantics is anything but simple. I keep seeing people saying this when discussing Rust in relation to C++. It's not untrue, but I would counter by saying that people who were writing C++ without having a full understanding of ownership and lifetime semantics were writing buggy code. Rust just makes understanding those semantics required to get your code to compile.

atombender 7y ago
There are many other instances where ownership/lifetimes kick in in ways that would not be a problem in a different language. Anywhere you have any kind of containment hiearchy, Rust starts becoming more invasive than other languages. In languages like Go, you can have complex graphs of objects referring to each other, and you can — often arguably safely — work with these structures without thinking about who owns what. As an example of something that got me stuck, I recently had some code that populated a map of mutable buffers: struct Builder { buffers: BTreeMap<Term, RefCell<PostingBuffer>>, } At the end of the building, it needs to flush the buffers, in key order, to a file and then empty the map so it can be reused. Turns out this is trickier than expected because the map owns its contents, so you can't take ownership of the RefCell that wraps the buffers: for (term, buf) in &self.buffers { // into_inner consumes buf, so it moves; fails with "Cannot move out of borrowed context" let data = buf.into_inner().get_data(); w.write(term, data)?; } self.buffers = BTreeMap::new(); In the end, the trick was to replace the map for the iteration: for (term, v) in std::mem::replace(&mut self.buffers, BTreeMap::new()) { let data = v.into_inner().get_data(); w.write(term, data)?; } Initially I used a HashMap to optimize for build speed, then sorted its keys at the end. This was also a challenge, because maps apparently have no way of getting a copy of the keys by value. (There might be an easier way, but again, this just illustrates the learning curve for new developers.) In the end, I chose BTreeMap so the keys are already sorted. This is all probably entirely obvious to Rust experts, but not so to new developers. Swapping out the entire map with std::mem::replace() would never have occurred to me. Even if you understand borrowing in principle, you have think about a container means in terms of borrowing, and how stuff will move in and out of a container. And you have to design the way you interact with them accordingly. In principle, I think this awareness is a good thing, and that the resultant code will be smarter and more optimal as a result, but at the same time, it doesn't make for such an ergonomic developer experience; so far it's been a drain on my productivity more than a gain. I like to say that Rust "scales down" towards the low levels, but does less well "scaling up"; you can't write high-level code without also thinking about the low levels, when even things like the size of your data type is always in your face. My solution above may not even be the most optimal, idiomatic way of doing things. I'm sure someone will come along and point out that there's a trick involving using something other than RefCell or whatever that simplifies everything. Not necessarily a criticism of Rust, just a data point in terms of complexity and learning curve.

gameswithgo 7y ago

I agreed with everything you said except: >but it's a far cry from being the next C/C++ when it comes to potential market adoption. Because C++ is very similarly complex/arcane etc.

ernst_klim 7y ago

>Rust improved upon languages like Cyclone but it's a far cry from being the next C/C++ I was with you till this point. Rust is ugly, complex, but far batter that C++ in this regards. * Functions instead of 666 constructors with obscure rules of which you should implement in pairs * Hygienic macros instead of that ugly unsafe mess in C and C++ called macro and templates * Move by default and Copy by calling a copy() function * Everything is so explicit

kzrdude 7y ago

For a C programmer, Rust's standard library is gigantic. And the cargo story is one of Rust's strongest points, how easy it is to handle dependencies. But the best parts of Rust are its move semantics, enum datatypes and traits, everything that makes programs a joy to express.