6 ms·

Wacky, quirky stuff?

by rtoway 5y ago

jimmaswell 5y ago
fn sum_odd_numbers(up_to: u32) -> u32 { why fn? why switch the order around? fn and u32 and all that as if keystrokes are such a scarce resource, yet u32 f(u32 a) saves so much more than fn f(a: u32) -> u32. Closures use pipes instead of any of the existing syntaxes we're used to. Why couldn't they just use the familiar concept of classes instead of whatever is going on with their strange NIH traits? NIH describes the whole language, every little thing has to be different somehow. C with Rust's safety guarantees, OOP style classes, and a few more bells and whistles could have taken over the world a lot faster, but instead we have something with a high friction to learning that will be adopted much more slowly by either programmers with a fresh start to whom every language is equally weird, or the relative minority of experienced programmers with the will and free time to push past the friction.
- oxnrtr 5y ago
 There are good reasons for it, and I'm certain you will gain a better understanding as you gain more experience as a developer.
 - quotemstr 5y ago
 > There are good reasons for it, and I'm certain you will gain a better understanding as you gain more experience as a developer. The people pointing out problems with Rust have more experience as developers in their little fingers than Rust's internet fan club has in their whole bodies combined. In a mature, intelligent discussion, if you have a point, you make it. On HN, if you have a point, you say "there are reasons; I'm not going to give them; also, you're a newbie". It's comments like yours that make HN unbearable nowadays.
 - deleted 5y ago
 [deleted]
- Rusky 5y ago
 None of this stuff is NIH, it's just from a different lineage than C.
- rtoway 5y ago
 Interesting perspective. FWIW a lot of modern languages now have put the types on the left for a good reason, it's a lot easier to parse. Plus for a reader, at least in Rust, wherever you see a `:` you know that a type is coming after. For the other stuff, I don't know, I got used to it pretty quickly. Not that much of a big deal in my opinion
 - still_grokking 5y ago
 The "symbol: Type" notation is the "scientific" one for programming languages since "forever". It's not that "modern" languages are doing something new. Everybody was doing it like that, besides the "C language family". They're the outlier, not the other way around.
 - rtoway 5y ago
 Thanks for educating me. I am affected by recency bias
- dosshell 5y ago
 To answer the first paragraph (as I understand it, i'm no expert here): Parsing! it is faster to parse and probably uses less memory too. This is not only important for compile time but also for editors with code suggestions. C has a relative long compile time. If you look at golang, which has a goal of a fast compile time, you will see similar syntax. PS. Note that Ken is one of the fathers of both C and golang.
 - quotemstr 5y ago
 > Parsing speed Parsing is ridiculously fast nowadays. Compilers spend far more time in phases after AST construction (like register allocation, SSA transforms, various vectorizaton passes) than they do constructing their ASTs. Parsing speed is a nonsense argument these days. It's the same level of rigor as painting a car red to go faster. > If you look at golang, which has a goal of a fast compile time, you will see similar syntax. Rust critics: "Some of Rust's language choices are clearly inspired by Go and may not have been good ideas" Rust people: "We didn't copy Go! We independently through a rigorous analysis arrived at our syntax!" Also Rust people: "If you look at golang, which has a goal of a fast compile time, you will see similar syntax." > Note that Ken is one of the fathers of both C and golang. Creating one of these things makes Ken made imperfect. Creating both of these things makes Ken a menace.
- pasabagi 5y ago
 I don't think rust is particularly weird. If you want, you can pretty much write in an imperative style, with objects, etc. It's just got some practical thinking thrown on ontop of that: i.e. make everything immutable by default, use tooling to ensure people aren't holding on to dangling pointers, etc. Some of these things have tradeoffs, but I think once you get to grips with what the borrow checker is asking of you (doesn't take long), it's a pretty easy language - certainly simpler than C[0], far simpler than C++. [0]: Non-buggy C, that is. I wrote a pretty basic program in C the other day (I'm not a C programmer) and I literally spent 80% of the time looking at output from -fsanitize=address to catch stupid off-by-one errors.
- dragonwriter 5y ago
 > Closures use pipes instead of any of the existing syntaxes we're used to. Who is “we”? Pipes are one of the existing closure syntaxes I was used to pre-Rust. And, I mean, I’m probably not alone: lots of current and ex-Rubyists around.
