8 ms·

The original Rust author make great points about safety. I think this new thrust on marketing emerges from Rust Roadmap 2017 which puts Rust usage in industry a

by geodel 10y ago

The original Rust author make great points about safety. I think this new thrust on marketing emerges from Rust Roadmap 2017 which puts Rust usage in industry as one of the major goal. Currently Rust is about Go's age but nowhere close in usage. As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that.

robin_reala 10y ago
It might be Go’s age overall from initial inception, but a typical point at which people start paying attention is the 1.0 release. In Go this was March 2012, for Rust it May 2015, over three years later.
- SomeStupidPoint 10y ago
  To be honest, Rust took so long to stop making breaking changes and stabilize, I sort of tuned out on it -- it was never at a point it made sense to start using. Has Rust actually settled down on some stability?
  - steveklabnik 10y ago
    A little over 18 months ago, 1.0 was released. We've had very strong compatibility guarantees since then.
    - nordsieck 10y ago
      While that is true, in Go, almost no libraries are written to use non-stable features. This is not the case in Rust.
      - steveklabnik 10y ago
        Right. Go and Rust have completely different development models, so that wouldn't make any sense. To recap, in Rust, to make additions to the language: 1. Small additions mean make a PR. 2. Big additions mean make an RFC, then a PR if accepted. 3. These PRs go behind a feature flag that lets us track the feature, and only allows it on nightly. 4. People who desire the new feature try it out. (This is what you refer to.) 5. If any issues are found, they're fixed, or, in the worst case, the feature is removed. 6. The feature is made available to stable users, the feature flag is removed, and backwards incompatible changes can no longer happen. What would be un-healthy is if everyone had to rely on nightly for everything. At the moment, most people use stable Rust. And of the people that use nightly, the largest single feature will be stable as of the next stable release for Rust. But some people are always going to be using nightly features, and that's a good thing: it means that by the time it hits stable, it's already undergone some degree of vetting.
        setori88 10y ago
        Any idea when custom allocator will become stable? That's the only thing holding us to nightly.
        steveklabnik 10y ago
        I literally had a conversation about this yesterday. We need someone to champion the work. If that's you, we should get in touch.
        setori88 10y ago
        email sent
        steveklabnik 10y ago
        Excellent! It might take me a day or two; I have some stuff to look up in order to give you a proper response.
        kebolio 10y ago
        > Most people use stable Rust. However, many popular or important libraries like Serde or Rocket require the use of nightly. I recall the article a very short while ago on the front page that noted how Rust has effectively diverged into two languages, stable and nightly.
        steveklabnik 10y ago
        Serde does not require nightly, though it is nicer to use on nightly. That's the "will be stable as of the next stable release for Rust" I alluded to above. Rocket just came out; I think it's an extremely interesting library, but https://crates.io/crates/rocket https://crates.io/crates/rocket shows that it's been downloaded 618 times. It hasn't exactly taken the world by storm yet. I think it shows great potential though! But it's not a good case of showing that the Rust ecosystem largely depends on nightly. The article you refer to contained a number of factual errors.
      - ekidd 10y ago
        There are really only two popular Rust libraries that use unstable features: 1. serde, the best serialization/deserialization library. This works on stable now using the `serge_codegen` crate and a custom `build.rs` script. This will Just Work on stable with no extra setup once Macros 1.1 lands, theoretically in about 5 weeks. But I'm using it on stable now in a half-dozen projects, thanks to a `build.rs` script. 2. Diesel, the high-level ORM library for Rust. This works on stable using a `build.rs` script, and 90% of it will work on stable without the `build.rs` script once Macros 1.1 ships. There are a few other experimental libraries like Rocket (which looks very slick) that only work on nightly Rust. But I don't think any of them are particularly popular yet. Personally, I maintain something like two dozen Rust crates and applications, and only two use nightly Rust. Both need Macros 1.1, which should be on stable in about 5 weeks.
        kzrdude 10y ago
        serde works on stable without serde_codegen or custom build scripts, too. It works like a regular library in fact, just with less features (no code generation feature). A custom data structure might not be able to use the default code generation for its impls anyway.
        bluejekyll 10y ago
        This is true of diesel as well: http://diesel.rs/guides/getting-started/ http://diesel.rs/guides/getting-started/
      - echelon 10y ago
        That article posted half a week ago [1] claiming Rust developers and libraries rely on nightly was FUD. It's terrible that this is being repeated, because it is simply not true. [1] https://news.ycombinator.com/item?id=13251729 https://news.ycombinator.com/item?id=13251729
      - kibwen 10y ago
        Er, there are no unstable features in Go... the language is deliberately frozen.
    - SomeStupidPoint 10y ago
      What constitutes a strong compatibility guarantee? How many breaking changes happened in the past 18 months?
      - steveklabnik 10y ago
        I wrote this out yesterday: https://news.ycombinator.com/item?id=13267399 https://news.ycombinator.com/item?id=13267399
      - deleted 10y ago
        [deleted]
