6 ms·

Pretty fair commentary. Rust certainly isn't one of those languages where you can just pick it up, play with it for a day implementing an algorithm in it to ge

Pretty fair commentary. Rust certainly isn't one of those languages where you can just pick it up, play with it for a day implementing an algorithm in it to get the feel of it and learn 'the complicated stuff' later. Other languages let you get away with that quick start style; you can write a lot of python before you need to write a plugin, and a lot of c# before you start using unsafe code, etc. Rust doesn't afford you that luxury. Lifetimes, mutability and single ownership are BAM, right in your face from the start. It probably puts a few people off... but hey, you know the analogy about tools and toolboxes. Rust is for writing fast, secure, cross platform code. There's nothing else out there that offers the same; it's not a case of use Rust or Nim, or C++; rust is literally the only language that offers these features right now. You can certainly write code that happens to be secure, fast and cross platform (eg. in C++), and if you don't need those features (or dont care), you're almost certainly better off picking a different language (like Go or Nim) that are 'fast enough' and 'secure enough', and don't restrict you in the same way Rust does, or something far more productive (like python or javascript) if all you need to do is smash out a product. That's perfectly ok. We don't need a language which is everything for everyone all at the same time. Rust is very good at doing what it does; and it's the first time C++ has had a real challenger. I, for one, am really looking forward to the dynamics between the two crowds going forwards.

pjmlp 12y ago
> Rust is very good at doing what it does; and it's the first time C++ has had a real challenger. Ada and Modula-3 were there first, they just weren't adopted by OS vendors at large.
- vezzy-fnord 12y ago
  Additionally, their categorizations of "fast", "secure" and "cross-platform" are far too general. I don't even think Rust officially supports that many platforms yet. It's strictly OS X/Windows/Linux, and the latter depends on glibc unless you're willing to throw away a ton of the standard library and third-party crates to start from scratch.
  - steveklabnik 12y ago
    It's true, Mac/Windows/Linux is first tier, but we also test Android in CI, and possibly iOS? And there's a few BSD hackers who keep things reasonably up to date. We're investigating a way to allow community-run CI servers for platforms we don't officially support. Being based on LLVM, we should able to support a wide variety of things, though there are C compilers for all sorts of exotic platforms, of course.
    - vhbit 12y ago
      iOS is supported but unfortunately is "manually" tested, for example snapshot of alpha2 is broken. Version which is going to build with iOS support can be found on https://github.com/vhbit/rust https://github.com/vhbit/rust (pre-built binaries on releases page)
- Rusky 12y ago
  On the other hand, Rust does have a few more guarantees than Ada or Modula-3- memory safety without a GC while deallocating memory, data race safety while sharing memory, stricter (as far as I can tell) aliasing semantics, etc.
  - pjmlp 12y ago
    While true, had Ada or Modula-3 became widespread instead of C++, we would be discussing about logical errors nowadays, not about pointer misuses.
tptacek 12y ago
Rust is for writing fast, secure, cross platform code. There's nothing else out there that offers the same. That's a weird way to put it. There are a lot of languages that offer the same (weak) security protections Rust does, and a lot of cross-platform languages, and a lot of fast languages, and lots of combinations of those attributes. What I think you mean to say is that there aren't a lot of combinations that don't have a GC runtime.
- MichaelGG 12y ago
  Which are the reasonably popular, fast ("like C") memory safe languages?
  - tptacek 12y ago
    Virtually all of the languages that aren't C, C++, and Objective C have the same (for all intents and purposes) memory safety property as Rust, so you can just check out the Programming Language Benchmark Game site to answer that question.
    - Jweb_Guru 12y ago
      Nim doesn't without the Boehm GC (it segfaults if you send a pointer to another thread). D doesn't without the garbage collector. Go doesn't with GOMAXPROCS > 1. These are often languages that are brought up in discussions like this...
      - pjmlp 12y ago
        The problem is how much safe is safe in these discussions. Rusts thread's safety is always brought up as part of the whole memory safety model and it is a very good goal to achieve. However, if we were free of the typical C style memory corruption brought upon the world of computing, there would be a lot of more safer applications. Even if those applications wouldn't be thread safe.
      - pcwalton 12y ago
        Nim also doesn't have memory safety in general. See: https://news.ycombinator.com/item?id=9050999 https://news.ycombinator.com/item?id=9050999
