6 ms·

I think this an argument like the following is not really meaningful: > Most of this difference is not related to lifetimes. Rust has patterns, traits, dyn, m

I think this an argument like the following is not really meaningful: > Most of this difference is not related to lifetimes. Rust has patterns, traits, dyn, modules, declarative macros, procedural macros, derive, associated types, annotations, cfg, cargo features, turbofish, autoderefencing, deref coercion etc Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any. Dyn is also a very obvious concept to anybody who knows a bit of OO-programming in lower-level languages (e.g. C++). The choice to make dynamic dispatching explicit is arguable, but ultimately, although making it explicit is (AFAIK) Rust-specific, the concept itself isn't. Complaining on pattern matching? C'mon :-) It's a bit like a Python programmer complaining that Golang has a switch/case. I don't argue that Rust is hard or not, but it seems to me that the author was overwhelmed, and complained about everything, even simple things. In my experience, in the Rust learning process (and programming experience), all the concepts above are dwarfed by the headaches induced by the borrow checker. > Zig has it's own implementation of standard OS APIs which means that linking libc is completely optional. Among other things, this means that zig can generate very small binaries which might give it an edge for wasm where download/startup times matter a lot. I'm curious about the details of this. Rust has `no_std`, however, it seems that in Zig, this is more (in a way) granular?

k__ 6y ago
You're right, but I find Rusts concepts/keywords also a bit confusing. I know what a class and what an interface is, but Rust doesn't have these. It has a struct, which is kinda like a class without methods? It has a trait, which is kinda like an interface but with implementations for methods? It has ... implementations... which kinda make a struct to a class, but not really. I don't mean to hate here, but these are all things that need to be understood in some kind of way.
- kzrdude 6y ago
  Once understood, even taken together, none of those have as many rules baked into one concept as "class" does; each is simple.
  - judofyr 6y ago
    I quite like the trait system in Rust, but I'm not sure if I would argue that it's simpler than a class-based language. Just looking at `foo.bar()` there are similar types of complexities. In a class-based language you need to be aware of the class hierarchy, and in Rust you need to be aware of imported traits and auto dereferencing.
    - estebank 6y ago
      I honestly think this is a factor of prior experience. When I started using Rust my background was in OOP languages, so I also went through the exercise of fitting trait pegs into a class shaped holes and it was painful. But this doesn't mean that traits and ADTs and how they interact is harder to learn or understand than Objects with its inheritance, polymorphism, encapsulation and abstraction concepts, it just means that if you already know those, you will have to learn new concepts to learn Rust, which can be surprising if you aren't told about it ahead of time, particularly when you already know several languages that don't use traits.
      - k__ 6y ago
        I did learn much about classes and interfaces in university, independent of language. But not much on traits and ADTs(?). Can you recommend some general learning resources on that?
        estebank 6y ago
        I do not have any non-Rust resources off the top of my head, but I can give you some quickly looked up resources and enough phrases to search for that should help you in this endeavor. ADTs are Abstract Data Types[1][2][3]: > ADT is implementation independent. For example, it only describes what a data type List consists (data) and what are the operations it can perform, but it has no information about how the List is actually implemented. In the context of Rust it means that the traits, structs and enums are ADTs, while the impls are Data Structures. Having structs and enums be the way they are in Rust (simplistic and with little extensibility beyond implementing traits) is that pattern matching[4][5] and destructuring is cheap and built in. Pattern matching becomes specially useful when combined with sum types/tagged unions/enums[6][7][8]. On the other corner you have Scala which lets you implement specific interfaces to allow structuring and destructuring for arbitrary types, but that has the same problems as overriding constructors in C++: the performance implications of pattern matching is impl dependent and hidden at the point of calling. [1]: https://softwareengineering.stackexchange.com/questions/148747/abstract-data-type-and-data-structure https://softwareengineering.stackexchange.com/questions/1487... [2]: https://en.wikipedia.org/wiki/Abstract_data_type https://en.wikipedia.org/wiki/Abstract_data_type [3]: https://abrickshort.wordpress.com/2005/03/06/abstract-data-types-vs-data-structures/ https://abrickshort.wordpress.com/2005/03/06/abstract-data-t... [4]: https://en.wikipedia.org/wiki/Pattern_matching https://en.wikipedia.org/wiki/Pattern_matching [5]: https://docs.scala-lang.org/tour/pattern-matching.html https://docs.scala-lang.org/tour/pattern-matching.html [6]: https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick-of-the-week/sum-types https://www.schoolofhaskell.com/school/to-infinity-and-beyon... [7]: https://chadaustin.me/2015/07/sum-types/ https://chadaustin.me/2015/07/sum-types/ [8]: https://stackoverflow.com/questions/2502354/what-is-pattern-matching-in-functional-languages https://stackoverflow.com/questions/2502354/what-is-pattern-...
