4 ms·

Between Rust and Go (for Pythonistas) I still prefer Rust. One thing that bothers me in Go is that, like Ruby, when you import something you don't know exactly

Between Rust and Go (for Pythonistas) I still prefer Rust. One thing that bothers me in Go is that, like Ruby, when you import something you don't know exactly what's being injected in the context. So it's quite bad to understand from where some things came from. I like more the Python / Rust approach for that.

ForHackernews 11y ago
Maybe it's just because Go has Google backing it, but I seem to hear way more about Go than I do about Rust. I have my doubts about whether Rust will have a viable ecosystem in 4-5 years. It's a shame because Rust seems like a more interesting language to me.
- Jweb_Guru 11y ago
  It might also have something to do with the fact that Go has been out for five years and Rust 1.0 happened two weeks ago, or the fact that you are hearing about Go in different contexts from Rust because the two languages, despite HN's insistence to the contrary, aren't really appropriate for the same use cases.
  - ForHackernews 11y ago
    Are there any good articles comparing the two? What are some contexts where one might be more appropriate than the other? I know Go's special focus is on concurrency. Is Rust less-good for concurrent applications?
    - Jweb_Guru 11y ago
      Rust is best viewed as a replacement for C++ in performance-critical, security-critical applications that are either resource-intensive, or exist in a resource-starved environment. In particular, it eschews garbage collection while preserving memory safety, even in the presence of multiple threads, something C++ does not. It also has native, overhead-free FFI-level compatibility with C. An example of where Rust is appropriate would be an operating system kernel, a video game, a web browser (writing one, not writing code that runs within one), embedded development, a high-performance database (there aren't any existing examples yet but it strikes me as an ideal language for this purpose), or fast, native extensions to applications written in higher level languages. Go is a relatively fast, ahead-of-time compiled, garbage-collected language; a good comparable for when you might want to use it would be OCaml (if you don't need threads) or Haskell (if you do). Java (particularly early versions of Java) or C# would also be a good comparable, in circumstances where you don't care about the JIT. Like Haskell, Go also has very good support for M:N threads, a particular threading model optimized for fast context switching and programmer ease of use (a common requirement for socket web servers). Unlike many ahead-of-time compiled languages, it also has compiler performance as an overriding concern--Go prides itself on its quick compilation. I would not say Go is better than Rust at concurrency. While Rust used to have M:N threads as well, it abandoned them because they turned out to have unacceptable performance tradeoffs in a language without a heavy runtime and garbage collector, and also play poorly with native code not managed by the runtime. Personally, I also feel that safe concurrency is considerably easier in Rust, where common Go idioms like channels are guaranteed to be memory safe, which they are not in Go with GOMAXPROCS > 1, and where it's impossible to see data races through things like mutexes or lockless data parallel threads in safe code. The reason to use Go over Rust would be that you can afford a garbage collector and a relatively heavy runtime, and are willing to accept some chance of data races (or don't require concurrency at all, or have a particular concurrent application where by far your biggest cost is context switching and you do very little allocation). This is the case for a large percentage of applications. Of course, there are many other languages available under these circumstances as well. I am not personally sure why people are espousing Rust for these applications, FWIW.
      - masklinn 11y ago
        > Java (particularly early versions of Java) or C# would also be a good comparable, in circumstances where you don't care about the JIT. Or if you're using a native code compilers (not sure about C#, but they exist for Java).
        Jweb_Guru 11y ago
        They exist for C# as well, so this is a good point.
- aaron-lebo 11y ago
  Rust is newer, but Go is also more relevant to the crowd here. Most people writing web apps don't need a language where you have to worry about ownership, but they do need a language that does concurrency really well. It's the same reason you hear more about Python or Ruby than C++ here. Use cases. Even as Rust matures, it is unlikely that people will be writing a lot of web apps in it.
  - BuckRogers 11y ago
    Can someone explain why the parent was downvoted? Difference of opinion or is there actual reasoning. Because if there is reasoning, I'd be interested to hear it. But this seems like shaming. Stop. Or explain why he's wrong. Other than the "Go is more relevant to the crowd here" which is a bit overarching, I don't see what's wrong here. I'm a Python user that has my eye on Go instead of transitioning to Python3, but letting Rust/Go/Py3 all bake for a bit before doing anything (though Py3 is last on that list as I've lost faith in it at this point). I tend to agree with his viewpoint. Do go on.
    - aaron-lebo 11y ago
      I'm not sure if this is the reason, but I have noticed that there is a definite backlash against Go here and on /r/programming, especially when discussed in relation to "better" languages like Haskell and Rust.
      - commentzorro 11y ago
        FWIW, in English there's no need to use quotes when referencing a word in its standard meaning.
        deleted 11y ago
        [deleted]
        aaron-lebo 11y ago
        Well done.
- kibwen 11y ago
  Rust is currently backed by Mozilla, Samsung, and an expanding coalition of startups. There are other large companies experimenting with Rust at the moment, but I'd rather wait for them to come out with their own announcements. The community is hugely active and growing at an increasing rate. There are four Rust books in the publishing pipeline and Rust's first conference will be held this year, with at least two conferences already planning for next year. I wouldn't worry about the state of Rust's ecosystem in five years. :)
  - alfiedotwtf 11y ago
    Rust conferences? I've seemed to have missed this. Any links/info?
    - steveklabnik 11y ago
      We announced http://rustcamp.com/ http://rustcamp.com/ today.
      - alfiedotwtf 11y ago
        Ah cool. I thought that might have been one of them. Was just interested if others have been announced too :)