gsg 12y ago
Fast, restrictive and secure have been done before - see ATS, Cyclone, etc. Almost everybody ignored those trailblazing efforts, probably because those languages are very intimidating.
drewcrawford 12y ago
I think the question is "what is the cost" of the more novel rust safety features? In my experience, the cost is pretty high. When you set Rust next to, e.g. swift, swift is phenominally more productive and similarly performant. And it is also quite safe (relative to C) without having all of the Rust safety features that make me want to kill the borrow checker with a rusty spoon. I really wish Rust walked back on the more esoteric forms of safety (like thread safety, which you can't really verify anyway, you just promise the compiler that it's safe) and it tried to drive a bargain like Swift. Rust really isn't satisfied to adopt the safety features that are "fairly low effort", it wants to break new ground without really measuring developer cost (hard to do since it's not widely used). That's really my issue with it.
- pcwalton 12y ago
  > When you set Rust next to, e.g. swift, swift is phenominally more productive and similarly performant. And it is also quite safe (relative to C) without having all of the Rust safety features that make me want to kill the borrow checker with a rusty spoon. Swift is totally garbage collected: every object is atomically reference counted. (This is necessary for compatibility with Objective-C.) So Swift is essentially in the same category as Go, Java, and most other languages as far as memory management is concerned. Garbage collection is simply not a cost that we wanted to pay with Rust, in order to reach performance parity with C++. > I really wish Rust walked back on the more esoteric forms of safety (like thread safety, which you can't really verify anyway, you just promise the compiler that it's safe) and it tried to drive a bargain like Swift. I don't understand "you just promise the compiler that it's safe". Rust prevents you from accessing data in a non-thread-safe way without a mutex or atomics. This is in fact something that just fell out of the memory safety features above and didn't require any extra features: see [1] for an elaboration on this point. > Rust really isn't satisfied to adopt the safety features that are "fairly low effort", it wants to break new ground without really measuring developer cost (hard to do since it's not widely used). We have been measuring developer cost all along, by writing hundreds of thousands of lines of code in the language as we've been developing it: the Rust compiler is written in Rust, and we've been developing Servo as well. [1]: http://smallcultfollowing.com/babysteps/blog/2013/06/11/on-the-connection-between-memory-management-and-data-race-freedom/ http://smallcultfollowing.com/babysteps/blog/2013/06/11/on-t...

pjmlp 12y ago

> Rust is very good at doing what it does; and it's the first time C++ has had a real challenger. Ada and Modula-3 were there first, they just weren't adopted by OS vendors at large.

vezzy-fnord 12y ago
Additionally, their categorizations of "fast", "secure" and "cross-platform" are far too general. I don't even think Rust officially supports that many platforms yet. It's strictly OS X/Windows/Linux, and the latter depends on glibc unless you're willing to throw away a ton of the standard library and third-party crates to start from scratch.
- steveklabnik 12y ago
  It's true, Mac/Windows/Linux is first tier, but we also test Android in CI, and possibly iOS? And there's a few BSD hackers who keep things reasonably up to date. We're investigating a way to allow community-run CI servers for platforms we don't officially support. Being based on LLVM, we should able to support a wide variety of things, though there are C compilers for all sorts of exotic platforms, of course.
  - vhbit 12y ago
    iOS is supported but unfortunately is "manually" tested, for example snapshot of alpha2 is broken. Version which is going to build with iOS support can be found on https://github.com/vhbit/rust https://github.com/vhbit/rust (pre-built binaries on releases page)