jmull 6y ago
> the author was overwhelmed It strikes me that you start off meaning to rebut the author's point and end up supporting it.
- Ygg2 6y ago
  Well, by that logic, Java is overwhelming if you dive right into Aspect oriented programming, the Atomics and Multi-threaded Java. I don't consider myself an expert in Rust, but hell, the borrow checker was always helpful. I.e. even if it prohibited a sound program, it explained its reasoning at length. It was easy to fix the issue even if it came. Macros are meta programming, of course they are hard. And even then, there are ways around. Like cargo-expand, it makes procedural macros easier to reason about.
rob74 6y ago
This reminds me of the (by now) old saying that code is more often read than written - sure, you're not forced to write macros, but if you use macros (or more exotic features), you force the developers who read your code to become familiar with (possibly arcane) features that they maybe would have never used (or needed). That's why I think Go's approach to not try to be "everybody's darling" by implementing every conceivable feature is commendable (even if mentioning this in a Rust-related thread will get me downvoted again).
- vardump 6y ago
  I think your words come from experience. It's not about how effortless the code is to write, but the total lifecycle effort. This includes for example maintenance, security, extending and on-boarding new team members.
- q3k 6y ago
  As coined by Google engineers: software engineering is programming integrated over time. Languages that are paragons of cutting edge PL research unfortunately tend to forget that. Go’s simplicity tends to be brought up as a negative trait (dumb language, dumb users, etc) mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codebase to do the same thing. Last thing on your mind then is the type safety and elegance of a language.
  - mcherm 6y ago
    > Go’s simplicity tends to be brought [...] mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codebase to do the same thing. Last thing on your mind then is the type safety and elegance of a language. Actually, type safety can be quite useful in such a context: it allows the person who designed the types in use to enforce certain restrictions on the developer who is hurriedly adding code to an unfamiliar codebase, thus reducing the requirement for that developer to understand larger issues in the system.
    - 6y ago
flohofwoe 6y ago
> Complaining on pattern matching? I've read that as a (minor) complaint that Zig doesn't have Rust's pattern matching, not that there's anything wrong with pattern matching (and that Zig's switch still does 90% of what the author uses Rust's pattern matching for).
martinhath 6y ago
> Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any. Macros in Rust aren't only confusing for beginners, because it has a completely different syntax (well, at least macro_rules! does; idk about proc macros) than the one you use for the rest of your program. Even _if_ you draw the line between macro writers and users, you've effectively made macros a black box you're not supposed to look into. Having trouble debugging anything related to a custom derive or a macro? Too bad, macro's are hard. This is (a) not useful and (b) not necessary, as Zig clearly shows. I think Rust made the C++ mistake of trying to accommodate everyone by having both low level control of things, but not too low level since that's dangerous, so we'll come up with some rules that you can't break, and oh by the way the rules aren't really ready yet, oh, and if you're not used to dereferencing pointers, don't worry we have this deref trait, what's a trait you say? and so on and so on. It's effectively a barrier to entry, which, ironically, is a thing the Rust community tries really hard to combat. If you mix a bunch of nice colors, blue, red, green, turqouise, purple, orange, eggshell white, you just get ... brown.
- scoutt 6y ago
  > the Rust community tries really hard to combat How? My impression is that they are not trying to do the language easier at every release. Contrarily, I see more new features added all the time (which is a good thing if Rust is your thing). What I see is top-quality documentation. No doubt about it. Perhaps they focus on quality learning material, but the truth is the more I read, the more I scratch my head thinking "what is this construct and when and why do I need to use this?". Then overchoice[1] anxiety kicks in and I go back to zero, that is, my good old C. [1] https://en.wikipedia.org/wiki/Overchoice https://en.wikipedia.org/wiki/Overchoice
