5 ms·

Apparently I’m pretty much alone in thinking that Rust is a clumbsy, messy language. The syntax is all over the place. You get the feeling that there’s no desig

Apparently I’m pretty much alone in thinking that Rust is a clumbsy, messy language. The syntax is all over the place. You get the feeling that there’s no design strategy and than anyone with half an idea is allowed to bolt on features.

jolux 6y ago
Rust’s syntax is definitely complicated and that’s one of my least favorite things about it but it’s extremely consistent. What gives you the “all over the place” feeling?
- mrweasel 6y ago
  I don’t really agree that it consistent, but maybe you’re right that it just complicated. There are so many different syntaxes for all sorts of features that you can’t really hold it all in your head. It’s been a year since I last gave Rust a try, in the mean time I’ve been able to pick Go without much effort. Rust just seem like PHP, it’s fast, featurefull but not thought through.
  - nindalf 6y ago
    You're assuming that it was difficult to learn because the features weren't thought through. Have you considered that maybe it was because there were genuinely new concepts not present in other languages?
    - stouset 6y ago
      Yeah, if anything, Rust feels to me like it's incredibly well thought through. All the pieces fit together well precisely as if they were all thought of as a whole. It's "hard" because it forces you to consider an entirely new constraint of your programs upfront. But (almost) every piece composes nicely with every other piece in a way that makes Rust development extremely pleasant. Golang feels like the opposite, in that none of the parts are actually built to work with one another. Tuple returns exist but there are no language features that allow you to actually work with them. There's a strong type system, but you have to break out of it with interface{} and type punning to solve entire classes of common problems. Type punning exists, but go can't prove exhaustiveness of switch statements so doing this opens further gaping holes. Errors are handled explicitly everywhere, but again there are no tools to handle the repetitive lifting so every program becomes an endless series of error handling occasionally interrupted by bits of program logic. And let's not forget how badly interface pointers interact with nils: comparing a nil interface pointer against nil returns false, so a basic nil-check that works everywhere else fails to actually perform correctly when dealing with interfaces.