lmm 10y ago
> Currently Rust is about Go's age but nowhere close in usage. Citation? I see a lot of people talking about both, but not very many public projects in either. Rust at least has a "killer app" on the way in the form of Servo, whereas I haven't heard of any user-facing programs in Go.
- mafribe 10y ago
  Go is the language in the LXC, Docker, containerisation space.
  - sametmax 10y ago
    Which is something I never understood. Since you are mainly wrapping OS API, why not take a higher level langage ?
    - nickpsecurity 10y ago
      For all the benefits of higher-level languages. Remember that the designers of C had to agree on every feature that went into Go: a language they co-designed for better programming experience & results. Wirth-style languages also compile ultra-fast for quick iterations.
      - sametmax 10y ago
        My question is really why not choose something really higher level ? Go is like stuck in the middle. If I need very low level, I'd choose rust. If I need high level, I'd choose Python. Go is kinda filling a weird niche between the two and I rarely find a case where I feel like it's the best choice.
    - geodel 10y ago
      What language you have in mind?
      - sametmax 10y ago
stymaar 10y ago
> Currently Rust is about Go's age but nowhere close in usage. Rust was released in 2015, it's merely one and a half years old, while Go was released in March 2012. If you count the inception period of Rust (pre-1.0) you should also count Ken Thompson's and Rob Pike's work at plan9, which doesn't make more sense … Fun fact: Go's first commit is 44 years old [1] ;) [1] https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfaea7d5efb5e90695a8 https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfae...
- pjmlp 10y ago
  Well, Go is Limbo with some Oberon-2 touches.
  - nickpsecurity 10y ago
    I thought it was supposed to be Oberon-2 with some Limbo, C, etc touches. That's part of how it becomes my slam dunk against C in anther discussion. ;)
    - pjmlp 10y ago
      If you read the Inferno programming guide, you will see how much the languages resemble themselves. Major differences are that Limbo uses a VM based runtime with dynamic loading and Abstract Data Types. But your approach is also good, still Oberon had some issues that were eventually improved in Oberon-2 that Go lacks. On the other hand Oberon-07 is even more bare bones than Go.
      - pvg 10y ago
        Most languages resemble themselves very strongly.
        pjmlp 10y ago
        You lost me there, regarding Go vs Limbo.
ccostes 10y ago
Part of the issue stopping me from jumping in is that it feels like the language is still changing in ways large enough to make it difficult to learn. That may not be true anymore, but it seems like it would take a lot of work to keep up with the current 'best practices'.
- steveklabnik 10y ago
  It's true that idioms are still developing; there are tools like clippy to help you learn them, though.