- rhodysurf 6y ago
  On top of that... you have to use proc macros to do any kind of annoying repetitive implementation of traits. But to do that, you have to add another crate, then you have to possibly make another crate if you want to share any code with the proc macro implementations and the actual library. I understand why it is this way but it is very much not ergonomic
patrec 6y ago
The author is obviously in the top ~1% or something of programmers: the article is thoughtful and shows a lot of technical depth and knowledge about things most programmers won't even have heard of and he clearly has a fair amount of practical experience. So telling him he's just somehow imagining all this complexity and cognitive load, because he doesn't have to use all this complexity feels a tad tone deaf, in a very HN way.
- mlindner 6y ago
  > The author is obviously in the top ~1% or something of programmers Appeal to authority much?
hxzhao 6y ago
> Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any. I think one of the problems with this mindset is, you are only assuming the case with you have full control on the code-base e.g. writing thing from scratch so that you can only use those features in rust that you feel comfortable with, in other cases, you have little control on what others use.
pornel 6y ago
As someone with lots of Rust experience I agree with the author. Rust has more concepts that users need to learn. It's not gratuitous/accidental complexity. Each of these features is IMHO pretty well designed and useful, but nevertheless Rust does have a larger toolbox. It's not necessarily bad. Do you prefer to put more effort into your program before it compiles, or debug it after it's up an running? Do you want a static guarantee, or do you trust yourself to get it right? These are fair trade-offs.
drcode 6y ago
Sure, the rust language is "simple" if you abstain from using 80% of the features of rust, but then it would be impossible to write non-trivial programs. Zig, on the other hand, gets rid of this 80% as well, AND still lets you write non-trivial programs.

k__ 6y ago

You're right, but I find Rusts concepts/keywords also a bit confusing. I know what a class and what an interface is, but Rust doesn't have these. It has a struct, which is kinda like a class without methods? It has a trait, which is kinda like an interface but with implementations for methods? It has ... implementations... which kinda make a struct to a class, but not really. I don't mean to hate here, but these are all things that need to be understood in some kind of way.