Rusky 12y ago
On the other hand, Rust does have a few more guarantees than Ada or Modula-3- memory safety without a GC while deallocating memory, data race safety while sharing memory, stricter (as far as I can tell) aliasing semantics, etc.
- pjmlp 12y ago
  While true, had Ada or Modula-3 became widespread instead of C++, we would be discussing about logical errors nowadays, not about pointer misuses.

tptacek 12y ago

Rust is for writing fast, secure, cross platform code. There's nothing else out there that offers the same. That's a weird way to put it. There are a lot of languages that offer the same (weak) security protections Rust does, and a lot of cross-platform languages, and a lot of fast languages, and lots of combinations of those attributes. What I think you mean to say is that there aren't a lot of combinations that don't have a GC runtime.

MichaelGG 12y ago
Which are the reasonably popular, fast ("like C") memory safe languages?
- tptacek 12y ago
  Virtually all of the languages that aren't C, C++, and Objective C have the same (for all intents and purposes) memory safety property as Rust, so you can just check out the Programming Language Benchmark Game site to answer that question.
  - Jweb_Guru 12y ago
    Nim doesn't without the Boehm GC (it segfaults if you send a pointer to another thread). D doesn't without the garbage collector. Go doesn't with GOMAXPROCS > 1. These are often languages that are brought up in discussions like this...
    - pjmlp 12y ago
      The problem is how much safe is safe in these discussions. Rusts thread's safety is always brought up as part of the whole memory safety model and it is a very good goal to achieve. However, if we were free of the typical C style memory corruption brought upon the world of computing, there would be a lot of more safer applications. Even if those applications wouldn't be thread safe.
    - pcwalton 12y ago
      Nim also doesn't have memory safety in general. See: https://news.ycombinator.com/item?id=9050999 https://news.ycombinator.com/item?id=9050999

gsg 12y ago

Fast, restrictive and secure have been done before - see ATS, Cyclone, etc. Almost everybody ignored those trailblazing efforts, probably because those languages are very intimidating.

drewcrawford 12y ago

I think the question is "what is the cost" of the more novel rust safety features? In my experience, the cost is pretty high. When you set Rust next to, e.g. swift, swift is phenominally more productive and similarly performant. And it is also quite safe (relative to C) without having all of the Rust safety features that make me want to kill the borrow checker with a rusty spoon. I really wish Rust walked back on the more esoteric forms of safety (like thread safety, which you can't really verify anyway, you just promise the compiler that it's safe) and it tried to drive a bargain like Swift. Rust really isn't satisfied to adopt the safety features that are "fairly low effort", it wants to break new ground without really measuring developer cost (hard to do since it's not widely used). That's really my issue with it.

pcwalton 12y ago
> When you set Rust next to, e.g. swift, swift is phenominally more productive and similarly performant. And it is also quite safe (relative to C) without having all of the Rust safety features that make me want to kill the borrow checker with a rusty spoon. Swift is totally garbage collected: every object is atomically reference counted. (This is necessary for compatibility with Objective-C.) So Swift is essentially in the same category as Go, Java, and most other languages as far as memory management is concerned. Garbage collection is simply not a cost that we wanted to pay with Rust, in order to reach performance parity with C++. > I really wish Rust walked back on the more esoteric forms of safety (like thread safety, which you can't really verify anyway, you just promise the compiler that it's safe) and it tried to drive a bargain like Swift. I don't understand "you just promise the compiler that it's safe". Rust prevents you from accessing data in a non-thread-safe way without a mutex or atomics. This is in fact something that just fell out of the memory safety features above and didn't require any extra features: see [1] for an elaboration on this point. > Rust really isn't satisfied to adopt the safety features that are "fairly low effort", it wants to break new ground without really measuring developer cost (hard to do since it's not widely used). We have been measuring developer cost all along, by writing hundreds of thousands of lines of code in the language as we've been developing it: the Rust compiler is written in Rust, and we've been developing Servo as well. [1]: http://smallcultfollowing.com/babysteps/blog/2013/06/11/on-the-connection-between-memory-management-and-data-race-freedom/ http://smallcultfollowing.com/babysteps/blog/2013/06/11/on-t...