blacksmythe 10y ago
>> Currently Rust is about Go's age but nowhere close in usage. However, Go has been suitable for production projects for several years longer than Rust. Rust sits in a very useful niche not served by other languages, and in steady state will probably be more popular than Go. Go has a very well designed ecosystem. I like it, use it, and am very impressed with everything about it I have seen. However, I don't see use cases that Go serves vastly better than other available alternatives.
- nemo1618 10y ago
  Go has one very significant advantage over Rust: Simplicity. Reading someone else's Go code is such a breath of fresh air compared to reading someone else's C++ code (or god forbid, Haskell). Having a standard formatting further enhances this. I feel like this aspect of Go is not given enough weight. It's a huge benefit to large software projects and large software companies. I also suspect that this may be why the Go team has been so conservative re: generics: If they aren't implemented carefully, they could unacceptably complicate the language. Rust is a powerful language, but with that power comes the ability to write "fancy" code -- esoteric, unreadable, and unmaintainable.
  - dispose13432 10y ago
    > re: generics: If they aren't implemented carefully, they could unacceptably complicate the language. Can you explain why? For example, simple generics which could be implemented as regex doesn't seem to complicated? Am I missing something? For example (in Java), an ArrayList <String> could be turned into a StringArrayList by a basic internal pre-processor.
    - kazagistar 10y ago
      How do you handle error messages? Can you make functions, methods or their parameters generic? Can you dynamically link generics?
  - gmjosack 10y ago
    In my experience working with new and experienced Go developers that simplicity is pretty superficial. Take a look at SliceTricks[0]. These are all pretty simple operations in other languages that the Go authors think users should be forced to write manually so they understand the costs. Reading these in code reviews is definitely not a breath of fresh air. I also see Go users develop bad habits that will burn them in other languages, like returning a reference to a "stack" allocated variable. In the same vein, if you care about performance you have to internalize the escape analysis rules, which most new users won't know about. There are tons of footguns[1] in Golang as well. I constantly see people get burned by issues at runtime. I truly believe that the Golang benefits are short-sighted. You get some upfront development gains that you end up pain for with less reliable software. I personally would rather pain that cost upfront where possible with the compiler telling me when something is wrong. [0] https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks [1] http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/ http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...
loup-vaillant 10y ago
> As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that. I don't. It's a measure of the overall success. Design is but a small part of that. Community, outreach, corporate back up… play a huge part in the success of a language. Go is a wonderful example: doesn't even provide parametric polymorphism (generics), and they got away with that! Feels like Google backup matters more than the core language here. Either that, or someone please explain why omitting generics today is not a big mistake. Feels like dynamic scope all over again.
- zzzcpan 10y ago
  Think about who is picking up which language and how many programmers with what background there are. Go offers solutions for certain problems that many of programmers have. I.e. performance and ease of deployment are the biggest ones for people coming from scripting languages, and there are a lot of them. Having easy to pick up syntax doesn't hurt easier. But generics are not as valuable for them at the beginning. And Go's syntax has like a dozen of critical problems either way, might as well add generics in 2.0 together with all the fixes.
- geodel 10y ago
  Google backup is really more towards Dart when compared to Go. Dart has much more Google contributors vs Non-Google. Dart Dev summit seems to be totally sponsored by Google and it even had free entry whereas Gophercon is independent of Google. Though Dart has generics but not much usage in industry.
- camus2 10y ago
  > Go is a wonderful example: doesn't even provide parametric polymorphism (generics), and they got away with that! Only because one can opt-out of the type system and use a catch all "interface {}" .Actually even the std lib does that ... a lot.
progman 10y ago
> As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that. C (and later C++) became popular because Unix was successful. Safe systems programming and safe browsers are nice to have but not completely safe if the underlying OS is unsafe (Windows in particular). Rust's "killer app" would be a safe OS. The first attempt (Redox) is already there.
sh_tinh_hair 10y ago
That's what I'm getting from the safe features emphasis and the fiercely C/C++ competitive slant argued by the evangelists in this thread. I was looking through the pointer safety portion of the safety brochure: https://doc.rust-lang.org/book/unsafe.html#what-does-safe-mean https://doc.rust-lang.org/book/unsafe.html#what-does-safe-me... and wondering how to approach unwrapping an ethernet packet on the wire in the easy unsigned pointer-specific way it can be done in C and came across a pcap implementation in Rust (sample source): https://github.com/ebfull/pcap/blob/master/src/raw.rs https://github.com/ebfull/pcap/blob/master/src/raw.rs Are you serious? Rust is not for me, thanks.

