6 ms·

Go is shit. Trust me, Rust will suit you better. Coming from C# it will be a lot closer to what you're used to than the bizzaro-world of Go.

ryenus 11y ago
I'm not against you, but to convince, you need to tell why, why the sh*t? why to trust you?
- lectrick 11y ago
  Lack of a runtime exception model would be one huge thing. So you basically have to check for errors after every operation, and whatever errors you don't check for just... get lost.
arthursilva 11y ago
Nonsense, go is fine, so is rust.
- andrewchambers 11y ago
  Both are really great. I think Go is better for servers and rust can be great on embedded and high performance applications.
  - arthursilva 11y ago
    The truth is that rust is in its infancy its all guesses at this point. Go didn't attract c++ people as people first guessed.
    - bsder 11y ago
      I saw them talking about that, but it's completely obvious. Nobody today is running C/C++ unless they need either A) complete speed or B) bare metal. Go can't do either, so there was going to be very little transfer from C/C++ to Go.
      - prewett 11y ago
        C++ is still mostly what I use, but I need neither speed nor bare metal. Maybe add C) people doing UI and applications? There aren't many other good options: Java: UI looks terrible; it's annoying living in Noun-land when CPUs are, if anything, more about verbs than nouns; and running properly on Windows is not trivial. C#: Up until recently, not cross-platform unless you're ok with Mono. (But, might be worth looking in to now) Python: great for scripts and experiments. The lack of static typing is a real problem when working with code other people wrote. Also, UI is not a strong point. Go: what UI libraries? (I'm sure they exist) Objective-C: even on iOS/Mac-only projects, I still prefer C++, because it's so much easier to use STL objects than NS data structures. C++: you can pretty much get it done, and often you can use Qt to get it done quickly and cross-platformy. I'm hoping Rust will be the C++ I always wanted.
        kibwen 11y ago
        Most GUI toolkits for Rust are in their infancy, but I hear that Gnome will be working on integrating Rust with GObject this year, which should allow Rust to leverage Gtk: https://wiki.gnome.org/GUADEC/2015/BOFs/Rust https://wiki.gnome.org/GUADEC/2015/BOFs/Rust Some preliminary work towards this: https://github.com/gi-rust/glib-sys https://github.com/gi-rust/glib-sys
        bsder 11y ago
        > I hear that Gnome will be working on integrating Rust with GObject this year, which should allow Rust to leverage Gtk: This disappoints me greatly. The idea of an object hierarchical GUI is not a guaranteed given. It causes things like "primary UI thread" which doesn't need to exist anymore. It is a reflection of a time when memory and CPU was more scarce. In the face of massively parallel CPU's and huge memory, a tile-based, constraint GUI with publish-subscribe is probably a much better choice. This is especially true with a language that promotes concurrent programming. I suspect, sadly, that we're simply going to continue down the same broken, single-threaded UI path because of the installed codebases.
        rhodysurf 11y ago
  - simcop2387 11y ago
    I've been tempted to try getting rust going on some of the small arm micros I've got lying around. The memory safety would be tremendous boon for a lot of development there, same with the ownership/lifetime management. I think I'd probably have to strike most of the standard library but it'd still be really useful.
    - andrewchambers 11y ago
      For me I keep seeing buffer overflows in router management stacks. It seems like rust would help protect routers from attack, while allowing low footprints.
      - simcop2387 11y ago
        Yea that's a common one I've done in a bunch of microcontroller things I've done. And there it's even more dangerous because you'll overflow the buffer, and change something and never have ANY idea you've done it until the consequences have happened. I ran into quite of few of those while setting up an allocator to get Lua running in <30k of ram without any floating point math.
    - Animats 11y ago
      Rust is likely to be popular for embedded work, where debugging is hard and crashing is often not tolerated. Go is primarily for server-side web applications. That's Google's main business area, that's what they built it for, and that's where all the libraries are well-debugged.
voltagex_ 11y ago
I need more info than that.

ryenus 11y ago

I'm not against you, but to convince, you need to tell why, why the sh*t? why to trust you?

lectrick 11y ago
Lack of a runtime exception model would be one huge thing. So you basically have to check for errors after every operation, and whatever errors you don't check for just... get lost.

arthursilva 11y ago

Nonsense, go is fine, so is rust.

andrewchambers 11y ago
Both are really great. I think Go is better for servers and rust can be great on embedded and high performance applications.
- arthursilva 11y ago
  The truth is that rust is in its infancy its all guesses at this point. Go didn't attract c++ people as people first guessed.
  - bsder 11y ago
    I saw them talking about that, but it's completely obvious. Nobody today is running C/C++ unless they need either A) complete speed or B) bare metal. Go can't do either, so there was going to be very little transfer from C/C++ to Go.
    - prewett 11y ago
      C++ is still mostly what I use, but I need neither speed nor bare metal. Maybe add C) people doing UI and applications? There aren't many other good options: Java: UI looks terrible; it's annoying living in Noun-land when CPUs are, if anything, more about verbs than nouns; and running properly on Windows is not trivial. C#: Up until recently, not cross-platform unless you're ok with Mono. (But, might be worth looking in to now) Python: great for scripts and experiments. The lack of static typing is a real problem when working with code other people wrote. Also, UI is not a strong point. Go: what UI libraries? (I'm sure they exist) Objective-C: even on iOS/Mac-only projects, I still prefer C++, because it's so much easier to use STL objects than NS data structures. C++: you can pretty much get it done, and often you can use Qt to get it done quickly and cross-platformy. I'm hoping Rust will be the C++ I always wanted.
      - kibwen 11y ago
        Most GUI toolkits for Rust are in their infancy, but I hear that Gnome will be working on integrating Rust with GObject this year, which should allow Rust to leverage Gtk: https://wiki.gnome.org/GUADEC/2015/BOFs/Rust https://wiki.gnome.org/GUADEC/2015/BOFs/Rust Some preliminary work towards this: https://github.com/gi-rust/glib-sys https://github.com/gi-rust/glib-sys
        bsder 11y ago
        > I hear that Gnome will be working on integrating Rust with GObject this year, which should allow Rust to leverage Gtk: This disappoints me greatly. The idea of an object hierarchical GUI is not a guaranteed given. It causes things like "primary UI thread" which doesn't need to exist anymore. It is a reflection of a time when memory and CPU was more scarce. In the face of massively parallel CPU's and huge memory, a tile-based, constraint GUI with publish-subscribe is probably a much better choice. This is especially true with a language that promotes concurrent programming. I suspect, sadly, that we're simply going to continue down the same broken, single-threaded UI path because of the installed codebases.
      - rhodysurf 11y ago
- simcop2387 11y ago
  I've been tempted to try getting rust going on some of the small arm micros I've got lying around. The memory safety would be tremendous boon for a lot of development there, same with the ownership/lifetime management. I think I'd probably have to strike most of the standard library but it'd still be really useful.
  - andrewchambers 11y ago
    For me I keep seeing buffer overflows in router management stacks. It seems like rust would help protect routers from attack, while allowing low footprints.
    - simcop2387 11y ago
      Yea that's a common one I've done in a bunch of microcontroller things I've done. And there it's even more dangerous because you'll overflow the buffer, and change something and never have ANY idea you've done it until the consequences have happened. I ran into quite of few of those while setting up an allocator to get Lua running in <30k of ram without any floating point math.
  - Animats 11y ago
    Rust is likely to be popular for embedded work, where debugging is hard and crashing is often not tolerated. Go is primarily for server-side web applications. That's Google's main business area, that's what they built it for, and that's where all the libraries are well-debugged.

voltagex_ 11y ago

I need more info than that.