15 ms·

On similar note, why Rust over Go? If I look at everything I used to write in C, I'd say 80% is well suited for Go and the rest I would fallthrough to Rust for

• burntsushi 10y ago
  I don't use Rust just because I want to avoid GC. I also use it for algebraic data types, compile time elimination of data races, sophisticated polymorphism, a clear and simple module system, excellent tooling in the form of Cargo and an unrelenting focus on providing abstractions with as little overhead as possible. (I've used Go and Rust daily for the past few years. I love them both.)
  • santaclaus 10y ago
    > I don't use Rust just because I want to avoid GC. Go that is?
    • burntsushi 10y ago
      Hmm, not sure I understand? Re-reading, perhaps my phrasing wasn't clear. What I meant was that I use Rust, and it's not simply because it lacks GC. There are lots of other good reasons too. To be even clearer: I don't think Rust's value proposition depends on whether you absolutely must avoid GC or not.
      • empath75 10y ago
        Rust has gc, no?
        • colejohnson66 10y ago
          Depends on your Rust implementation. You can have an implementation without one and use it to make, say, an operating system.
          • steveklabnik 10y ago
            There is only one implementation of Rust, and it does not have tracing GC. The language does not include semantics for one, so it would be an extension of the language.
            • colejohnson66 10y ago
              Right. I had that backwards. (I don't program Rust)
              • TheDong 10y ago
                > I don't program Rust If you don't know anything about rust, you shouldn't respond to a question about rust.
        • dcsommer 10y ago
          Not in the mandatory runtime overhead, cycle collection, or non-deterministic pausing senses of the word.
        • dignan 10y ago
          No, it does not. It does allow you to implement it if you want though: https://github.com/Manishearth/rust-gc https://github.com/Manishearth/rust-gc
        • 404-universe 10y ago
          Not really, no. You could implement one with e.g. reference counting, but one is not provided for you by default.
        • lossolo 10y ago
          It has reference counting for some of the constructs which is a form of garbage collection and it has runtime overhead. Like shared_ptr in c++.
    • jjnoakes 10y ago
      No. He is saying he uses rust to avoid GC, but not just to avoid GC.
  • voidlogic 10y ago
    Good point. I agree there are other reasons to use Go, I what mean is that unless I have a project that gets a lot of bang for the buck out of those, the KISSness of Go wins out over those nice features and their correlated complexity. GC was just at the forefront of that list of features.
    • Ericson2314 10y ago
      There's simple, and there's anti-intellectual. Go would be the latter.
      • oblio 10y ago
        Well, in many respects Basic, PHP, Javascript, Java all had various forms of "anti-intellectualism" baked. They lost some of them along the way. Still, the fact that all those languages are in the top 10 of programming languages kind of says that people don't really care.
      • _callcc 10y ago
        Go is against the sort of programming that builds up conceptual dream worlds of gratuitous abstraction and needless complexity. When that's the only way you want to think, Go will indeed seem anti-intellectual.
        • tigershark 10y ago
          A modern programming language without any whatsoever support for generics from my point of view is just extremely bad, for someone else can very well be proof of anti-intellectualism.
• moosingin3space 10y ago
  The ownership system isn't strictly about memory management and can make it easier to catch yourself making larger architectural errors, and you can have more confidence in a refactor with Rust than Go. In fact, I'd argue Rust leads to simpler architectures that fit well into the ownership model as opposed the the "ad-hoc" architectures programs written in other languages seem to invariably turn into.
• dispose13432 10y ago
  >On similar note, why Rust over Go? I was going to say that rust has performance advantages over Go (due to GC), but look at benchmarks: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Go wins some and looses some, but it's all in the ballpark (except Binary trees [1] which it loses even to Java(!)). It's true that rust is a new language, but so is Go. [1]: I assume it's because it's a test of GC, but Go loses to Java (which, like Go, is a GC language)
  • merb 10y ago
    yeah of course, doing simple programs and checking their time is a good benchmark... oh wait.. also real world performance in bigger programs is mostly different, especially when you deal with big heaps. Btw. this site is extremly bad for benchmarks since it also measure's the startup time of the runtime in java/go/rust.
    • igouy 10y ago
      > startup time http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html#jvm-startup-time http://benchmarksgame.alioth.debian.org/sometimes-people-jus...
    • FreeFull 10y ago
      Rust doesn't have any significant runtime startup cost, but it certainly is an issue for Java (and presumably Go as well).
      • igouy 10y ago
        It is an issue for Java programs that complete in a few tenths of a second. So these do more work than a few tenths of a second.
  • mmstick 10y ago
    This is only because the Rust implementations are using particularly slow code paths, either because SIMD/AVX optimizations requires a nightly compiler, some optimizations would require unsafe code, or that other languages are using particularly hacky code that would never fly in real world software. For example, many of the Java/C/C++ benchmarks are using custom optimizations that should be illegal for the benchmarking. Case in point, some are featuring custom hash maps that feature hashing algorithms that, while fast, would never be useful as they provide no protection against collisions. You'll see a hashing algorithm in a C preprocessor, for example, that just fakes having an actual algorithm whereas Rust examples are sticking to the tried and tested production-grade algorithms shipping in the standard library.
• mmstick 10y ago
  I was writing software in Go for a year before I switched to Rust. I've not felt a need to touch Go since. Basically, anything you can do in Go, you can also do in Rust, but Rust will let you do it with higher efficiency and with significantly less lines of code. In the end, it's just easier to write software with Rust than it is Go. Feature-wise, Rust features generics and functional programming via higher-order functions and iterators, which is something that Go especially lacks in. Go doesn't have nice concepts like `Option`, `Result`, or `Iterator`. That's not something I'd personally want to live without today. The Go method is effectively writing boiler plate code everywhere, which leads to much room for error prone implementations that require more testing. I haven't felt that Rust was more complex than Go, at least when you're actually writing software in Rust. Rust libraries feature semantic versioning and are automatically downloaded and verified at build time based on the contents of your `Cargo.toml` and `Cargo.lock` files. No importing of Git repositories directly required. Go does not provide an equal on that front. There are a lot of great libraries out there to bring you extreme performance, simply, such as the bytecount crate, which is just a library that features a single function, a function that counts the occurrence of a specific byte, 32 bytes at a time with AVX, with additional SSE/SIMD implementations depending on what the processor supports. All there is to truly know about Rust is the borrowing and ownership mechanism and how to implement a custom `Iterator`. If you have a solid understanding of both then you've pretty much mastered all you need to know about Rust. The borrowing and ownership mechanism can be simplified down to: - Passing a variable by value will move ownership, dropping the original variable from memory - Passing a variable by mutable reference will keep the original variable, but allow you to modify the variable. - You may only borrow a variable mutably once at a time, and you may not immutably borrow while mutably borrowing. - You may have as many immutable borrows as you want, so long as you aren't modifying that value. - You may mutably borrow a field in a struct, and then mutably borrow a different field in the same struct simultaneously, so long as you aren't also mutably borrowing the overall struct. - You can use `Cell` and `RefCell` to allow for mutably modifying an immutable field in a struct. - You may mutably borrow multiple slices from the same array simultaneously so long as there is no overlap. - Safe memory practices means that instead of mutably borrowing the same variable in multiple places, you queue the changes to make in a separate location and apply them serially one after another. Then for the `Iterator` trait, you would know that all traits have required methods, whereby as long as you implement the required methods for your type, you will automatically gain all of the other methods associated with the trait. For the `Iterator` type, you only need to implement the `next` method, and that looks something like so: ``` struct DataIterator<'a> { data: &'a [u8], index: usize, } enum Token<'a> { One(&'a [u8]), Two(&'a [u8]) } impl<'a> Iterator for DataIterator<'a> { type Item = Token<'a>; fn next(&mut self) -> Option<Token<'a>> { let start = self.read; for element in self.data.iter().skip(self.read) { self.read += 1; // if next value is found then return Some(&value[start..self.read]) } None } } ```
• catnaroek 10y ago
  Go's GC isn't a big deal for most use cases. However, the loss of static guarantees regarding thread-safe manipulation of arbitrarily complex data structures is a big deal.
• plandis 10y ago
  For me this is pretty easy. It's about leadership. The leaders of Go foster an attitude of exclusiveness (just like a month ago they wanted to get rid of the Go subreddit in favor of a solely Google owned option of Google groups). The leaders of Rust are very receptive and helpful to new people. They are on IRC / Reddit and many other channels. I'd much rather invest my time into a truly open language and to me, that is not Go.
  • NoahTheDuke 10y ago
    > (just like a month ago they wanted to get rid of the Go subreddit in favor of a solely Google owned option of Google groups) Wow, really? Do you have a link to that discussion? That's wild.
    • gmjosack 10y ago
      I believe this post was stickied at the top of the golang subreddit for a bit: https://www.reddit.com/r/golang/comments/5eubdp/the_future_of_rgolang/ https://www.reddit.com/r/golang/comments/5eubdp/the_future_o... It should be a good summary of the event.
  • atombender 10y ago
    > just like a month ago they wanted to get rid of the Go subreddit To be fair, this was a proposal by a single person on the Go mailing list, and it was in reaction to Reddit's CEO publicly admitting to editing other users' comments. The person who proposed closing the Go subreddit was also under the mistaken impression that the subreddit was hosted by the Go team, which wasn't the case. In the end, there was a lot of discussion, and nothing was deleted. Tempest in a teapot, as usual. Go has a serious culture problem, but that's not a good example of it.
    • euyyn 10y ago
      What's a good example of it?
      • 10y ago
• pornel 10y ago
  I write libraries. In Go I can only write libraries for Go programs. In Rust I can write libraries for any program. i.e. Rust can easily produce static and dynamic libraries that are linkable with C programs and any language with a C FFI. I can write Rust code that works for programmers using C, C++, C#, D, Go, Swift, Python, PHP, Java, etc.
  • shanemhansen 10y ago
    > In Go I can only write libraries for Go programs. That's not true. It's quite simple to create a loadable shared object in go and call it using anything with a c ffi.
    • TheDong 10y ago
      It's not quite simple because of the GC go brings. As proof, notice that it barely happens, and only as an oddity in Go, yet in rust there are actual uses (e.g. ruby and python library optimization)
    • lobster_johnson 10y ago
      Calling C from Go has significant overhead [1], doesn't that mean calling Go from C is equally slow? [1] https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/ https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...
      • hueving 10y ago
        It may be even worse calling Go from C since you are bring the whole Go runtime with GC and all when you call into Go.
  • thegeekpirate 10y ago
    You can do this with Go as well, and have been able to for a while now. http://www.darkcoding.net/software/building-shared-libraries-in-go-part-1/ http://www.darkcoding.net/software/building-shared-libraries... http://blog.ralch.com/tutorial/golang-sharing-libraries/ http://blog.ralch.com/tutorial/golang-sharing-libraries/
• treehau5_ 10y ago
  4th law of HN: Whenever Rust is brought up, Go inevitably follows, and vice versa.
  • saghm 10y ago
    It's kind of a shame, because I don't really feel like the languages are used for similar things in practice, so the constant comparisons don't do either of them justice.
• lobster_johnson 10y ago
  As someone who writes Go full time, once I'm done with my current big Go project I will be taking a break to investigate alternatives. Both Rust and Swift are at the top of my list. Go is good, even great, at many things. But it's a language largely defined by its limitations, usually intentionally. It's an engineering language, not made for big abstractions. For me, the largest frustration is that the language gets in the way, and the pain increases with the scale of the problem. Which is to say: I think Go scales to large projects just fine, but there are problems where you'd like to build big building blocks on top of smaller blocks on top of smaller blocks, and Go doesn't lend itself to certain kinds of big, composable, data-oriented abstractions. It's small building blocks all the way. I've bumped into several very real problems recently where Go's coarse, not-very-data-oriented imperative approach has revealed itself as a liability, and where I found myself fantasizing how I could have done it in just a few elegant lines in Haskell. Sometimes they're about expressing things simply in a composable manner, and sometimes these problems simply manifest themselves in immense blobs of boilerplate/repetition (for example, because you have to implement the same method a few dozen times on different data structures, which in a different language could be solved with a generic implementation), where Go's solution is to either eschew type safety, use slow reflection APIs, or programmatically generate the Go code as part of the build process. Go's is also frustrating in its selective pragmatism. Where Go has chosen to automate and sugarcoat some complicated things (memory management, goroutines), it's stubbornly unpragmatic about other things (error handling, working with polymorphic data, memory safety). Go has been ridiculed for its simplistic error system, but I'm not an extremist here; I'm all for errors being values, and not a fan of exceptions. But if you look at actual Go code, a huge amount of code has to interact with errors. When nearly every function is riddled with "if err != nil", you should know that your language is crying out for just a little syntactic sugar. Or a solid type-system solution for that matter. Enums (Rust-style) and pattern matching wouldn't go against Go's grain at all, but since Go is "done", we're stuck with how it is. I think Go's focus on simplicity is very important (I'm a big fan of the Wirth school of languages), and my worry about Rust and Swift is that they never learned this lesson. To me, both Rust and Swift looked more promising early in the design process than in their current state; Swift looks increasingly like Scala every time I visit it, whereas Rust often feels lost in a sea of punctuation. That said, my annoyance with Go is acute enough that I'm willing to deal with a few downsides if I can get a language that better matches the kinds of projects that I build.
• EugeneOZ 10y ago
  Rust is not more complex, it just takes some more time to get used to.
• estefan 10y ago
  I've literally just started learning Rust after following it for a few years. I wanted a language that was type-safe and produced binaries to simplify deployment. I chose Rust over Go because I wanted a functional language with generics. Go's repetitiveness regarding error handling just put me off. I've tried learning C/C++ at several times but I just don't have the inclination to have to bother about null-terminating strings, etc in 2016. I don't mind spending a little more time getting something to compile if it prevents silly mistakes. Having said all that, it's obviously too early for me to say whether I like Rust. I'm picking it up pretty quickly since I know FP thanks to Scala, but I'll see how much time I spend fighting the borrow checker.
• fleetfox 10y ago
  I'm learning Rust. I considered Go but feature wise compared to Rust it seems really boring and plain. IMHO modern language has to have functional flavor.