by geodel 10y ago

robin_reala 10y ago

It might be Go’s age overall from initial inception, but a typical point at which people start paying attention is the 1.0 release. In Go this was March 2012, for Rust it May 2015, over three years later.

SomeStupidPoint 10y ago
To be honest, Rust took so long to stop making breaking changes and stabilize, I sort of tuned out on it -- it was never at a point it made sense to start using. Has Rust actually settled down on some stability?
- steveklabnik 10y ago
  A little over 18 months ago, 1.0 was released. We've had very strong compatibility guarantees since then.
  - nordsieck 10y ago
    While that is true, in Go, almost no libraries are written to use non-stable features. This is not the case in Rust.
    - steveklabnik 10y ago
      Right. Go and Rust have completely different development models, so that wouldn't make any sense. To recap, in Rust, to make additions to the language: 1. Small additions mean make a PR. 2. Big additions mean make an RFC, then a PR if accepted. 3. These PRs go behind a feature flag that lets us track the feature, and only allows it on nightly. 4. People who desire the new feature try it out. (This is what you refer to.) 5. If any issues are found, they're fixed, or, in the worst case, the feature is removed. 6. The feature is made available to stable users, the feature flag is removed, and backwards incompatible changes can no longer happen. What would be un-healthy is if everyone had to rely on nightly for everything. At the moment, most people use stable Rust. And of the people that use nightly, the largest single feature will be stable as of the next stable release for Rust. But some people are always going to be using nightly features, and that's a good thing: it means that by the time it hits stable, it's already undergone some degree of vetting.
      - setori88 10y ago
        Any idea when custom allocator will become stable? That's the only thing holding us to nightly.
        steveklabnik 10y ago
        I literally had a conversation about this yesterday. We need someone to champion the work. If that's you, we should get in touch.
        setori88 10y ago
        email sent
        steveklabnik 10y ago
        Excellent! It might take me a day or two; I have some stuff to look up in order to give you a proper response.
      - kebolio 10y ago
        > Most people use stable Rust. However, many popular or important libraries like Serde or Rocket require the use of nightly. I recall the article a very short while ago on the front page that noted how Rust has effectively diverged into two languages, stable and nightly.
        steveklabnik 10y ago
        Serde does not require nightly, though it is nicer to use on nightly. That's the "will be stable as of the next stable release for Rust" I alluded to above. Rocket just came out; I think it's an extremely interesting library, but https://crates.io/crates/rocket https://crates.io/crates/rocket shows that it's been downloaded 618 times. It hasn't exactly taken the world by storm yet. I think it shows great potential though! But it's not a good case of showing that the Rust ecosystem largely depends on nightly. The article you refer to contained a number of factual errors.
    - ekidd 10y ago
      There are really only two popular Rust libraries that use unstable features: 1. serde, the best serialization/deserialization library. This works on stable now using the `serge_codegen` crate and a custom `build.rs` script. This will Just Work on stable with no extra setup once Macros 1.1 lands, theoretically in about 5 weeks. But I'm using it on stable now in a half-dozen projects, thanks to a `build.rs` script. 2. Diesel, the high-level ORM library for Rust. This works on stable using a `build.rs` script, and 90% of it will work on stable without the `build.rs` script once Macros 1.1 ships. There are a few other experimental libraries like Rocket (which looks very slick) that only work on nightly Rust. But I don't think any of them are particularly popular yet. Personally, I maintain something like two dozen Rust crates and applications, and only two use nightly Rust. Both need Macros 1.1, which should be on stable in about 5 weeks.
      - kzrdude 10y ago
        serde works on stable without serde_codegen or custom build scripts, too. It works like a regular library in fact, just with less features (no code generation feature). A custom data structure might not be able to use the default code generation for its impls anyway.
        bluejekyll 10y ago
        This is true of diesel as well: http://diesel.rs/guides/getting-started/ http://diesel.rs/guides/getting-started/
    - echelon 10y ago
      That article posted half a week ago [1] claiming Rust developers and libraries rely on nightly was FUD. It's terrible that this is being repeated, because it is simply not true. [1] https://news.ycombinator.com/item?id=13251729 https://news.ycombinator.com/item?id=13251729
    - kibwen 10y ago
      Er, there are no unstable features in Go... the language is deliberately frozen.
  - SomeStupidPoint 10y ago
    What constitutes a strong compatibility guarantee? How many breaking changes happened in the past 18 months?
    - steveklabnik 10y ago
      I wrote this out yesterday: https://news.ycombinator.com/item?id=13267399 https://news.ycombinator.com/item?id=13267399
    - deleted 10y ago
      [deleted]

