5 ms·

It seems to me like the designers really couldn't make up their minds. Do you want GC or not? Do you want lightweight threads or not? What level of runtime req

It seems to me like the designers really couldn't make up their minds. Do you want GC or not? Do you want lightweight threads or not? What level of runtime requirements do you want? Its finally converging on something sane, but its taken a while.

mattdw 12y ago
Or, to put it another way, the design process happened in the open, and you got to see some perfectly normal things that just wouldn't usually be visible to you. (And even have some input into them, if you were so inclined.) I don't really think that deserves criticism.
jeffreyrogers 12y ago
I've thought similar things when I've looked at Rust in the past. It seems to me that designers really wanted to make it nice from a PL theory perspective, (hence the focus on functional programming and a strong type system). I'm more partial to the Go style of language design, which focused on making it easy to do the things the designers did in practice. I don't want to make it seem like I'm coming down too hard on Rust however, and I'm excited to see how everything works out once version 1.0 is released.
- jeffdavis 12y ago
  For the time I've been interested in rust, it's been quite focused on a very practical problem: safe, without requiring a GC.
- Dewie 12y ago
  > I've thought similar things when I've looked at Rust in the past. It seems to me that designers really wanted to make it nice from a PL theory perspective, (hence the focus on functional programming and a strong type system). Do you have any alternatives to implementing a strong type system in order to give certain well-defined safety guarantees for anyone using the language? Any other alternative theories or implementation strategies that would be better? > I'm more partial to the Go style of language design, which focused on making it easy to do the things the designers did in practice. The designers/implementers wrote the first non-bootstrapped compiler in OCaml, a functional language. How's that for "things the designers did in practice"? As far as doing what they were doing in systems programming in practice: the point of the project is to actually get away from their then heavy use of unsafe languages like C++. But then they took the concepts of smart pointers, ownership etc. (presumably inspired by best practices in C/++) and tried to make it bulletproof to use.
iopq 12y ago
That's what always happens. You have a few goals that you won't compromise on (memory safety and same performance as C) and then you try to make decisions about things you CAN compromise on.
Havvy 12y ago
To be fair, GC was always a big TODO item that became less and less important to implement until there were no go reasons to implement it in the language core (as you can implement it on top of the language), and removed from that list. The other two are really part of the same coin. Having green threads involves having a runtime that has to be started. Deciding to remove the runtime means removing the green threads.

mattdw 12y ago

Or, to put it another way, the design process happened in the open, and you got to see some perfectly normal things that just wouldn't usually be visible to you. (And even have some input into them, if you were so inclined.) I don't really think that deserves criticism.

jeffreyrogers 12y ago

I've thought similar things when I've looked at Rust in the past. It seems to me that designers really wanted to make it nice from a PL theory perspective, (hence the focus on functional programming and a strong type system). I'm more partial to the Go style of language design, which focused on making it easy to do the things the designers did in practice. I don't want to make it seem like I'm coming down too hard on Rust however, and I'm excited to see how everything works out once version 1.0 is released.

jeffdavis 12y ago
For the time I've been interested in rust, it's been quite focused on a very practical problem: safe, without requiring a GC.
Dewie 12y ago
> I've thought similar things when I've looked at Rust in the past. It seems to me that designers really wanted to make it nice from a PL theory perspective, (hence the focus on functional programming and a strong type system). Do you have any alternatives to implementing a strong type system in order to give certain well-defined safety guarantees for anyone using the language? Any other alternative theories or implementation strategies that would be better? > I'm more partial to the Go style of language design, which focused on making it easy to do the things the designers did in practice. The designers/implementers wrote the first non-bootstrapped compiler in OCaml, a functional language. How's that for "things the designers did in practice"? As far as doing what they were doing in systems programming in practice: the point of the project is to actually get away from their then heavy use of unsafe languages like C++. But then they took the concepts of smart pointers, ownership etc. (presumably inspired by best practices in C/++) and tried to make it bulletproof to use.

iopq 12y ago

That's what always happens. You have a few goals that you won't compromise on (memory safety and same performance as C) and then you try to make decisions about things you CAN compromise on.

Havvy 12y ago

To be fair, GC was always a big TODO item that became less and less important to implement until there were no go reasons to implement it in the language core (as you can implement it on top of the language), and removed from that list. The other two are really part of the same coin. Having green threads involves having a runtime that has to be started. Deciding to remove the runtime means removing the green threads.