kzrdude 6y ago
Once understood, even taken together, none of those have as many rules baked into one concept as "class" does; each is simple.
- judofyr 6y ago
  I quite like the trait system in Rust, but I'm not sure if I would argue that it's simpler than a class-based language. Just looking at `foo.bar()` there are similar types of complexities. In a class-based language you need to be aware of the class hierarchy, and in Rust you need to be aware of imported traits and auto dereferencing.
  - estebank 6y ago
    I honestly think this is a factor of prior experience. When I started using Rust my background was in OOP languages, so I also went through the exercise of fitting trait pegs into a class shaped holes and it was painful. But this doesn't mean that traits and ADTs and how they interact is harder to learn or understand than Objects with its inheritance, polymorphism, encapsulation and abstraction concepts, it just means that if you already know those, you will have to learn new concepts to learn Rust, which can be surprising if you aren't told about it ahead of time, particularly when you already know several languages that don't use traits.
    - k__ 6y ago
      I did learn much about classes and interfaces in university, independent of language. But not much on traits and ADTs(?). Can you recommend some general learning resources on that?
      - estebank 6y ago
        I do not have any non-Rust resources off the top of my head, but I can give you some quickly looked up resources and enough phrases to search for that should help you in this endeavor. ADTs are Abstract Data Types[1][2][3]: > ADT is implementation independent. For example, it only describes what a data type List consists (data) and what are the operations it can perform, but it has no information about how the List is actually implemented. In the context of Rust it means that the traits, structs and enums are ADTs, while the impls are Data Structures. Having structs and enums be the way they are in Rust (simplistic and with little extensibility beyond implementing traits) is that pattern matching[4][5] and destructuring is cheap and built in. Pattern matching becomes specially useful when combined with sum types/tagged unions/enums[6][7][8]. On the other corner you have Scala which lets you implement specific interfaces to allow structuring and destructuring for arbitrary types, but that has the same problems as overriding constructors in C++: the performance implications of pattern matching is impl dependent and hidden at the point of calling. [1]: https://softwareengineering.stackexchange.com/questions/148747/abstract-data-type-and-data-structure https://softwareengineering.stackexchange.com/questions/1487... [2]: https://en.wikipedia.org/wiki/Abstract_data_type https://en.wikipedia.org/wiki/Abstract_data_type [3]: https://abrickshort.wordpress.com/2005/03/06/abstract-data-types-vs-data-structures/ https://abrickshort.wordpress.com/2005/03/06/abstract-data-t... [4]: https://en.wikipedia.org/wiki/Pattern_matching https://en.wikipedia.org/wiki/Pattern_matching [5]: https://docs.scala-lang.org/tour/pattern-matching.html https://docs.scala-lang.org/tour/pattern-matching.html [6]: https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick-of-the-week/sum-types https://www.schoolofhaskell.com/school/to-infinity-and-beyon... [7]: https://chadaustin.me/2015/07/sum-types/ https://chadaustin.me/2015/07/sum-types/ [8]: https://stackoverflow.com/questions/2502354/what-is-pattern-matching-in-functional-languages https://stackoverflow.com/questions/2502354/what-is-pattern-...

jmull 6y ago

> the author was overwhelmed It strikes me that you start off meaning to rebut the author's point and end up supporting it.

Ygg2 6y ago
Well, by that logic, Java is overwhelming if you dive right into Aspect oriented programming, the Atomics and Multi-threaded Java. I don't consider myself an expert in Rust, but hell, the borrow checker was always helpful. I.e. even if it prohibited a sound program, it explained its reasoning at length. It was easy to fix the issue even if it came. Macros are meta programming, of course they are hard. And even then, there are ways around. Like cargo-expand, it makes procedural macros easier to reason about.

rob74 6y ago

This reminds me of the (by now) old saying that code is more often read than written - sure, you're not forced to write macros, but if you use macros (or more exotic features), you force the developers who read your code to become familiar with (possibly arcane) features that they maybe would have never used (or needed). That's why I think Go's approach to not try to be "everybody's darling" by implementing every conceivable feature is commendable (even if mentioning this in a Rust-related thread will get me downvoted again).

vardump 6y ago
I think your words come from experience. It's not about how effortless the code is to write, but the total lifecycle effort. This includes for example maintenance, security, extending and on-boarding new team members.
q3k 6y ago
As coined by Google engineers: software engineering is programming integrated over time. Languages that are paragons of cutting edge PL research unfortunately tend to forget that. Go’s simplicity tends to be brought up as a negative trait (dumb language, dumb users, etc) mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codebase to do the same thing. Last thing on your mind then is the type safety and elegance of a language.
- mcherm 6y ago
  > Go’s simplicity tends to be brought [...] mostly by those who weren’t yet woken up by a page that required them to quickly read, debug and fix things. Or even jump into another team’s codebase to do the same thing. Last thing on your mind then is the type safety and elegance of a language. Actually, type safety can be quite useful in such a context: it allows the person who designed the types in use to enforce certain restrictions on the developer who is hurriedly adding code to an unfamiliar codebase, thus reducing the requirement for that developer to understand larger issues in the system.
  - 6y ago