steveklabnik 6y ago
> anyone with half an idea is allowed to bolt on features. I know you're talking about feel here, not about process, but to be clear, while we do have a pretty open and fairly democratic process, and while anyone can propose a feature, only the language team members, which is currently five folks, can decide to say "yes" to a proposal. The team may have been plus or minus a few over the years, but it's never been particularly large. (We generally feel this process works well to balance all these factors; we want everyone's good ideas, but we also have to maintain coherence. An open suggestion process with a closed selection process has worked well in our eyes, but everyone can feel differently, of course.)
derefr 6y ago
I’m guessing you’ve looked more at Rust code that uses incubating features from Rust nightly. Most of those features don’t make it to stable—or if they do, their syntax has usually been refined by the time they do. Inconveniently, a lot of the Rust code examples you’ll run into on HN uses incubating features, because a lot of the people posting about Rust on HN are language researchers talking about how they were finally able to implement new language feature/performance optimization/safety guarantee X using incubating language feature Y; or how they think nascent library Foo’s use of incubating language feature Z is/isn’t a good idea. All that is inside baseball. It looks nothing like day-to-day Rust code, any more than e.g. .NET CLR static analysis code looks like day-to-day C#. (Also, there’s the code examples of Rust stdlib code, which is like C++ STL code in that you have to use arcane language features “in anger” to bootstrap the language — e.g. safe concurrent data structures must necessarily at some point rely on unsafe code.) (Or it’s code for a Rust unikernel / OS device driver / etc, because that’s a thing you can do. But it’s a still-nascent thing you can do, that’s not yet as ergonomic as regular code that can rely on virtual memory to exist. You have to build the safety yourself in such cases, or rely on a library that does; and there are no such libraries that have yet reached high code quality + wide cross-platform applicability.)
- nyanpasu64 6y ago
  Rust stdlib code is a lot nicer to read than C++ stdlib code, which relies on _Mangled names to prevent conflicts, and (ab)uses template metaprogramming, SFINAE, overloading, & and && and forwarding, etc. heavily. Though Rust's trait system results in indirections comparable to (but somewhat more manageable than) C++ SFINAE/overloading/type traits. And some Rust stdlib types delegate to compiler intrinsics rather than being implemented in unsafe Rust (forgot which). Additionally, third-party Rust data structure/concurrency crates often contain unsafe code comparable to Rust's stdlib in complexity. (And device drivers, as you mentioned, are probably highly unsafe too.)
onei 6y ago
Is that because Rust is an expression language? As much as I like Rust, I do find that returning variables from conditionals or match expressions can feel a little jarring (especially when you combine the two). In other places though, it really shines and just requires a little discipline.

jolux 6y ago

Rust’s syntax is definitely complicated and that’s one of my least favorite things about it but it’s extremely consistent. What gives you the “all over the place” feeling?

mrweasel 6y ago
I don’t really agree that it consistent, but maybe you’re right that it just complicated. There are so many different syntaxes for all sorts of features that you can’t really hold it all in your head. It’s been a year since I last gave Rust a try, in the mean time I’ve been able to pick Go without much effort. Rust just seem like PHP, it’s fast, featurefull but not thought through.
- nindalf 6y ago
  You're assuming that it was difficult to learn because the features weren't thought through. Have you considered that maybe it was because there were genuinely new concepts not present in other languages?
  - stouset 6y ago
    Yeah, if anything, Rust feels to me like it's incredibly well thought through. All the pieces fit together well precisely as if they were all thought of as a whole. It's "hard" because it forces you to consider an entirely new constraint of your programs upfront. But (almost) every piece composes nicely with every other piece in a way that makes Rust development extremely pleasant. Golang feels like the opposite, in that none of the parts are actually built to work with one another. Tuple returns exist but there are no language features that allow you to actually work with them. There's a strong type system, but you have to break out of it with interface{} and type punning to solve entire classes of common problems. Type punning exists, but go can't prove exhaustiveness of switch statements so doing this opens further gaping holes. Errors are handled explicitly everywhere, but again there are no tools to handle the repetitive lifting so every program becomes an endless series of error handling occasionally interrupted by bits of program logic. And let's not forget how badly interface pointers interact with nils: comparing a nil interface pointer against nil returns false, so a basic nil-check that works everywhere else fails to actually perform correctly when dealing with interfaces.

steveklabnik 6y ago

> anyone with half an idea is allowed to bolt on features. I know you're talking about feel here, not about process, but to be clear, while we do have a pretty open and fairly democratic process, and while anyone can propose a feature, only the language team members, which is currently five folks, can decide to say "yes" to a proposal. The team may have been plus or minus a few over the years, but it's never been particularly large. (We generally feel this process works well to balance all these factors; we want everyone's good ideas, but we also have to maintain coherence. An open suggestion process with a closed selection process has worked well in our eyes, but everyone can feel differently, of course.)

derefr 6y ago

I’m guessing you’ve looked more at Rust code that uses incubating features from Rust nightly. Most of those features don’t make it to stable—or if they do, their syntax has usually been refined by the time they do. Inconveniently, a lot of the Rust code examples you’ll run into on HN uses incubating features, because a lot of the people posting about Rust on HN are language researchers talking about how they were finally able to implement new language feature/performance optimization/safety guarantee X using incubating language feature Y; or how they think nascent library Foo’s use of incubating language feature Z is/isn’t a good idea. All that is inside baseball. It looks nothing like day-to-day Rust code, any more than e.g. .NET CLR static analysis code looks like day-to-day C#. (Also, there’s the code examples of Rust stdlib code, which is like C++ STL code in that you have to use arcane language features “in anger” to bootstrap the language — e.g. safe concurrent data structures must necessarily at some point rely on unsafe code.) (Or it’s code for a Rust unikernel / OS device driver / etc, because that’s a thing you can do. But it’s a still-nascent thing you can do, that’s not yet as ergonomic as regular code that can rely on virtual memory to exist. You have to build the safety yourself in such cases, or rely on a library that does; and there are no such libraries that have yet reached high code quality + wide cross-platform applicability.)

nyanpasu64 6y ago
Rust stdlib code is a lot nicer to read than C++ stdlib code, which relies on _Mangled names to prevent conflicts, and (ab)uses template metaprogramming, SFINAE, overloading, & and && and forwarding, etc. heavily. Though Rust's trait system results in indirections comparable to (but somewhat more manageable than) C++ SFINAE/overloading/type traits. And some Rust stdlib types delegate to compiler intrinsics rather than being implemented in unsafe Rust (forgot which). Additionally, third-party Rust data structure/concurrency crates often contain unsafe code comparable to Rust's stdlib in complexity. (And device drivers, as you mentioned, are probably highly unsafe too.)

onei 6y ago

Is that because Rust is an expression language? As much as I like Rust, I do find that returning variables from conditionals or match expressions can feel a little jarring (especially when you combine the two). In other places though, it really shines and just requires a little discipline.