lmm 10y ago

> Currently Rust is about Go's age but nowhere close in usage. Citation? I see a lot of people talking about both, but not very many public projects in either. Rust at least has a "killer app" on the way in the form of Servo, whereas I haven't heard of any user-facing programs in Go.

mafribe 10y ago
Go is the language in the LXC, Docker, containerisation space.
- sametmax 10y ago
  Which is something I never understood. Since you are mainly wrapping OS API, why not take a higher level langage ?
  - nickpsecurity 10y ago
    For all the benefits of higher-level languages. Remember that the designers of C had to agree on every feature that went into Go: a language they co-designed for better programming experience & results. Wirth-style languages also compile ultra-fast for quick iterations.
    - sametmax 10y ago
      My question is really why not choose something really higher level ? Go is like stuck in the middle. If I need very low level, I'd choose rust. If I need high level, I'd choose Python. Go is kinda filling a weird niche between the two and I rarely find a case where I feel like it's the best choice.
  - geodel 10y ago
    What language you have in mind?
    - sametmax 10y ago

stymaar 10y ago

> Currently Rust is about Go's age but nowhere close in usage. Rust was released in 2015, it's merely one and a half years old, while Go was released in March 2012. If you count the inception period of Rust (pre-1.0) you should also count Ken Thompson's and Rob Pike's work at plan9, which doesn't make more sense … Fun fact: Go's first commit is 44 years old [1] ;) [1] https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfaea7d5efb5e90695a8 https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfae...

pjmlp 10y ago
Well, Go is Limbo with some Oberon-2 touches.
- nickpsecurity 10y ago
  I thought it was supposed to be Oberon-2 with some Limbo, C, etc touches. That's part of how it becomes my slam dunk against C in anther discussion. ;)
  - pjmlp 10y ago
    If you read the Inferno programming guide, you will see how much the languages resemble themselves. Major differences are that Limbo uses a VM based runtime with dynamic loading and Abstract Data Types. But your approach is also good, still Oberon had some issues that were eventually improved in Oberon-2 that Go lacks. On the other hand Oberon-07 is even more bare bones than Go.
    - pvg 10y ago
      Most languages resemble themselves very strongly.
      - pjmlp 10y ago
        You lost me there, regarding Go vs Limbo.

ccostes 10y ago

Part of the issue stopping me from jumping in is that it feels like the language is still changing in ways large enough to make it difficult to learn. That may not be true anymore, but it seems like it would take a lot of work to keep up with the current 'best practices'.

steveklabnik 10y ago
It's true that idioms are still developing; there are tools like clippy to help you learn them, though.

blacksmythe 10y ago

>> Currently Rust is about Go's age but nowhere close in usage. However, Go has been suitable for production projects for several years longer than Rust. Rust sits in a very useful niche not served by other languages, and in steady state will probably be more popular than Go. Go has a very well designed ecosystem. I like it, use it, and am very impressed with everything about it I have seen. However, I don't see use cases that Go serves vastly better than other available alternatives.