NateDad 11y ago
Nothing gets imported into the namespace when you import a package in go, except a reference to the package itself. The only way to pollute the namespace is to use import "foo" . which is strongly discouraged.

ForHackernews 11y ago

Maybe it's just because Go has Google backing it, but I seem to hear way more about Go than I do about Rust. I have my doubts about whether Rust will have a viable ecosystem in 4-5 years. It's a shame because Rust seems like a more interesting language to me.

Jweb_Guru 11y ago
It might also have something to do with the fact that Go has been out for five years and Rust 1.0 happened two weeks ago, or the fact that you are hearing about Go in different contexts from Rust because the two languages, despite HN's insistence to the contrary, aren't really appropriate for the same use cases.
- ForHackernews 11y ago
  Are there any good articles comparing the two? What are some contexts where one might be more appropriate than the other? I know Go's special focus is on concurrency. Is Rust less-good for concurrent applications?
  - Jweb_Guru 11y ago
    Rust is best viewed as a replacement for C++ in performance-critical, security-critical applications that are either resource-intensive, or exist in a resource-starved environment. In particular, it eschews garbage collection while preserving memory safety, even in the presence of multiple threads, something C++ does not. It also has native, overhead-free FFI-level compatibility with C. An example of where Rust is appropriate would be an operating system kernel, a video game, a web browser (writing one, not writing code that runs within one), embedded development, a high-performance database (there aren't any existing examples yet but it strikes me as an ideal language for this purpose), or fast, native extensions to applications written in higher level languages. Go is a relatively fast, ahead-of-time compiled, garbage-collected language; a good comparable for when you might want to use it would be OCaml (if you don't need threads) or Haskell (if you do). Java (particularly early versions of Java) or C# would also be a good comparable, in circumstances where you don't care about the JIT. Like Haskell, Go also has very good support for M:N threads, a particular threading model optimized for fast context switching and programmer ease of use (a common requirement for socket web servers). Unlike many ahead-of-time compiled languages, it also has compiler performance as an overriding concern--Go prides itself on its quick compilation. I would not say Go is better than Rust at concurrency. While Rust used to have M:N threads as well, it abandoned them because they turned out to have unacceptable performance tradeoffs in a language without a heavy runtime and garbage collector, and also play poorly with native code not managed by the runtime. Personally, I also feel that safe concurrency is considerably easier in Rust, where common Go idioms like channels are guaranteed to be memory safe, which they are not in Go with GOMAXPROCS > 1, and where it's impossible to see data races through things like mutexes or lockless data parallel threads in safe code. The reason to use Go over Rust would be that you can afford a garbage collector and a relatively heavy runtime, and are willing to accept some chance of data races (or don't require concurrency at all, or have a particular concurrent application where by far your biggest cost is context switching and you do very little allocation). This is the case for a large percentage of applications. Of course, there are many other languages available under these circumstances as well. I am not personally sure why people are espousing Rust for these applications, FWIW.
    - masklinn 11y ago
      > Java (particularly early versions of Java) or C# would also be a good comparable, in circumstances where you don't care about the JIT. Or if you're using a native code compilers (not sure about C#, but they exist for Java).
      - Jweb_Guru 11y ago
        They exist for C# as well, so this is a good point.
aaron-lebo 11y ago
Rust is newer, but Go is also more relevant to the crowd here. Most people writing web apps don't need a language where you have to worry about ownership, but they do need a language that does concurrency really well. It's the same reason you hear more about Python or Ruby than C++ here. Use cases. Even as Rust matures, it is unlikely that people will be writing a lot of web apps in it.
- BuckRogers 11y ago
  Can someone explain why the parent was downvoted? Difference of opinion or is there actual reasoning. Because if there is reasoning, I'd be interested to hear it. But this seems like shaming. Stop. Or explain why he's wrong. Other than the "Go is more relevant to the crowd here" which is a bit overarching, I don't see what's wrong here. I'm a Python user that has my eye on Go instead of transitioning to Python3, but letting Rust/Go/Py3 all bake for a bit before doing anything (though Py3 is last on that list as I've lost faith in it at this point). I tend to agree with his viewpoint. Do go on.
  - aaron-lebo 11y ago
    I'm not sure if this is the reason, but I have noticed that there is a definite backlash against Go here and on /r/programming, especially when discussed in relation to "better" languages like Haskell and Rust.
    - commentzorro 11y ago
      FWIW, in English there's no need to use quotes when referencing a word in its standard meaning.
      - deleted 11y ago
        [deleted]
      - aaron-lebo 11y ago
        Well done.
kibwen 11y ago
Rust is currently backed by Mozilla, Samsung, and an expanding coalition of startups. There are other large companies experimenting with Rust at the moment, but I'd rather wait for them to come out with their own announcements. The community is hugely active and growing at an increasing rate. There are four Rust books in the publishing pipeline and Rust's first conference will be held this year, with at least two conferences already planning for next year. I wouldn't worry about the state of Rust's ecosystem in five years. :)
- alfiedotwtf 11y ago
  Rust conferences? I've seemed to have missed this. Any links/info?
  - steveklabnik 11y ago
    We announced http://rustcamp.com/ http://rustcamp.com/ today.
    - alfiedotwtf 11y ago
      Ah cool. I thought that might have been one of them. Was just interested if others have been announced too :)

NateDad 11y ago

Nothing gets imported into the namespace when you import a package in go, except a reference to the package itself. The only way to pollute the namespace is to use import "foo" . which is strongly discouraged.