8 ms·

> expect severe bugs, crashes, and missing functionality. I really don't mean this in a snarky way: wasn't this kind of thing supposed to be obviated by the sw

by pekk 10y ago

> expect severe bugs, crashes, and missing functionality. I really don't mean this in a snarky way: wasn't this kind of thing supposed to be obviated by the switch to Rust? It often seems that every other post about Rust on HN says that if it compiles, it works.

IanCal 10y ago
No language can fix missing functionality, that seems pretty clear. Your compiler doesn't know what you're trying to do, so you can't prevent all bugs. That leaves crashes, and ... well it may also depend on what you mean by a crash. The UI becomes unresponsive? Might have absolutely nothing to do with memory issues or even code written in rust. Maybe your rust code is fine but you're trying to open and write to the same file from two places which you don't realise because the users file system is case insensitive but you've only tested on a case sensitive one, etc. It's also multi-threaded and while languages can significantly help improve the safety of multi-threaded code, I don't think anything can stop you from creating a deadlock or putting your system into an inconsistent state. And finally, they may not even particularly expect those things, but putting out early nightly builds to a wider audience and expecting nothing to go wrong would be cavalier. A typical warning on many early releases is "don't blame me if this destroys all your files".
- Manishearth 10y ago
  By crashes we mean panics. We still panic in various places in the code when something goes wrong.
  - tinco 10y ago
    To clarify, a panic in rust is the result of an unhandled exception. Usually this is due to laziness rather than a real bug. For example Servo might encounter an IMG tag, start to load the body. The result might be stored in an option because something could have gone wrong during loading (peer disconnected etc.) but the developer didn't feel like implementing robust image handling that day and instead called .expect to extract the image. This throws a panic and exits the application if the image is not there. This is just a hypothetical example, I bet image loading is one of the things Servo does fine. Just to give you an idea of when Rust might panic.
    - Morgawr 10y ago
      I do things like this all the time in Haskell when quickly prototyping new code and then swiftly kick myself because of it. Safe languages are nice, but there's really no way to prevent a developer from saying "Yeah fuck it, this case will never happen anyway" and then calling a fromJust on a Maybe monad which turns out was a Nothing and throws a runtime exception.
      - majewsky 10y ago
        Well, there is a way: Don't allow partial functions like fromJust or head. But a) it's going to make prototyping so tedious that no one will bother using this hypothetical language, and b) there are problems that you just cannot solve without partial functions (e.g. foldl1).
    - Manishearth 10y ago
      Heh. Earlier in this thread, someone did indeed find a bug in our image loading: https://news.ycombinator.com/item?id=12014108 https://news.ycombinator.com/item?id=12014108 We were basically panicking when an invalid URL was given to us. There was a comment there noting this -- which means that this was probably written when it wasn't so important to handle all the cases, and more important to handle some cases so that we can test out various ideas. We're still sort of in that stage, and you may see other comments like this throughout the code :)
    - gsnedders 10y ago
      And importantly, a panic is not a result of a memory safety bug, and those are the crashes (with their potential security risks) that Rust is aiming to get rid of.
    - AlisdairO 10y ago
      It would be quite nice if there was a synonym for expect (say unimplemented_expect) that meant 'I haven't bothered to implement the proper error handling yet' rather than 'error handling shouldn't be required'. That would really enhance auditability of in-progress code.
- alex_duf 10y ago
  >Maybe your rust code is fine but you're trying to open and write to the same file from two places which you don't realise because the users file system is case insensitive but you've only tested on a case sensitive one, etc That sounds too precise to be just an example :) We've all been there!
  - IanCal 10y ago
    Haha, yes, this kind of thing has bitten me a few times. I remember getting SVN really confused where the server thought files were different but my machine thought they were the same (or similar). I think I had to make a whole new repo. It's now on my mental list for "but it works on my machine", checking filenames and their cases.
lmm 10y ago
In pure Rust that never uses "unsafe", maybe. (Though even then, you only get memory safety; it's still possible to e.g. go into an infinite loop and use all CPU and/or memory).
- yoklov 10y ago
  It's also still possible to panic.
  - Jweb_Guru 10y ago
    Panic's implementation uses unsafe code, IIRC. But stuff like stack overflow can happen even without explicit unsafe code, I think.
    - kibwen 10y ago
      Rust intercepts most stack overflows and aborts the program when they occur. There are some more difficult cases where legit stack overflows are still possible, the resolution to which is blocked on LLVM support on most platforms (notably, Windows is the best here).
    - Manishearth 10y ago
      Well ultimately any useful program will use a library that uses unsafe. All I/O is unsafe at the bare metal so while you can safely wrap it it still is unsafe internallly. When talking about the usage of unsafe code in rust, we generally ignore encapsulated unsafe code in libstd since it has the same safety guarantees as tgr compiler itself. all unsafe code encapsulated in a safe API has these guarantees, but you trust libstd more :)
- mythmon_ 10y ago
  Does anyone know if Servo has any unsafe Rust code?
  - panic 10y ago
    Yes, quite a bit of it: https://github.com/servo/servo/search?l=rust&q=unsafe https://github.com/servo/servo/search?l=rust&q=unsafe