nemo1618 10y ago
Go has one very significant advantage over Rust: Simplicity. Reading someone else's Go code is such a breath of fresh air compared to reading someone else's C++ code (or god forbid, Haskell). Having a standard formatting further enhances this. I feel like this aspect of Go is not given enough weight. It's a huge benefit to large software projects and large software companies. I also suspect that this may be why the Go team has been so conservative re: generics: If they aren't implemented carefully, they could unacceptably complicate the language. Rust is a powerful language, but with that power comes the ability to write "fancy" code -- esoteric, unreadable, and unmaintainable.
- dispose13432 10y ago
  > re: generics: If they aren't implemented carefully, they could unacceptably complicate the language. Can you explain why? For example, simple generics which could be implemented as regex doesn't seem to complicated? Am I missing something? For example (in Java), an ArrayList <String> could be turned into a StringArrayList by a basic internal pre-processor.
  - kazagistar 10y ago
    How do you handle error messages? Can you make functions, methods or their parameters generic? Can you dynamically link generics?
- gmjosack 10y ago
  In my experience working with new and experienced Go developers that simplicity is pretty superficial. Take a look at SliceTricks[0]. These are all pretty simple operations in other languages that the Go authors think users should be forced to write manually so they understand the costs. Reading these in code reviews is definitely not a breath of fresh air. I also see Go users develop bad habits that will burn them in other languages, like returning a reference to a "stack" allocated variable. In the same vein, if you care about performance you have to internalize the escape analysis rules, which most new users won't know about. There are tons of footguns[1] in Golang as well. I constantly see people get burned by issues at runtime. I truly believe that the Golang benefits are short-sighted. You get some upfront development gains that you end up pain for with less reliable software. I personally would rather pain that cost upfront where possible with the compiler telling me when something is wrong. [0] https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks [1] http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/ http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...

loup-vaillant 10y ago

> As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that. I don't. It's a measure of the overall success. Design is but a small part of that. Community, outreach, corporate back up… play a huge part in the success of a language. Go is a wonderful example: doesn't even provide parametric polymorphism (generics), and they got away with that! Feels like Google backup matters more than the core language here. Either that, or someone please explain why omitting generics today is not a big mistake. Feels like dynamic scope all over again.

zzzcpan 10y ago
Think about who is picking up which language and how many programmers with what background there are. Go offers solutions for certain problems that many of programmers have. I.e. performance and ease of deployment are the biggest ones for people coming from scripting languages, and there are a lot of them. Having easy to pick up syntax doesn't hurt easier. But generics are not as valuable for them at the beginning. And Go's syntax has like a dozen of critical problems either way, might as well add generics in 2.0 together with all the fixes.
geodel 10y ago
Google backup is really more towards Dart when compared to Go. Dart has much more Google contributors vs Non-Google. Dart Dev summit seems to be totally sponsored by Google and it even had free entry whereas Gophercon is independent of Google. Though Dart has generics but not much usage in industry.
camus2 10y ago
> Go is a wonderful example: doesn't even provide parametric polymorphism (generics), and they got away with that! Only because one can opt-out of the type system and use a catch all "interface {}" .Actually even the std lib does that ... a lot.

progman 10y ago

> As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that. C (and later C++) became popular because Unix was successful. Safe systems programming and safe browsers are nice to have but not completely safe if the underlying OS is unsafe (Windows in particular). Rust's "killer app" would be a safe OS. The first attempt (Redox) is already there.

sh_tinh_hair 10y ago

That's what I'm getting from the safe features emphasis and the fiercely C/C++ competitive slant argued by the evangelists in this thread. I was looking through the pointer safety portion of the safety brochure: https://doc.rust-lang.org/book/unsafe.html#what-does-safe-mean https://doc.rust-lang.org/book/unsafe.html#what-does-safe-me... and wondering how to approach unwrapping an ethernet packet on the wire in the easy unsigned pointer-specific way it can be done in C and came across a pcap implementation in Rust (sample source): https://github.com/ebfull/pcap/blob/master/src/raw.rs https://github.com/ebfull/pcap/blob/master/src/raw.rs Are you serious? Rust is not for me, thanks.