5 ms·

I don't understand why would you choose Rust over Go for backend stuff. From what I see here on HN, Rust doesn't target backend app?

by Thaxll 11y ago

eru 11y ago
Rust is a nicer language than Go---especially its type system. That might be reason enough. What do you mean by `doesn't target backend app'?
echelon 11y ago
I've already written several components of my home automation system in Rust. Mio, Hyper, Iron, etc. are great tools for developing microservices. I cross-compiled this stuff to run on Raspberry Pi, and the binaries are so small and performant!
- jonreem 11y ago
  Hey, main author of iron here, I'd love to hear more about your use of iron! It's always nice to hear from users and your feedback is crucial to driving the project forward. Feel free to respond here or reach out (contact details in my profile, you can find me as reem on the mozilla irc network).
- Manishearth 11y ago
  I'd really love to see some blog posts and/or code about this. It sounds super-cool!
- Cshelton 11y ago
  Awesome! I'm working on a home automation platform as well! Not close to being done (started last week). I'd love to see some code or examples of what you've come up with!
paulddraper 11y ago
Because he doesn't enjoy casting every time he iterates over a collection? Because he doesn't like NULL pointers aka the worst mistake of CS?https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/ https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis... Because he doesn't want a package manager that always fetches HEAD? I'm not saying Go is a poorly designed language where the answer to every decision is the easiest one for the implementors. I'm just saying there's a legitimate case to be made.
- nindalf 11y ago
  Have you actually had problems with nil pointers in Go? I've written it for years without facing it so perhaps you're doing something radically different if you managed to come across it.
  - sebcat 11y ago
    My experience is the same. Go mitigates pointer problems very well by having zero values and explicitly separating error returns. If anyone complains about having nil in Go, I usually assume they're either forced to work a really bad codebase or lack experience in Go. I've worked on a Go codebase for ~2 years, and I'm pretty sure the only nil pointer dereference I've seen was due to a concurrency bug, where an object cache (implemented as an array, not sync.Pool) was not locked properly. The problem with having nil is when you expect a value to be either a valid pointer or nil to indicate an error, and you forget to check for an error. In Go, in my experience, explicit error checking and multiple return values makes that a non-problem, however ugly some people consider it to be. If I see error assignments to _, that makes me raise my eyebrows.
    - pcwalton 11y ago
      How do zero values help here? Zero values would seem to me to make nil pointer panics easier to run across, because it means the language can silently insert nil into your data structures or assign nil to your variables without any syntactic indication. > The problem with having nil is when you expect a value to be either a valid pointer or nil to indicate an error, and you forget to check for an error. That's not the problem with null pointers. Null is used all over the place for non-error conditions. The problem is when an object legitimately might or might not be present, but the type doesn't encode that fact, so some code mistakenly assumes that the object is always present when it isn't.
      - masklinn 11y ago
        > The problem is when an object legitimately might or might not be present, but the type doesn't encode that fact, so some code mistakenly assumes that the object is always present when it isn't. Yes reworded slightly, types encode value invariants, nullable types can't encode one of their invariants.
Manishearth 11y ago
> Rust doesn't target backend app? This isn't the case. We have web backend libraries (servers, database thingies, template engines, I/O, etc) and it's totally possible to work on backend stuff in Rust. Rust doesn't "not target" much, really. Most of what you do in Python/Go/Ruby is also something we want Rust to work for. There is a false dichotomy of "fast language or safe language" which Rust does away with -- it's not only for situations where you would usually use C++.
- pjmlp 11y ago
  Until the rise of scripting languages we would use compiled languages for everything. It feels odd that someone would question it nowadays. I surely do hope Rust gets used for everything.
  - ktRolster 11y ago
    Except there were always those LISP guys in the back talking about how great the REPL was
    - pjmlp 11y ago
      So what? Almost every programming language can have a REPL, it is called an interpreter. Anyone with a CS background should know this. Also Lisp is a compiled language since the early days.
      - coldtea 11y ago
        >Almost every programming language can have a REPL, it is called an interpreter. Anyone with a CS background should know this. That's the theory though. The practice is (was) that Lisp had an excellent REPL, and most languages didn't have one at all, or had a crappy one. Some languages lend themselves to a REPL by making it much easier to program one. iPython is great, JS ones are decent. Go attempts at REPLs otoh are mostly BS. C++ REPLs (Cling) etc, are neither very handy nor very popular. Etc. The truth is, some languages handle the REPL situation much better than others. And "scripting" languages are usually better than others at that. And REPL is not really just an interpreter. You can have an interpreter without having a REPL, or without having the kind of full featured REPL we're talking about. Most BASICs run with an interpreter, but didn't have a REPL, for example.
allan_s 11y ago
I've posted reasons why here : https://news.ycombinator.com/item?id=10949667 https://news.ycombinator.com/item?id=10949667 more reasons: On error handling, in Go most of libraries and even some part of the std lib, erros are constant string, which mean that for example you can only do `err == foo.DUPLICATE_KEY_ERROR` but you can't extract which key, or then you start to have to either use an external library to do some string masking/unmasking, which complicate quite things and add one more dependency, or just to say "screw it, i will just log 'duplicate key error" which is unoptimal I really did try go, to the point I even proposed a fix in the std library for a long standing bug in the xml library https://go-review.googlesource.com/#/c/15684/ https://go-review.googlesource.com/#/c/15684/ , but not all the reason stated above makes me consider go as "yes sure it's an improvement over php/python/c++" but rust is like an even bigger improvement

I don't understand why would you choose Rust over Go for backend stuff. From what I see here on HN, Rust doesn't target backend app?

by Thaxll 11y ago

I don't understand why would you choose Rust over Go for backend stuff. From what I see here on HN, Rust doesn't target backend app?

eru 11y ago

Rust is a nicer language than Go---especially its type system. That might be reason enough. What do you mean by `doesn't target backend app'?