- dralley 5y ago
 Rust didn't invent any of these syntaxes. Pascal was invented around the same time as C and had functions that start with "function" and types that use the "binding: type" notation. And lots of languages (Ada and ML come to mind) followed in Pascal's footsteps that predate Rust. It has benefits. It's easier to parse for both humans and machines and it allows for easier type inference. >Closures use pipes instead of any of the existing syntaxes we're used to. Closures in Ruby use pipes. It's a common syntax. >Why couldn't they just use the familiar concept of classes instead of whatever is going on with their strange NIH traits? NIH describes the whole language, every little thing has to be different somehow. Needless to say, traits aren't NIH either, and there's good reasons for avoiding class-style polymorphism in a language like Rust. Here's some reading to help explain. https://stevedonovan.github.io/rust-gentle-intro/object-orientation.html https://stevedonovan.github.io/rust-gentle-intro/object-orie... It also happens to include this choice quote: >I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible And that's basically what Rust gives you
 - tialaramex 5y ago
 And clever use of blanket implementations makes traits even nicer for this purpose. For example, suppose you just invented the type Qux and you always know how turn any Baz into a Qux. Rust's standard library provides four interesting conversion traits that may be applicable for different purposes, From, Into, TryFrom, and TryInto. Oh no, implementing all of them sounds like a lot of work and who knows which anybody would need? Just implement From<Baz> for Qux A blanket implemention of Into for T when From<T> for U gets you Into, then a blanket implementation of TryFrom<T> for U when Into for T gives you TryFrom, and finally a blanket implementation of TryInto for T when TryFrom<T> for U gets you TryInto as well. So you only wrote one implementation but anybody who needs any of these four conversions gets the one they needed. Another more obvious example is the blanket implementation of IntoIterator for any Iterator. This makes it easy when you want to be passed a bunch of Stuff you're going to iterate over, just give a trait bound on your parameter saying it has to be IntoIterator for Stuff. You needn't care if the user of your function passes you an array, a container type, or an iterator, since all of them are IntoIterator. It would have been so easy to overlook this, and end up with a language where people find themselves collecting up iterators into containers over and over to make more iterators, or else constantly turning containers into iterators to call functions.
- howinteresting 5y ago
 I have extensive experience in OOP. Classes are a bad way to achieve polymorphism, and their popularity is an indictment on our profession.
- oxnrtr 5y ago
 Tell me you have basically no understanding of the subject matter without telling me you have basically no understanding of the subject matter.

Wacky, quirky stuff?

by rtoway 5y ago

Wacky, quirky stuff?

