10 ms·

While I'm bullish on Rust being a big language in the next few years, there's not much production use yet -- it's still pretty immature from a production toolin

While I'm bullish on Rust being a big language in the next few years, there's not much production use yet -- it's still pretty immature from a production tooling point of view. Go, on the other hand, has a lot of adoption. So if you're looking for a language to use on the job today, it's gonna be Go.

pcwalton 11y ago
> it's still pretty immature from a production tooling point of view. I think that the production tooling for Rust is pretty good. For example, it has a package manager that everyone uses, with features like lockfiles that are specifically designed for production. Not many languages have this. It's undeniable that Go is more popular than Rust, but I think "production tooling" is not the reason.
- k__ 11y ago
  Rust and Go are going into different directions. Rust is trying something new and Go tries to only use the stuff that worked in the past. It's no surprise that people favor Go instead of Rust. Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them. The tooling really isn't the problem, as far as I can tell, Cargo is really one of the best package manager out there.
  - nickpsecurity 11y ago
    "Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them." That has nothing to do with anything. "Rust is trying something new and Go tries to only use the stuff that worked in the past. It's no surprise that people favor Go instead of Rust." That's a good point. Anyone doing something critical wants low risk. Using a proven tool or one with proven concepts is lower risk. Go's methods were proven in Pascal, Oberon, etc. So, Go is less risk. Not to knock Rust in any way with the above. Might be safer in long run due to design and improving toolchain. However, there is a risk perception and a real issue of new concepts taking time to spot then eliminate problems. So, I encourage Rust for systems use on less critical stuff right now but was shocked Dropbox uses it in storage functions.
    - pcwalton 11y ago
      > Go's methods were proven in Pascal, Oberon, etc. So, Go is less risk. Totally disagree. Rust's ideas are tweaks of decades-old research. These tweaks are what make it interesting and constitute research in their own right, but Go did that too with their tweaks to CSP and interfaces.
      - nickpsecurity 11y ago
        You disagree that the basic functionality of Go, including type and memory safety, have been proven by prior language and production deployments? That's my basic premise. If Pascal/Oberon-like languages and GC's are proven, then one that's very similar to them will likely maintain those properties and deliver the same results. That's supported by the number of amateurs that ported and re-implemented Oberon OS & compilers successfully in 6 months to 2 years at ETH. Whereas Rust uses a combination of proven primitives and exotic techniques to achieve its goals. The exotic stuff, integration strategy, and implementation are new territory that exposes a level of risk a tried-and-true method (eg knock-off Oberon) doesn't have. It's new and unfamiliar territory to programmers at large even if some methods were seen in academia (eg Cyclone). It must be shown to be effective in terms of daily usage, standard libraries, and tooling because it's such new and unfamiliar territory. When it is, as I have confidence in the team(s), it will then have a different argument where it eliminates way more risks than it introduces. Already has it at application level if compiler is robust. Overall thing needs more deployment, though, so people can see if it lives up to it, how much, and in what scenarios. That's the risk perception I'm talking about. Right now, it's a big unknown to many outsiders compared to traditional languages and platforms.
  - kod 11y ago
    Rust is actually pretty conservative regarding "new stuff". Every single feature of Rust, with the exception of the borrow checker, has been around since the 80s. Even the borrow checker is based on linear / affine types that had been researched in other languages at least over a decade ago.
  - tatterdemalion 11y ago
    > Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them. They were each represented by a prominent member of their language design team. Its tragic that more people don't know of Niko Matsakis, but his blog is one of the best resources on the design of the Rust language: http://smallcultfollowing.com/babysteps/ http://smallcultfollowing.com/babysteps/
Animats 11y ago
Go is really easy to learn if you're coming from a scripting language. It's used for a lot of server-side processing. It's probably more immediately useful than Rust if you want to get work. Rust is elegant and the future of serious programming, but not mainstream yet.
steveklabnik 11y ago
> there's not much production use yet I can't wait for a few weeks, when Dropbox should hopefully be giving a status report on how their new production deployment is going.

pcwalton 11y ago

> it's still pretty immature from a production tooling point of view. I think that the production tooling for Rust is pretty good. For example, it has a package manager that everyone uses, with features like lockfiles that are specifically designed for production. Not many languages have this. It's undeniable that Go is more popular than Rust, but I think "production tooling" is not the reason.

k__ 11y ago
Rust and Go are going into different directions. Rust is trying something new and Go tries to only use the stuff that worked in the past. It's no surprise that people favor Go instead of Rust. Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them. The tooling really isn't the problem, as far as I can tell, Cargo is really one of the best package manager out there.
- nickpsecurity 11y ago
  "Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them." That has nothing to do with anything. "Rust is trying something new and Go tries to only use the stuff that worked in the past. It's no surprise that people favor Go instead of Rust." That's a good point. Anyone doing something critical wants low risk. Using a proven tool or one with proven concepts is lower risk. Go's methods were proven in Pascal, Oberon, etc. So, Go is less risk. Not to knock Rust in any way with the above. Might be safer in long run due to design and improving toolchain. However, there is a risk perception and a real issue of new concepts taking time to spot then eliminate problems. So, I encourage Rust for systems use on less critical stuff right now but was shocked Dropbox uses it in storage functions.
  - pcwalton 11y ago
    > Go's methods were proven in Pascal, Oberon, etc. So, Go is less risk. Totally disagree. Rust's ideas are tweaks of decades-old research. These tweaks are what make it interesting and constitute research in their own right, but Go did that too with their tweaks to CSP and interfaces.
    - nickpsecurity 11y ago
      You disagree that the basic functionality of Go, including type and memory safety, have been proven by prior language and production deployments? That's my basic premise. If Pascal/Oberon-like languages and GC's are proven, then one that's very similar to them will likely maintain those properties and deliver the same results. That's supported by the number of amateurs that ported and re-implemented Oberon OS & compilers successfully in 6 months to 2 years at ETH. Whereas Rust uses a combination of proven primitives and exotic techniques to achieve its goals. The exotic stuff, integration strategy, and implementation are new territory that exposes a level of risk a tried-and-true method (eg knock-off Oberon) doesn't have. It's new and unfamiliar territory to programmers at large even if some methods were seen in academia (eg Cyclone). It must be shown to be effective in terms of daily usage, standard libraries, and tooling because it's such new and unfamiliar territory. When it is, as I have confidence in the team(s), it will then have a different argument where it eliminates way more risks than it introduces. Already has it at application level if compiler is robust. Overall thing needs more deployment, though, so people can see if it lives up to it, how much, and in what scenarios. That's the risk perception I'm talking about. Right now, it's a big unknown to many outsiders compared to traditional languages and platforms.
- kod 11y ago
  Rust is actually pretty conservative regarding "new stuff". Every single feature of Rust, with the exception of the borrow checker, has been around since the 80s. Even the borrow checker is based on linear / affine types that had been researched in other languages at least over a decade ago.
- tatterdemalion 11y ago
  > Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them. They were each represented by a prominent member of their language design team. Its tragic that more people don't know of Niko Matsakis, but his blog is one of the best resources on the design of the Rust language: http://smallcultfollowing.com/babysteps/ http://smallcultfollowing.com/babysteps/

Animats 11y ago

Go is really easy to learn if you're coming from a scripting language. It's used for a lot of server-side processing. It's probably more immediately useful than Rust if you want to get work. Rust is elegant and the future of serious programming, but not mainstream yet.

steveklabnik 11y ago

> there's not much production use yet I can't wait for a few weeks, when Dropbox should hopefully be giving a status report on how their new production deployment is going.