pcwalton 10y ago
> It often seems that every other post about Rust on HN says that if it compiles, it works. I'm always careful not to say that "if it compiles, it works"--no language can guarantee that (well, except those that prove your program correct). Instead I like to say "if it compiles, it will fail for a not-stupid reason". :)
ndesaulniers 10y ago
if feature_thats_not_implemented_yet: explicitly_crash

by pekk 10y ago

IanCal 10y ago

No language can fix missing functionality, that seems pretty clear. Your compiler doesn't know what you're trying to do, so you can't prevent all bugs. That leaves crashes, and ... well it may also depend on what you mean by a crash. The UI becomes unresponsive? Might have absolutely nothing to do with memory issues or even code written in rust. Maybe your rust code is fine but you're trying to open and write to the same file from two places which you don't realise because the users file system is case insensitive but you've only tested on a case sensitive one, etc. It's also multi-threaded and while languages can significantly help improve the safety of multi-threaded code, I don't think anything can stop you from creating a deadlock or putting your system into an inconsistent state. And finally, they may not even particularly expect those things, but putting out early nightly builds to a wider audience and expecting nothing to go wrong would be cavalier. A typical warning on many early releases is "don't blame me if this destroys all your files".

Manishearth 10y ago
By crashes we mean panics. We still panic in various places in the code when something goes wrong.
- tinco 10y ago
  To clarify, a panic in rust is the result of an unhandled exception. Usually this is due to laziness rather than a real bug. For example Servo might encounter an IMG tag, start to load the body. The result might be stored in an option because something could have gone wrong during loading (peer disconnected etc.) but the developer didn't feel like implementing robust image handling that day and instead called .expect to extract the image. This throws a panic and exits the application if the image is not there. This is just a hypothetical example, I bet image loading is one of the things Servo does fine. Just to give you an idea of when Rust might panic.
  - Morgawr 10y ago
    I do things like this all the time in Haskell when quickly prototyping new code and then swiftly kick myself because of it. Safe languages are nice, but there's really no way to prevent a developer from saying "Yeah fuck it, this case will never happen anyway" and then calling a fromJust on a Maybe monad which turns out was a Nothing and throws a runtime exception.
    - majewsky 10y ago
      Well, there is a way: Don't allow partial functions like fromJust or head. But a) it's going to make prototyping so tedious that no one will bother using this hypothetical language, and b) there are problems that you just cannot solve without partial functions (e.g. foldl1).
  - Manishearth 10y ago
    Heh. Earlier in this thread, someone did indeed find a bug in our image loading: https://news.ycombinator.com/item?id=12014108 https://news.ycombinator.com/item?id=12014108 We were basically panicking when an invalid URL was given to us. There was a comment there noting this -- which means that this was probably written when it wasn't so important to handle all the cases, and more important to handle some cases so that we can test out various ideas. We're still sort of in that stage, and you may see other comments like this throughout the code :)
  - gsnedders 10y ago
    And importantly, a panic is not a result of a memory safety bug, and those are the crashes (with their potential security risks) that Rust is aiming to get rid of.
  - AlisdairO 10y ago
    It would be quite nice if there was a synonym for expect (say unimplemented_expect) that meant 'I haven't bothered to implement the proper error handling yet' rather than 'error handling shouldn't be required'. That would really enhance auditability of in-progress code.
alex_duf 10y ago
>Maybe your rust code is fine but you're trying to open and write to the same file from two places which you don't realise because the users file system is case insensitive but you've only tested on a case sensitive one, etc That sounds too precise to be just an example :) We've all been there!
- IanCal 10y ago
  Haha, yes, this kind of thing has bitten me a few times. I remember getting SVN really confused where the server thought files were different but my machine thought they were the same (or similar). I think I had to make a whole new repo. It's now on my mental list for "but it works on my machine", checking filenames and their cases.

lmm 10y ago

In pure Rust that never uses "unsafe", maybe. (Though even then, you only get memory safety; it's still possible to e.g. go into an infinite loop and use all CPU and/or memory).

yoklov 10y ago
It's also still possible to panic.
- Jweb_Guru 10y ago
  Panic's implementation uses unsafe code, IIRC. But stuff like stack overflow can happen even without explicit unsafe code, I think.
  - kibwen 10y ago
    Rust intercepts most stack overflows and aborts the program when they occur. There are some more difficult cases where legit stack overflows are still possible, the resolution to which is blocked on LLVM support on most platforms (notably, Windows is the best here).
  - Manishearth 10y ago
    Well ultimately any useful program will use a library that uses unsafe. All I/O is unsafe at the bare metal so while you can safely wrap it it still is unsafe internallly. When talking about the usage of unsafe code in rust, we generally ignore encapsulated unsafe code in libstd since it has the same safety guarantees as tgr compiler itself. all unsafe code encapsulated in a safe API has these guarantees, but you trust libstd more :)
mythmon_ 10y ago
Does anyone know if Servo has any unsafe Rust code?
- panic 10y ago
  Yes, quite a bit of it: https://github.com/servo/servo/search?l=rust&q=unsafe https://github.com/servo/servo/search?l=rust&q=unsafe

pcwalton 10y ago

> It often seems that every other post about Rust on HN says that if it compiles, it works. I'm always careful not to say that "if it compiles, it works"--no language can guarantee that (well, except those that prove your program correct). Instead I like to say "if it compiles, it will fail for a not-stupid reason". :)

ndesaulniers 10y ago

if feature_thats_not_implemented_yet: explicitly_crash