flohofwoe 6y ago

> Complaining on pattern matching? I've read that as a (minor) complaint that Zig doesn't have Rust's pattern matching, not that there's anything wrong with pattern matching (and that Zig's switch still does 90% of what the author uses Rust's pattern matching for).

martinhath 6y ago

> Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any. Macros in Rust aren't only confusing for beginners, because it has a completely different syntax (well, at least macro_rules! does; idk about proc macros) than the one you use for the rest of your program. Even _if_ you draw the line between macro writers and users, you've effectively made macros a black box you're not supposed to look into. Having trouble debugging anything related to a custom derive or a macro? Too bad, macro's are hard. This is (a) not useful and (b) not necessary, as Zig clearly shows. I think Rust made the C++ mistake of trying to accommodate everyone by having both low level control of things, but not too low level since that's dangerous, so we'll come up with some rules that you can't break, and oh by the way the rules aren't really ready yet, oh, and if you're not used to dereferencing pointers, don't worry we have this deref trait, what's a trait you say? and so on and so on. It's effectively a barrier to entry, which, ironically, is a thing the Rust community tries really hard to combat. If you mix a bunch of nice colors, blue, red, green, turqouise, purple, orange, eggshell white, you just get ... brown.

scoutt 6y ago
> the Rust community tries really hard to combat How? My impression is that they are not trying to do the language easier at every release. Contrarily, I see more new features added all the time (which is a good thing if Rust is your thing). What I see is top-quality documentation. No doubt about it. Perhaps they focus on quality learning material, but the truth is the more I read, the more I scratch my head thinking "what is this construct and when and why do I need to use this?". Then overchoice[1] anxiety kicks in and I go back to zero, that is, my good old C. [1] https://en.wikipedia.org/wiki/Overchoice https://en.wikipedia.org/wiki/Overchoice
rhodysurf 6y ago
On top of that... you have to use proc macros to do any kind of annoying repetitive implementation of traits. But to do that, you have to add another crate, then you have to possibly make another crate if you want to share any code with the proc macro implementations and the actual library. I understand why it is this way but it is very much not ergonomic

patrec 6y ago

The author is obviously in the top ~1% or something of programmers: the article is thoughtful and shows a lot of technical depth and knowledge about things most programmers won't even have heard of and he clearly has a fair amount of practical experience. So telling him he's just somehow imagining all this complexity and cognitive load, because he doesn't have to use all this complexity feels a tad tone deaf, in a very HN way.

mlindner 6y ago
> The author is obviously in the top ~1% or something of programmers Appeal to authority much?

hxzhao 6y ago

> Nobody forces beginners to write macros. Beginners are only macros _users_. With time and experience, the need for macros emerges by itself, then learning them is a natural part of the process. But even then, nobody is forced to write any. I think one of the problems with this mindset is, you are only assuming the case with you have full control on the code-base e.g. writing thing from scratch so that you can only use those features in rust that you feel comfortable with, in other cases, you have little control on what others use.

pornel 6y ago

As someone with lots of Rust experience I agree with the author. Rust has more concepts that users need to learn. It's not gratuitous/accidental complexity. Each of these features is IMHO pretty well designed and useful, but nevertheless Rust does have a larger toolbox. It's not necessarily bad. Do you prefer to put more effort into your program before it compiles, or debug it after it's up an running? Do you want a static guarantee, or do you trust yourself to get it right? These are fair trade-offs.

drcode 6y ago

Sure, the rust language is "simple" if you abstain from using 80% of the features of rust, but then it would be impossible to write non-trivial programs. Zig, on the other hand, gets rid of this 80% as well, AND still lets you write non-trivial programs.