echelon 11y ago

I've already written several components of my home automation system in Rust. Mio, Hyper, Iron, etc. are great tools for developing microservices. I cross-compiled this stuff to run on Raspberry Pi, and the binaries are so small and performant!

jonreem 11y ago
Hey, main author of iron here, I'd love to hear more about your use of iron! It's always nice to hear from users and your feedback is crucial to driving the project forward. Feel free to respond here or reach out (contact details in my profile, you can find me as reem on the mozilla irc network).
Manishearth 11y ago
I'd really love to see some blog posts and/or code about this. It sounds super-cool!
Cshelton 11y ago
Awesome! I'm working on a home automation platform as well! Not close to being done (started last week). I'd love to see some code or examples of what you've come up with!

paulddraper 11y ago

Because he doesn't enjoy casting every time he iterates over a collection? Because he doesn't like NULL pointers aka the worst mistake of CS?https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/ https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis... Because he doesn't want a package manager that always fetches HEAD? I'm not saying Go is a poorly designed language where the answer to every decision is the easiest one for the implementors. I'm just saying there's a legitimate case to be made.

nindalf 11y ago
Have you actually had problems with nil pointers in Go? I've written it for years without facing it so perhaps you're doing something radically different if you managed to come across it.
- sebcat 11y ago
  My experience is the same. Go mitigates pointer problems very well by having zero values and explicitly separating error returns. If anyone complains about having nil in Go, I usually assume they're either forced to work a really bad codebase or lack experience in Go. I've worked on a Go codebase for ~2 years, and I'm pretty sure the only nil pointer dereference I've seen was due to a concurrency bug, where an object cache (implemented as an array, not sync.Pool) was not locked properly. The problem with having nil is when you expect a value to be either a valid pointer or nil to indicate an error, and you forget to check for an error. In Go, in my experience, explicit error checking and multiple return values makes that a non-problem, however ugly some people consider it to be. If I see error assignments to _, that makes me raise my eyebrows.
  - pcwalton 11y ago
    How do zero values help here? Zero values would seem to me to make nil pointer panics easier to run across, because it means the language can silently insert nil into your data structures or assign nil to your variables without any syntactic indication. > The problem with having nil is when you expect a value to be either a valid pointer or nil to indicate an error, and you forget to check for an error. That's not the problem with null pointers. Null is used all over the place for non-error conditions. The problem is when an object legitimately might or might not be present, but the type doesn't encode that fact, so some code mistakenly assumes that the object is always present when it isn't.
    - masklinn 11y ago
      > The problem is when an object legitimately might or might not be present, but the type doesn't encode that fact, so some code mistakenly assumes that the object is always present when it isn't. Yes reworded slightly, types encode value invariants, nullable types can't encode one of their invariants.

Manishearth 11y ago

> Rust doesn't target backend app? This isn't the case. We have web backend libraries (servers, database thingies, template engines, I/O, etc) and it's totally possible to work on backend stuff in Rust. Rust doesn't "not target" much, really. Most of what you do in Python/Go/Ruby is also something we want Rust to work for. There is a false dichotomy of "fast language or safe language" which Rust does away with -- it's not only for situations where you would usually use C++.

pjmlp 11y ago
Until the rise of scripting languages we would use compiled languages for everything. It feels odd that someone would question it nowadays. I surely do hope Rust gets used for everything.
- ktRolster 11y ago
  Except there were always those LISP guys in the back talking about how great the REPL was
  - pjmlp 11y ago
    So what? Almost every programming language can have a REPL, it is called an interpreter. Anyone with a CS background should know this. Also Lisp is a compiled language since the early days.
    - coldtea 11y ago
      >Almost every programming language can have a REPL, it is called an interpreter. Anyone with a CS background should know this. That's the theory though. The practice is (was) that Lisp had an excellent REPL, and most languages didn't have one at all, or had a crappy one. Some languages lend themselves to a REPL by making it much easier to program one. iPython is great, JS ones are decent. Go attempts at REPLs otoh are mostly BS. C++ REPLs (Cling) etc, are neither very handy nor very popular. Etc. The truth is, some languages handle the REPL situation much better than others. And "scripting" languages are usually better than others at that. And REPL is not really just an interpreter. You can have an interpreter without having a REPL, or without having the kind of full featured REPL we're talking about. Most BASICs run with an interpreter, but didn't have a REPL, for example.

allan_s 11y ago

I've posted reasons why here : https://news.ycombinator.com/item?id=10949667 https://news.ycombinator.com/item?id=10949667 more reasons: On error handling, in Go most of libraries and even some part of the std lib, erros are constant string, which mean that for example you can only do `err == foo.DUPLICATE_KEY_ERROR` but you can't extract which key, or then you start to have to either use an external library to do some string masking/unmasking, which complicate quite things and add one more dependency, or just to say "screw it, i will just log 'duplicate key error" which is unoptimal I really did try go, to the point I even proposed a fix in the std library for a long standing bug in the xml library https://go-review.googlesource.com/#/c/15684/ https://go-review.googlesource.com/#/c/15684/ , but not all the reason stated above makes me consider go as "yes sure it's an improvement over php/python/c++" but rust is like an even bigger improvement