fn sum_odd_numbers(up_to: u32) -> u32 { why fn? why switch the order around? fn and u32 and all that as if keystrokes are such a scarce resource, yet u32 f(u32 a) saves so much more than fn f(a: u32) -> u32. Closures use pipes instead of any of the existing syntaxes we're used to. Why couldn't they just use the familiar concept of classes instead of whatever is going on with their strange NIH traits? NIH describes the whole language, every little thing has to be different somehow. C with Rust's safety guarantees, OOP style classes, and a few more bells and whistles could have taken over the world a lot faster, but instead we have something with a high friction to learning that will be adopted much more slowly by either programmers with a fresh start to whom every language is equally weird, or the relative minority of experienced programmers with the will and free time to push past the friction.

oxnrtr 5y ago
There are good reasons for it, and I'm certain you will gain a better understanding as you gain more experience as a developer.
- quotemstr 5y ago
  > There are good reasons for it, and I'm certain you will gain a better understanding as you gain more experience as a developer. The people pointing out problems with Rust have more experience as developers in their little fingers than Rust's internet fan club has in their whole bodies combined. In a mature, intelligent discussion, if you have a point, you make it. On HN, if you have a point, you say "there are reasons; I'm not going to give them; also, you're a newbie". It's comments like yours that make HN unbearable nowadays.
  - deleted 5y ago
    [deleted]
Rusky 5y ago
None of this stuff is NIH, it's just from a different lineage than C.
rtoway 5y ago
Interesting perspective. FWIW a lot of modern languages now have put the types on the left for a good reason, it's a lot easier to parse. Plus for a reader, at least in Rust, wherever you see a `:` you know that a type is coming after. For the other stuff, I don't know, I got used to it pretty quickly. Not that much of a big deal in my opinion
- still_grokking 5y ago
  The "symbol: Type" notation is the "scientific" one for programming languages since "forever". It's not that "modern" languages are doing something new. Everybody was doing it like that, besides the "C language family". They're the outlier, not the other way around.
  - rtoway 5y ago
    Thanks for educating me. I am affected by recency bias
dosshell 5y ago
To answer the first paragraph (as I understand it, i'm no expert here): Parsing! it is faster to parse and probably uses less memory too. This is not only important for compile time but also for editors with code suggestions. C has a relative long compile time. If you look at golang, which has a goal of a fast compile time, you will see similar syntax. PS. Note that Ken is one of the fathers of both C and golang.
- quotemstr 5y ago
  > Parsing speed Parsing is ridiculously fast nowadays. Compilers spend far more time in phases after AST construction (like register allocation, SSA transforms, various vectorizaton passes) than they do constructing their ASTs. Parsing speed is a nonsense argument these days. It's the same level of rigor as painting a car red to go faster. > If you look at golang, which has a goal of a fast compile time, you will see similar syntax. Rust critics: "Some of Rust's language choices are clearly inspired by Go and may not have been good ideas" Rust people: "We didn't copy Go! We independently through a rigorous analysis arrived at our syntax!" Also Rust people: "If you look at golang, which has a goal of a fast compile time, you will see similar syntax." > Note that Ken is one of the fathers of both C and golang. Creating one of these things makes Ken made imperfect. Creating both of these things makes Ken a menace.
pasabagi 5y ago
I don't think rust is particularly weird. If you want, you can pretty much write in an imperative style, with objects, etc. It's just got some practical thinking thrown on ontop of that: i.e. make everything immutable by default, use tooling to ensure people aren't holding on to dangling pointers, etc. Some of these things have tradeoffs, but I think once you get to grips with what the borrow checker is asking of you (doesn't take long), it's a pretty easy language - certainly simpler than C[0], far simpler than C++. [0]: Non-buggy C, that is. I wrote a pretty basic program in C the other day (I'm not a C programmer) and I literally spent 80% of the time looking at output from -fsanitize=address to catch stupid off-by-one errors.
dragonwriter 5y ago
> Closures use pipes instead of any of the existing syntaxes we're used to. Who is “we”? Pipes are one of the existing closure syntaxes I was used to pre-Rust. And, I mean, I’m probably not alone: lots of current and ex-Rubyists around.
dralley 5y ago
Rust didn't invent any of these syntaxes. Pascal was invented around the same time as C and had functions that start with "function" and types that use the "binding: type" notation. And lots of languages (Ada and ML come to mind) followed in Pascal's footsteps that predate Rust. It has benefits. It's easier to parse for both humans and machines and it allows for easier type inference. >Closures use pipes instead of any of the existing syntaxes we're used to. Closures in Ruby use pipes. It's a common syntax. >Why couldn't they just use the familiar concept of classes instead of whatever is going on with their strange NIH traits? NIH describes the whole language, every little thing has to be different somehow. Needless to say, traits aren't NIH either, and there's good reasons for avoiding class-style polymorphism in a language like Rust. Here's some reading to help explain. https://stevedonovan.github.io/rust-gentle-intro/object-orientation.html https://stevedonovan.github.io/rust-gentle-intro/object-orie... It also happens to include this choice quote: >I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible And that's basically what Rust gives you
- tialaramex 5y ago
 And clever use of blanket implementations makes traits even nicer for this purpose. For example, suppose you just invented the type Qux and you always know how turn any Baz into a Qux. Rust's standard library provides four interesting conversion traits that may be applicable for different purposes, From, Into, TryFrom, and TryInto. Oh no, implementing all of them sounds like a lot of work and who knows which anybody would need? Just implement From<Baz> for Qux A blanket implemention of Into for T when From<T> for U gets you Into, then a blanket implementation of TryFrom<T> for U when Into for T gives you TryFrom, and finally a blanket implementation of TryInto for T when TryFrom<T> for U gets you TryInto as well. So you only wrote one implementation but anybody who needs any of these four conversions gets the one they needed. Another more obvious example is the blanket implementation of IntoIterator for any Iterator. This makes it easy when you want to be passed a bunch of Stuff you're going to iterate over, just give a trait bound on your parameter saying it has to be IntoIterator for Stuff. You needn't care if the user of your function passes you an array, a container type, or an iterator, since all of them are IntoIterator. It would have been so easy to overlook this, and end up with a language where people find themselves collecting up iterators into containers over and over to make more iterators, or else constantly turning containers into iterators to call functions.
howinteresting 5y ago
I have extensive experience in OOP. Classes are a bad way to achieve polymorphism, and their popularity is an indictment on our profession.
oxnrtr 5y ago
Tell me you have basically no understanding of the subject matter without telling me you have basically no understanding of the subject matter.