23 ms·

Why Go and Not Rust?

• tomashubelbauer 7y ago
  I tend to agree with the message in the article, even as someone who's in the past been a bit overzealous about evangelising Rust. The most striking point to me though was the one about not using tribalistic names like Rustaceans and Gophers. These never sat well with me because they sound silly, but I also see how they could be inadvertently reinforcing silloing across programming languages.
  • seren 7y ago
    I agree and it echoes what Paul Graham said here [0] about ego. If your identity is tied to being a 'Xer' you are going to have a hard time working with 'Y' even if it is the best solution in this case. Don't identify as a Xer or Yer, but as someone solving problems and creating value. [0] http://www.paulgraham.com/identity.html http://www.paulgraham.com/identity.html
• sudeepj 7y ago
  Go is simple & simplicity scales when it comes to development (learnability, dev-effort, tooling, etc). So from a manager's point-of-view he/she can hire/train people far more quickly with Go than Rust. As much as I love Rust and have advocated for it in my company I cannot argue on this point with my management.
• srbby 7y ago
  What the fuck is wrong with the Internet? https://i.imgur.com/nv7wTet.png https://i.imgur.com/nv7wTet.png
  • ciaran-ifelse 7y ago
    Looks like the site is made with gatsby. PWA install comes as standard.
    • kristoff_it 7y ago
      Yep!
  • kristoff_it 7y ago
    (author here) Uhh, I've just setup the normal progressive webapp manifest, it's not supposed to be asking you actively about it. I'd recommend checking out the settings in your browser.
    • srbby 7y ago
      It's not asking me actively, but it's just crazy that I'm offered to install a random blog as an app.
    • tambourine_man 7y ago
      Though impolitely made, I think he has a point. Why does a blog need to be a progressive webapp? Why would one want to “install” it?
• gameswithgo 7y ago
  From the article: "Go is faster than Java / C#" The is more often untrue, than it is true. There are times when the low latency GC is beneficial though.
  • electrograv 7y ago
    That’s right, and this is confirmed by many benchmarks I’ve seen. I agree with pretty much everything in this article except the repeated claim that “Go is fast”. Of course “fast” is relative, but I would reserve it for languages that are nearly as fast as competitors in their segment. There are too many languages very similar to Go’s ergonomics that are much faster for us to meaningfully call Go “fast”. That said, I don’t really think that’s a problem. I think people who use Go are often just happy it’s faster than Python, and that’s okay. My personal dislike of Go comes simply from their unapologetic[1] embrace of default nullable pointers (the “billion dollar mistake”[2]): There is very strong theoretical (and practical) ground supporting the approach of Rust/Zig/Swift/etc’s (to use algebraic data types instead) as objectively better (yielding inherently more reliable results with virtually no ergonomic compromise[3]). In other words, in the 21st century, we know how to design statically typed languages that guarantee the impossibility of null dereference exceptions (not counting bugs in external libraries from other languages). And we can do this without any runtime performance or code ergonomics compromise! Therefore there are no good excuses anymore for any statically typed language in the 21st century to not provide this extremely beneficial guarantee. [1] There are no plans to fix this, ever: I’ve seen entire articles written by members of the Go team not just defending “all pointers are nillable”, but encouraging this as an idiomatic Go style of coding. [2] https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill... [3] The ergonomic difficulties of Rust come from the borrow checker, not from their use of algebraic data types to replace nullable pointers.
    • kristoff_it 7y ago
      I replied to the parent comment on my experience, but I do agree that Java and C# can be very fast. I also agree on the problem with null pointers with is really ridiculous. Another complaint that I have about Go is how for some reason Google decided to implement many web protocols in the standard library, but never really cared to get websockets right, to the point that they just sedn you to a third-party library from their own documentation. That + QUIC/HTTP3 make me want to take my tinfoil hat out from the drawer. https://godoc.org/golang.org/x/net/websocket https://godoc.org/golang.org/x/net/websocket
• ancarda 7y ago
  Because the Go standard library is nice - net/http is a joy to use
• akavi 7y ago
  Tangentially, what language right now most closely hits the mark of Rust + GC? I'm thinking Algol based syntax, expressive type system (sum types/generics/structurally typed structs), and optional mutability like Rust, but without the mental overhead of memory management.
  • skocznymroczny 7y ago
    I'd say D, but it has optional immutability. It feels like C++ with GC more than Rust.
  • bluejekyll 7y ago
    You might want to look at Kotlin, though the mutability options aren’t as good as Rust’s.
    • asdf21 7y ago
      Can you describe (or link) a scenario where more advanced mutability options would be preferred / better practice?
      • bluejekyll 7y ago
        This article looks pretty good: https://blog.stylingandroid.com/kotlin-mutability/ https://blog.stylingandroid.com/kotlin-mutability/ I would describe the difference between Rust and Kotlin as: Rust offers control over interior mutability and guarantees that there is only ever one mutable reference at a time—Kotlin offers exterior mutability control, not all that dissimilar from final in Java or const in C/C++, but it is better.
  • stefano 7y ago
    Swift. Automatic reference counting still requires more developer attention (to break reference cycles) than a GC, but is still easy to get right. Too bad that outside of iOS development it's still unusable.
    • 7y ago
• notus 7y ago
  I think they have different applications. If I were to choose a language for writing a web service I'd use Go but if I wanted to write an opengl renderer I'd use Rust.
  • CalChris 7y ago
    Memory safety is Rust's hallmark. Is memory safety such a concern with opengl renderers?
    • Liquid_Fire 7y ago
      Rust is more than just memory safety. For example, it also enables safe concurrency, which sounds like something you would want in a renderer.
      • falcolas 7y ago
        > it also enables safe concurrency Small correction, Rust provides a barrier against data access race conditions. It does not prevent deadlocks, cache hits/misses, work distribution bottlenecks, or any number of other concurrency issues.
    • jerf 7y ago
      Graphics code has a long history of memory unsafety, in more recent years causing serious security issues when we tried to put OpenGL on the web with WebGL, resulting in every device driver bug turning into a kernel-level vulnerability in the JS code. You've got a lot of people writing code with more brains than discipline [1], writing in an environment where performance is priorities one, two, and three, writing in memory unsafe languages... yeah, memory unsafety in rendering code been a big problem for a long time. [1]: One of the most dangerous types of coder there is is the brilliant one, who has several times the working memory capacity of a normal person, and who can write 1000-line "functions" without breaking a sweat, and builds entire codebases out of such things. (Sometimes, perhaps the core loop of a program will be a bit of a monster, but the whole program isn't like that.) The cost of salvaging such things can be disturbingly close to the cost of rewriting such things, and indeed, the process for either may not be all that different.
• surfsvammel 7y ago
  I’ve written a bit of Go and am learning Rust. In my toolbox I believe there will be a place for both.
• krn 7y ago
  I would choose Go to solve network I/O bound problems, Rust to solve CPU / memory bound problems, and Clojure to solve business bound problems: where mental cycles are more expensive than computational cycles.
• epx 7y ago
  Rust is lower-level, it is a replacement for C and C++. I'd love to work with Rust but there are only so much low-level projects where it makes sense - kernels, Web engines, things like HTTP servers. Go covers those cases where you would like to use Python but it would be too slow.
  • k__ 7y ago
    Would be cool if Rust could cover that gap.
    • AstralStorm 7y ago
      It's close enough with its syntactic sugar and type system. There's no gap at all, really. One place where Java and C# win, and sometimes C++, is the availability of excellent libraries. Rust doesn't have as many and not as fleshed out either. Go has the same problem though.
      • asdkhadsj 7y ago
        Agreed, I write everything in Rust these days. I usually dogfood areas where normally I would recommend Go but I'm curious on what the end product will end like in Rust. So far, all the projects have been super easy and only as complex as I want them; with one exception: Diesel. If a developer came to me and wanted to write something in Rust over Go, but didn't know Rust well and wanted to use Diesel, I'd warn them not to. The errors you can get from Diesel are insanely unhelpful and quite advanced in the type system. With that said, I don't think Go really has a comparison to Diesel either.. so perhaps this is an unfair warning. If instead you use raw SQL with Diesel, suddenly it becomes just as friendly as Go's SQLX, and yet again Rust becomes largely as simple as Go. Rust is in my view surprisingly simple. If you choose advanced features you usually understand them. It seems to me that using libraries are the biggest threat to making Rust feel insanely complex; ie Diesel's type system. As an aside, I hope one day Diesel can achieve errors akin to TQL (which I found recently), as TQL really nails the error reporting from what I've seen, at least.
        • 7y ago
• darklion 7y ago
  > Go is a better Java / C#, while Rust is not. Mm, not really. Go is a less sophisticated Java / C#, in the same way that a bicycle is a less sophisticated motorcycle. There's situations to use both, and there's nothing with either, but sometimes you want or need to travel hundreds of kilometers in a day and a bicycle isn't going to cut that for most people.
  • mirceal 7y ago
    but but... anybody can ride a bike and you don’t need to pay for gas. and it’s better for the environment. think about the new people joining the team.
  • DocSavage 7y ago
    I hate bad analogies that have us arguing more about how well the analogy fits than simply debating the underlying question. When we talk about concurrency or the ability to make simple yet high-performing server apps, it's ridiculous to say Go is a bicycle compared to the motorcycle that is Java / C#. User-space network driver? The benchmarks group Go closer to Rust with Java / C# way behind: https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages This would be a very complex comparison and simple analogies do us a disservice. I think the author's blanket statement that Go is faster than Java / C# also seems too broad.
    • loonyphoenix 7y ago
      How do you get that C# is way behind Go on this one? If anything, those benchmarks show these groups of languages performing at roughly the same level: 1. C/Rust 2. Go/C# 3. Java/OCaml/Haskell 4. JavaScript/Swift 5. Python
      • DocSavage 7y ago
        I agree that my wording is too strong due to my memory of the latency results. As you increase the load, Go is closer to Rust/C than C# (see last benchmarks) and at a given load, C# isn’t in picture. It’s fair to say that Go/C# is similar while Java is far behind depending on the benchmarks that are important to you.
• kumarvvr 7y ago
  I always thought rust was for system level stuff, like writing a database engine and go was for more backend server jobs, like distributed processing,etc.
• semitext 7y ago
  While I don’t think it should be the only consideration when deciding on a language to use, I think there is something to the idea that you should use a language that makes you happy. I know a lot of people that use Go that really like using it.
• vips7L 7y ago
  > Go is a better Java / C# Arguable. Both Java and C# perform extremely well, have good ecosystems, generics, and great concurrency.
• cletus 7y ago
  For the record, I like Go. I also like Rust. But I really see them as being aimed at different markets. Go is a better Python/Java. Rust is a better C/C++. The interesting thing about Go is Rob Pike envisioned it as a systems programming language but any language with GC is a complete nonstarter as a systems programming language. So as for the author's pretext (writing some tool in Go), personally my view is "why not?" not "why not Rust?". If someone had written that same tool in Rust I wouldn't be saying "why not Go?". Whatever floats your boat. But here is the one part where I disagree with the author: > Go is unapologetically simple It is not as simple as it seems, just like every GC language out there. I find Go advocates in particular seem to dismissive of any GC complexities or downsides. Maybe because many of them just don't have the background in dealing with this from years of Java. I worked on a team at Google that wrote and maintained a project using Go. Note that I never wrote anything for this project so my experience was second hand but close second hand. One thing I remember was the Go binary blowing up on memory limits (10GB+) in production. Some debugging found there to be millions of Go channels (IIRC) that needed to be cleaned up. For whatever reason the GC didn't clean them up, possibly because of a non-obvious dangling reference, possibly not. Anything can have bugs obviously. It's just a myth that GC is a silver bullet is my point. There was a guy who worked on the Go team (David Crawshaw) who'd stop by every now and again. Occasionally I'd get into debates with him about Go and GC. It's from these that I established my general observations of Go pundits: 1. Full GC pauses and GC in general are totally not a problem in Go. 2. If they were, they're totally going to be fixed in Go 1.N+1 where N = the current version of Go. (At the time, the argument David made was that Go's STW GC pauses were sub-millisecond so totally not a problem).
  • AstralStorm 7y ago
    And in the meantime Java gets its GC finally fixed to not stall. Yes, it's a real problem, ignoring it for many years costed some people lots of productivity.
  • sacado2 7y ago
    > The interesting thing about Go is Rob Pike envisioned it as a systems programming language but any language with GC is a complete nonstarter as a systems programming language. AFAIK, by "systems programming" he meant "non-user-facing programming", not "kernel or embedded programming". So, basically, servers, batch programs and other os utilities.
• kitd 7y ago
  I've moved from Java to Go and I appreciate it very much. It's very practical for day-to-day development. The 2 killer features for me are: 1. the built-in tooling (cross-platform building, profiling, formatting, test coverage, etc) 2. the standard library. I've written services that have convoluted TLS certificate handling, encryption and REST calls and never had to look elsewhere. The language itself is good, though 2 gripes for me: 1. x.Y. At first glance, it isn't obvious whether this is function Y in package x, or method Y on object x. Package::function would be better IMHO. 2. The ':=' assignment with inference operator has sometimes led to unintended variable shadowing. edit: another one comes to mind. The usual ... generics, pretty pls? BTW, the author claims Go is faster than Java. Is this true, because it didn't used to be?
  • LandR 7y ago
    > BTW, the author claims Go is faster than Java. Is this true, because it didn't used to be? I think for certain use cases C# or Java will be faster. THere was a post here the other day about a network driver written in C, Rust, C#, Go, Java and a few others and The C# one was faster then Go. Can't remember if Java was faster or not.
    • coder543 7y ago
      > The C# one was faster then Go As pointed out over here (https://news.ycombinator.com/item?id=20984503 https://news.ycombinator.com/item?id=20984503), Compared to C#, Go was faster (higher throughput) for smaller batch sizes, and it always had significantly lower latency. .NET Core is particularly good these days, so I'm sure there are times when C# is definitely faster than Go, but the network driver isn't a great example to support that.
      • joelfolksy 7y ago
        Are we looking at the same charts? Go and C# are practically on top of each other for smaller batch sizes, then C# pulls ahead significantly.
        • 7y ago
• pornel 7y ago
  Not disagreeing with the sentiment, but I dislike the word "simple" used to describe languages, because it has two meanings: simple = "consists of few parts" and simple = "easy to use", and these are not the same. Certain things in Go are not easy (not simple), because Go has few language features (is simple). Go has definitely a lower barrier to entry and is very productive for certain size and complexity of a project. However, as you start pushing beyond "scale" Go is designed for, Go becomes less simple to use. To appreciate things like generics, non-nullable types, no shared mutable state, you have to be working on a problem that requires these things, and only then these extra features pay off and make development and maintenance easier.
  • walkingolof 7y ago
    >However, as you start pushing beyond "scale" Go is designed for, Go becomes less simple to use. I wonder if that is really true, some really complex systems are written in Go and it does seem to scale well with that. Take Kubernetes for example.
    • asdkhadsj 7y ago
      I view it as a problem of scaling comprehension. Not scaling of performance.
    • hauleth 7y ago
      Yes this is still true[1] [1]: https://www.youtube.com/watch?v=4VNDjwzzKPo https://www.youtube.com/watch?v=4VNDjwzzKPo
  • asdkhadsj 7y ago
    > Certain things in Go are not easy (not simple), because Go has few language features (is simple). Too true, I touch on that in a post I made here as well. In Go I often found myself having to reuse logic in functions that, in Rust, could be hidden behind iterators or custom iterator implementations. While the Rust version is definitely more complex if you look at the implementation of the iterator; in practice you are just using the iterator - and that ends up meaning the problem you're solving keeps locality, and is easier to reason about. In my experience, at least.
• leshow 7y ago
  > Go is faster than Java / C#, more memory-efficient than Java / C#, and definitely has better concurrency than Java / C# C# is a great language and has a ton of modern features. It's also quite a bit faster than the author is giving it credit for. In fact there was a network stack written in it that was posted here last week that had it beating Go by an order of magnitude. I don't really agree with the statement that 'Rust is a better C++' either. It very much can take the place of C in many applications also.
  • patrec 7y ago
    What features does Rust have that C++ lacks that allows it to be used as a C replacement when C++ can't be?
    • w56rjrtyu6ru 7y ago
      Compile-time memory safety by default.
    • pdpi 7y ago
      Arguably, the point is precisely that Rust lacks features that C++ has which make C++ not as good as it could be at replacing C.
    • nine_k 7y ago
      (1) Memory safety guarantees through the ownership model, a clear delineation of unsafe code that doesn't follow it. Also, no UD. (2) Both Rust and C++ can be used to write most / all of the code that can be written in C, at a zero runtime cost. Their difference is in ergonomics, safety features, ecosystem maturity, etc.
    • eximius 7y ago
      Memory safety? C++ has lots of bells and whistles, some of which Rust doesn't have (classes, to name one), but those aren't necessarily more important bells and whistles. Also, the Rust infrastructure is light-years ahead of linking in libraries in C/C++. Compile times are higher, but not horribly so.
• w8rbt 7y ago
  I like to think that Go is C for the Cloud. And don't let detractors get you down. No matter what you do, or how successful you are, there will always be critics. Ignore them.
• JulianMorrison 7y ago
  Go's hidden feature is that there are no personal dialects of Go, not even in the whitespace, because everyone uses "go fmt". As such, you look at it, you see what it's doing, not how clever the programmer was. And you can feel free to dive in and edit.
  • skohan 7y ago
    I haven't written a ton of go, but my read on the language is that it's built for large teams with lots of turnover. It makes it really easy to write boring, readable code and it makes it really hard to write code which is too clever by half. If I am choosing a language for a personal project, or for a small team of developers I'm really confident in, I'm probably going to choose something which is more fun to write. But if I had to recommend a tool for a large shop where long-term maintainability regardless of the team makeup is more important than programmer happiness, Go seems like a great option.
    • JulianMorrison 7y ago
      And yet Go programmers are often happy. I think the reason is: Go code has a low level of abstraction-construction and a high level of explicitly writing the algorithm. You can see through the language, which is "boring" and does not distract your attention, to what it is trying to achieve, which is interesting.
      • skohan 7y ago
        I can totally understand the appeal of Go, and I can understand why a lot of people probably really like working in it. I also really prefer boring code so that's not a knock! It's just that in some cases I do like to work with a bit more expressive and low-level tools than Go has on offer, so it's not my first choice. But that's 100% personal preference.
      • ummonk 7y ago
        Yes, I agree with this, but need to caveat it. Go is a fun language to write code in (it has the simplicity and directness of C, which is also a fun language to write code in, while avoiding the warts of C). Like C, it isn’t a fun language to rapidly develop features in, because it is very boilerplatey due to limited abstraction. Incidentally, for this reason I’ve always enjoyed coding in C because in domains where I’ve used it (most embedded code) the required feature set is quite limited, so C’s slow pace of development isn’t a problem. On the other hand when working with Go server code at a startup, I was deeply frustrated because I just wanted a much more abstract language to rapidly write features in.
• asdkhadsj 7y ago
  As a now Rust lover and prior (6 years?) Go lover, this article hits home. We have a lot of tech debt in my shop (who doesn't lol), and generally I advocate Rust or Go. I usually start the conversation with: Would this be a program you'd write in C++ or in Python? And then I advocate Rust or Go, with one amendment; data structures, and frequency of conversion/etc. Having converted some large Go programs to Rust recently I now have the perspective that some programs, while perfectly fit for Go, are miserable to write without Generics. I had a program which did some pretty minor work, but it did so with a lot of varying data structures and writing it in Go was less than pleasant. No, Go might handle this better with generics. However I imagine this will only move the bar. Certain problems are just going to be friendlier (though, more complex!) to solve with a more advanced typing system. I do look forward to the day that Go can get basic iterator behavior via Generics (if ever). Some of the smallest things in Rust were the biggest sighs of relief for me. Converting a slice of slices from one type to another is just a PITA in Go (in my opinion), and iterators make a world of difference for short, easy to read and comprehend implementations. In my experience, Go's biggest fault is code bloat that "simplicity" offers. A simple goal could turn into a multi function implementation in Go that frankly shouldn't have to be. Then code locality gets worse over time, and suddenly simple doesn't feel simple. Rust's larger complexity (iterators and the like) improve code locality, and thusly simplicity, in my experience. It's a game of tradeoffs. They're both great languages, and they both have their places in my company.
  • crimsonalucard 7y ago
    You only mentioned one tradeoff for Rust and that is the complexity of the overall language. I would say that the complexity of the overall language is a one time hurdle. Once you get past that and once Rust has more mature libraries. Which language in your opinion is the better one?
  • ShinTakuya 7y ago
    I'm a Rust evangelist too but I think it's going a bit too far to blanket recommend Rust and Go over C++ and Python. Python in particular is still an excellent language and there are many situations where it makes perfect sense to continue using it. I can see a future where Rust and Go overshadow Python but that future isn't near. Python still has superior libraries for many use cases, a great community, easy to learn syntax, and little training requirement (most people know it or can become proficient in a very short time). Moreover with the type annotations and linting tools it's becoming a lot easier to write a large and maintainable Python codebase.
• yitchelle 7y ago
  "Well, you could answer that Go is what you know, so that’s what you used to solve your problem," This is definitely an appropriate answer for the author to give. He wrote a small tool, and most folks writing a small tool would just run with what is already know by coder.
  • tom_mellior 7y ago
    Yeah. The whole premise of the article is "if someone trolls you, feed the troll".
• cpursley 7y ago
  It seems like Elixir is a better fit than Go for all of the benefits listed here, especially in the age of distributed systems. https://blog.codeship.com/comparing-elixir-go/ https://blog.codeship.com/comparing-elixir-go/
  • interfixus 7y ago
    Your linked article states quite clearly that Elixir does not cross compile, and is best deployed via some deployment tool, seeing as it doesn't produce easily managed, static, standalone executables like Go does. So it seems like Elixir isn't.
    • floatboth 7y ago
      OTP release tarballs aren't much harder to deploy than static binaries :) Elixir doesn't need to "cross compile" because its only compile target is BEAM. That's like saying "Java doesn't cross-compile".
    • traderjane 7y ago
      But how something is deployed is often not the job of the code author, as deployment has become its own technical craft. The argument should largely go to whether a tool can fit the domain given typical resource constraints (team size), not whether you get a static binary.
• lidHanteyk 7y ago
  I will remember these talking points when talking to Rust prophets. That said, although Rust is a mediocre language at best, Go is truly quite poor. Neither of them are good languages, and Go will stay that way; only Rust can be good in the future.
• phlakaton 7y ago
  I tell folks that working in Go is like coming full-circle to C again. It is the easiness of Go, the general presentation of good ole shoot-yourself-in-the-foot pointers, and even the presence of interface{} as an analog of void*, that causes the link in my mind. As many of you know, the Go community has been having a knock-down drag-out argument over whether/how generics should be added to the language. I joked a bit about this, but I am serious in my contention that much of the value proposition I see of Go over Java would be wiped away if a feature that complex gets bolted onto it.
  • deleted 7y ago
    [deleted]
  • jerf 7y ago
    "the general presentation of good ole shoot-yourself-in-the-foot pointers... presence of interface{} as an analog of void*" Go doesn't have "shoot yourself in the foot" pointers. For that, you need pointer arithmetic, and Go doesn't have that. (Outside of the "unsafe" library.) interface{} may be an analog of void∗, but it lacks the failure in C where casting something to void∗ loses all type information; in Go, if you put an "string" into an interface{}, the runtime still knows it's a "string" and you can't put it into any sort of strongly typed variable except a string. The runtime/virtual machine Go implements knows the types of all values at all times. I really wish the Go designers had called their pointers "references". Considered across the entire landscape of what various programming languages call "pointers" and "references", there's substantial overlap but I think Go's pointers are closer to the center of the "references" cluster than the "pointers" one.
    • phlakaton 7y ago
      Not shootable in the foot in terms of pointer arithmetic, but shootable in the foot in terms of unchecked dereferences of nil. As a C++ programmer historically, I think of references as not being nilable.
      • Gibbon1 7y ago
        AKA has 'pointers' but not in a way that adds value.
• deleted 7y ago
  [deleted]
• hyperpape 7y ago
  A minor nit about this article: > Go has great concurrency support, but Rust has provably-correct concurrency. I believe it's incorrect to say Rust has provably-correct concurrency. It prevents data-races, but not race conditions: https://doc.rust-lang.org/nomicon/races.html https://doc.rust-lang.org/nomicon/races.html.
• hydandata 7y ago
  I love Common Lisp, which is definitely on the other end of the spectrum, but still enjoy Go a lot too. For me it is a perfect fit for writing automation, services and command line tools. It is stable, it is simple to use/write/read, it is easy to deploy, it has great IDE support and tooling, it just makes sense in the enterprise, as author himself notes. I like Rust too, but compared to Go it has the feel of a research project. I think Rust has great future, I definitely see using it, but for now I will stick with CL/TS/Go.
  • tombert 7y ago
    Out of curiosity, do you use Common Lisp for work or just for fun? I get to do Clojure about half-time (it was an easy sell due to a lot of our stack being Java), and really like it, but haven't used Common Lisp at all. If you do get to use it for work, how does it scale (programmer/code-wise, not efficiency-wise) for "real" projects?
    • hydandata 7y ago
      I used it at work[0] for a few years and it was great, but I did not scale that project to large number of people, mainly because it did not need to. Folks at Grammarly have a writeup about how they are using it, it might have more relevant information for you[1]. I would definitely consider using it again, but proper buy-in takes time, and I have simply been moving too fast since then. I am still not a big fan of Clojure myself, but it is definitely seems easier to sell than CL. In my humble opinion, if you are already a convert the benefits of going from Clojure to CL will not be as great as the ones for going from Java to Clojure. [0] https://news.ycombinator.com/item?id=13979002 https://news.ycombinator.com/item?id=13979002 [1] http://tech.grammarly.com/blog/posts/Running-Lisp-in-Production.html http://tech.grammarly.com/blog/posts/Running-Lisp-in-Product...
      • tombert 7y ago
        I actually went Haskell->F#->Clojure in terms of job progression, so I am ok with largely theoretical stuff. The reason I ask is that Clojure is an easy-ish sell largely because there's a near guarantee that you will never be blocked due to lack of libraries, since you can mooch off of anything in the Java ecosystem (similar arguments can be made for F#). I hate Java, but it has been around a long time and is extremely popular, and as a result there is a library for virtually anything for it. As far as I know, there is no such guarantee for CL...unless I'm mistaken (which wouldn't surprise me). When using it for work, did you ever get stuck because of a lack of libraries (e.g. JSON parsing, protobufs, socketing stuff, threadsafe collections)?
• qaq 7y ago
  Try creating a type in Go to represent arbitrary JSON.
  • sacado2 7y ago
    interface{}
    • qaq 7y ago
      very safe option
      • kristoff_it 7y ago
        you mean the interface{} or the json? :)
      • dullgiulio 7y ago
        It's 100% memory safe. In other languages you would use the same (some variation of Object.)
      • sacado2 7y ago
        There is no safer option anyway if you can be given an arbitrary JSON object in the first place.
• rustezen 7y ago
  The junior programmer one day asked the senior team lead sitting next: - What sound does a Go program make? The senior looked on for a second, then smacked the junior over the head with the keyboard. The junior was instantly enlightened and from that day on only programmed in Rust.
  • jerf 7y ago
    That's... not how those work.
    • AnimalMuppet 7y ago
      User name checks out... his Zen is rusty. Sorry, I'll show myself out...
  • almost_usual 7y ago
    You needed to create a new account to make this comment?
• illuminati1911 7y ago
  ”While the story above is 100% the result of my imagination, it’s no secret that the Rust fandom has a few overexcited members who feel compelled to enlighten every lost soul about the virtues of the Crab-God.” Just like any programming language and probably most of all Go. The fanaticism around it is just next level.
  • twic 7y ago
    It's incredible how Rust stans get so much stick, when there is if anything more blind fanboyism around Go.
    • woadwarrior01 7y ago
      Indeed. This is from a comment on this thread: And yet Go programmers are often happy. If the programming language you use is your primary source of happiness, you might want to reflect a bit on what happiness means to you. :)
      • themacguffinman 7y ago
        This is pointlessly dismissive. Is it somehow weird to think that a language you use and think about 8 hours a day, 5 days a week will significantly affect your general happiness? "yet Go programmers are often happy" is a vague and slippery argument for sure, but somehow this response is even worse in how pretentious it is.
  • blub 7y ago
    I can't think of any other programming language discussed on HN besides Rust where hordes of people will doggedly praise it and nitpick any criticism of it to death. Maybe Haskell, although even that doesn't compare. Every mention of Rust on HN feels like a public relations exercise where one is force fed an opinion until they learn to like it. The Go community's actually quite relaxed, all things considered, which makes them look more self-confident and less desperate.
    • 7y ago
• jonathanstrange 7y ago
  I agree with the author that some Rust zealots are overdoing it and don't do their community a huge favour, they were one among several reasons why I chose Go instead of Rust for a larger project I'm working on. It's especially annoying to talk to the fanatics when you know Ada fairly well. (Most of them seem to come primarily from C++...?) Like the article suggests and was stated numerous times, Rust and Go are not competing languages, they have different use cases. Rust is a good choice if you want to write a rock solid and secure library to replace a C++ library, or instead of writing it in C++ in first place. Go is a good language if you want to write a web service and want to rely on many existing libraries to cut down development time. Both are great languages if you know them intimately as an expert and are deeply familiar with the common frameworks. Almost every language is great in that case. However, for my use cases Rust would be a bad choice. Relying on GC is not only perfectly fine for my performance requirements, it also makes life much easier. Personally, I think that both Rust and Go are a step back when we're talking about pure language features. They are both needlessly and artificially restrictive in comparison to good old languages like Ada and CL. But in the end, the frameworks and 3rd party libraries are more important anyway.
• perspective1 7y ago
  Love these points. They answer "which language is better for building enterprise services in the vast majority of cases." Go, is simply good enough and makes well-thought out compromises for "non"-zero cost abstractions. For me, I'm a part-time solo "services" developer using Rust. I've built some terrible projects that I hate peeking into to add features and maintain. But, ultimately that's gotten better and the web-services story is maturing (Actix is somewhat unstable but easy to work with, and async/await will finally hit stable in a few months). I also write non-idiomatic code quasi-functional code that works for me but others would scoff at or at least find hard to maintain. Rust, to me, is an enjoyable language to use and has great tooling (debugging being a major exception). I've become productive in it after a heavy upfront cost. And, although I haven't quantified this exactly, its speed saves me money considering my relatively small single server. I think, as a sole-developer, the largest issue with using Rust for services is the package support. Python, Go and JS all have mature Redis packages, for instance. Rust's works, but it has some peculiarities particularly with connection management and some Redis commands. It's enough where I could get everything working with enough time. But I don't have all the time in the world. It's a similar story for lots of packages, even in Actix web. You often have to dig into the source code to figure things out. I'm trialing a "microservice"-like architecture solely because it's easier to do some things in other languages. Hopefully widespread WASM support hits soon but I'm a long-time single-server guy now trying to figure out Kubernetes because I find Rust enjoyable.
  • kristoff_it 7y ago
    Well maybe the Redis packages problem can be solved, I started working on one for Zig [1], maybe I'll bite the bullet in the future and contribute to redis-rs too :) [1] https://github.com/kristoff-it/zig-heyredis https://github.com/kristoff-it/zig-heyredis (far from complete)
• tombert 7y ago
  > There are only two levels of visibility for variables, and the only concurrency model is CSP. I think this is generally true, but in the interest of pedantry, I feel like I have to point out that Go does have "traditional" locks and mutexes and whatnot, if you're feeling masochistic and don't want to use channels for some reason [0]. [0] : https://gobyexample.com/mutexes https://gobyexample.com/mutexes
• IMTDb 7y ago
  > Well, you could answer that Go is what you know, so that’s what you used to solve your problem, but that’s probably not going to be a satisfactory answer. It should be
  • AdamJacobMuller 7y ago
    It is, for sure. As long as the tool gets the job done, I don't see the issue. That's not to say some tools aren't better suited to a task than others, or that there isn't room for improvement, but, unless things are manifestly mismatched I don't see why it wouldn't be a satisfactory answer, especially for a "hey i wrote this cool thing" project.
• chooseaname 7y ago
  The problem, for me, with Rust is a lot of people who evangelize it seem to think there should only be one programming language. It's kind of a put-off.
  • kristoff_it 7y ago
    I would recommend not factoring that into your decisions. Yes it's off-putting, but the technical merits of the language are truly there.
• davesque 7y ago
  Honestly I'm a bit confused why these languages are constantly pitted against each other as though one has to eventually win out. They were each designed with different goals in mind and suit different tasks.
• Communitivity 7y ago
  I have written a command-line log processor in Rust, an XML processor in Go, and some small microservices in both. My experience in working with both languages is that Rust has a steeper learning curve than Go, and it took me longer to feel proficient in Rust. However, once I felt proficient in both I felt much more productive in Rust. It's my impression that you may need to have worked with functional languages and have an understanding of type systems before you can be efficiently productive in Rust, but for those who reach that I think they can be much more productive in Rust than Go,based on only my personal experience. One of Rust's biggest and best features, and its biggest barrier to grokability, is the Rust Borrow Checker. I think Go is a very good language, has awesome concurrency designs (I love Go channels), and is more accessible to more developers, but it also doesn't seem as flexible. I think the OP hit the nail on the head with the idea that Go is designed for Enterprise, where a sea or journeyman engineers are working under a small number of senior eningeers. I think Rust OTOH is designed for senior engineers, but is usable by less experienced engineers if they are mentored properly, i.e. 1:1 or at most 1:3. Also, I like the tooling better in Rust than Go. Rust tools are easier for me to install, and the cargo build tool is not part of the language, but there is a standard build tool, so I get to have my cake and eat it too. Meaning I can customized the build tool to my needs, and have different customizations for different projects. That can get out of hand, which is why so many hated Gradle. OTOH, the level of customization is why many shops with senior engineers loved Gradle (e.g., Netflix). Examples of build tool install: * Go: $GO111MODULE=on go get golang.org/x/tools/cmd/stress * Rust: $cargo install cargo-stress One thing I think both languages will need to watch out for is the P3 problem (Package Proliferation Pachyderm), where there becomes an ocean of packages, some too trivial to really be an effective package (e.g., a package with a single functor to add two numbers). I've seen this with Node.js, though the community has noticed it and is working to rectify the situation. This, like so many problems with language adoption and evolution, is a policy/community problem and not a technical problem. Both Go and Rust have great communities, so hopefully we can avoid P3 in the future.
  • agumonkey 7y ago
    I have zero field experience regarding go, but it seems to me that it's made to remove friction for teams. Lean toolchain, lean build times, lean formatting (can you imagine the amount of time wasted on IDE config, commit syntax, and formatting style debates ?) so that large groups can just go to work. ps: I'd love to work in rust. As you said, it seems very potent at making very expressive yet very efficient code.
• Yoric 7y ago
  As a devoted and long-time Rust user, I'll tell you: by all means, use the language in which you're most comfortable and/or which seems best suited for the task! Rust is not meant to replace every single language on Earth. Rust is, as you mention, a better C++, with great predictability, great safety and great concurrency. That's a feature set that's critical for some classes of applications, but absolutely secondary for others. It's a good thing we have more than one language to pick from :)
• trpc 7y ago
  I've read this article and I am yet to conclude why Go and not Rust. All your talk is very generic and no proof or concrete argument to support article title.
• pictur 7y ago
  Fanaticism in programming languages sometimes sounds very funny
• dochtman 7y ago
  I have little doubt that Go is easier to get started with than Rust. However, I'm very skeptical that Go "scales" better on any other axis than onboarding new people quickly. Also not convinced the Go toolchain is better than Rust (other than in terms of compile time). Especially for "big scope", I place a lot of value on leveraging Rust's more extensive type system and abstractions to model the "complex domains". I would also bet that services written in Rust would be more robust than those initially written in Go. Initially standing it up is, in the end, such a small part of your long-term productivity, and Rust really shines in all the other parts. Seems to me that Go is more compelling than Rust for enterprise software development because many businesses do a bad job of looking at their development costs over a longer time frame, thus valuing short learning curve over high reliability. So really, it seems like the author does not have a profound familiarity with Rust. Which is fine, but not a great basis for confidently expressing semi-universal truths on your blog.
  • kjksf 7y ago
    I'm an open-source, solo dev. Not an enterprise dev. I use Go for most of my projects. For me, the biggest hit to productivity are long compile times. One of my projects is ~80k loc C++ app (SumatraPDF) and I pretty much abandoned working on it because the long compilation times are killing me. Go is good in that regard. My medium sized projects compile pretty much instantly. I hear Rust is not doing well there. The second productivity boost is GC (Garbage Collector). I don't want to manually track every allocation (C++) or think about how to contort the code to a form that Rust will be happy about. Long term productivity is very much why I use Go. In addition to GC and fast compile times, there's now a very rich ecosystem of libraries for almost everything you might need. The language has been stable in past 10 years. I don't need to fix the code every major release because language changed (Swift) and I don't need to learn a large number of new things because of significant new addition (Rust). And for what I use it (backend servers, cmd-line apps) Go is more than fast enough (which can't be said about out languages that have similar productivity, like Python, Ruby, Node). If there's a C++ competitor I'll be willing to look at, it'll be JAI (when it's released).
  • kristoff_it 7y ago
    > Also not convinced the Go toolchain is better than Rust (other than in terms of compile time). Never claimed this. I compared the Go toolchain with other toolchains I happened to encounter in enterprise development. > I place a lot of value on leveraging Rust's more extensive type system and abstractions to model the "complex domains". I would also bet that services written in Rust would be more robust than those initially written in Go. In my experience it's not easy to get there in an environment like the one I described in my post, and any non-trivial abstraction carries a relative risk to later become a problem. The problem is that it doesn't matter how "sound" the abstraction is, the product owner will come in and change things in surprising ways. So at that point investing in sophisticated mechanisms becomes a form of premature optimization. That's the reason you can't afford microservices if the business doesn't have a well-defined structure. >Seems to me that Go is more compelling than Rust for enterprise software development because many businesses do a bad job of looking at their development costs over a longer time frame, thus valuing short learning curve over high reliability. For some business, "high reliability" does have less value than a shorter time-to-market, and in enterprise software development providing value to the business is the entirety of your job, not building cool tech. That's why reconciliation procedures exist even now that we have tons of tools to ensure transactional/eventual consistency.
• rcarmo 7y ago
  The "enterprise software" bit is a drum I've been banging on for a bit, and which always gets me into trouble from Java/.NET/OOP advocates who usually sail under the "legacy modernisation" flag when they point out that dependency management in Go is sub-optimal in closed environments. But I think it will get there, eventually.
• Animats 7y ago
  Having used both, I admire Rust as an intellectual exercise, but would write back-end web stuff in Go. Go is an OK language, not a great one. The real advantage is that you have the libraries that Google uses for their own web server side stuff. Those have been pounded on by billions of transactions, and that the special cases have been handled. There's one well-tested library for each major web service related function. Rust's libraries don't have that volume of use behind them. Look up "http" in the Rust libraries. You find "Note that this crate is still early on in its lifecycle so the support libraries that integrate with the http crate are a work in progress!"[1] (Rust enthusiasts may comment with a complicated excuse for why this isn't a problem, if they like. That's what the official document says.) [1] https://docs.rs/http/0.1.18/http/ https://docs.rs/http/0.1.18/http/
  • crimsonalucard 7y ago
    If rust had all the libraries you needed. Would it be a better language than golang?
  • steveklabnik 7y ago
    Your point isn't wrong, but you've linked to a weird package to make it; the http crate is an attempt to standardize some of the types used across multiple implementations. That takes longer than actually building the functionality, as the whole point is that you have multiple implementations, and then consolidate afterwards. It's also not an "official document"; that's just a package that exists. It's not run by the Rust project.
  • nicoburns 7y ago
    Rust isn't there for http services yet (if you're being conservative). Come back this time next year and things will be different though. A nice thing about Rust is that there is so much safety is built into the language that even random libraries tend to work quite reliably.
    • ryacko 7y ago
      I don’t think it is necessary to integrate http as a standard library. CGI allows using common wed servers, and there is a separate set of ecosystems around those servers.
• peterwwillis 7y ago
  Why <trendy language 1> and not <trendy language 2> ? Maybe because trendy languages aren't a panacea.
  • red75prime 7y ago
    Maybe people aren't looking for the panacea, but to ease particular pains.
    • peterwwillis 7y ago
      We all use C instead of assembly because it makes it easier to express the same thing, though we lose some control, and pick up bloat. Each successive language tends to do the same. But once you're comparing languages that are basically at the same level, what are you really gaining by switching? There's always going to be pain. I think we just assume the other pain will be more tolerable.
• deg4uss3r 7y ago
  Contrary to popular belief there is not one ring to rule them all.
• thelazydogsback 7y ago
  I can see moving from C/C++ to Rust for buffer-copying style codes, but for most code general-use programs the cognitive load required to deal with resource management seems way to high to move from from Java/C#/Node to Rust. (I just got called about a shop moving their Node code to Rust, and I can't imagine why any code that would make good Rust code was written in JS in the first place.) Go seems like a non-starter to me -- sure features can be abused (as implementation inheritance has been for years) but to omit generics at this point just seems silly. As for moving from C# to Rust, you can learn to program with the Span<> APIs and get the non-GC perf. of Rust for the most part and still keep GC and other C# niceties (like the whole toolchain and ecosystem...) in much less time than a wholesale move to Rust. As as for message-passing/agent/channel programming, you can certainly do that in C# if you like, and though there is certainly a lot a foot-shooting that can be done with async and thread contexts, in general the Task<> system is a joy to use compare to almost anything else out there, not only for async code, but for concurrent code. Don't get me wrong, I always thought that C++ was a "worst of all worlds" language and appreciate moving to Rust from there, but for most user-facing applications that tend to have complex object lifetimes, I just can't see why you'd want to deal with RIAA when modern GC's are so darn good.
  • munk-a 7y ago
    Ah the Generics, the fact that empty interfaces have been accepted as the way to get things done is absolutely terrifying to me. I understand that C++'s approach to generic type usage has slowly evolved into the most absurd collection of left angle brackets out there but Go seriously needs to shape up about generics, when people are regularly hacking your logic rules and advising others to do the same thing then... maybe there was an error in your rules. Go is interesting and I really wonder how it'd be doing if someone went all in on the multi-return syntax sugar (pretty awesome stuff), the prohibition (mostly) on exceptions, channels and trivial threading and a bunch of other nicely packaged features while giving some ground on Generics. All languages have their warts, but I think this one is particularly easy to address - though it may take a major version bump and introduce some BC breaks I feel like those could be minimized, the biggest cost would be library incompatibility.
    • 7y ago
• bullen 7y ago
  Can you share memory between cores with go without copying the memory?
  • scottlamb 7y ago
    > Can you share memory between cores with go without copying the memory? Yes. Go's "do not communicate by sharing memory; instead, share memory by communicating" thing [1] is advice, not a language requirement. Go's memory model is similar to C's. Channels are completely optional; you can share pointers and protect stuff with mutexes. You can skip the mutexes and have data races, too, unfortunately. At least Go has good tooling for finding these kinds of races dynamically. [2] Rust is similar, except that it prevents data races (as well as other types of memory errors) in safe Rust code, barring compiler bugs. I absolutely love this property, and it can save you from very difficult-to-debug production problems. It has a significant upfront cost in terms of "fighting the borrow checker", adding extra annotations to your code, etc., so it's definitely not worth it for every developer in every situation. [1] https://blog.golang.org/share-memory-by-communicating https://blog.golang.org/share-memory-by-communicating [2] https://blog.golang.org/race-detector https://blog.golang.org/race-detector
• kod 7y ago
  "Rust is a better C++" Rust is very clearly an ML derivative, not (just) a better C++
• _bxg1 7y ago
  I was having a conversation the other day with a principle JavaScript engineer who's been in the industry for 20 years. I asked him, "What's the use-case for Node in industry? It's so much slower than other server platforms, which in the age of the cloud translates directly to real expense. Is it only used by startups who need maximum agility?" His answer was that for larger companies, server costs are orders of magnitude cheaper than payroll. It's often much more valuable for a company to improve their development process than server performance. So high-productivity (and ease of hiring) technologies like Node and Go can end up being a really good business tradeoff in terms of actual dollars, even if they result in double or triple the server costs.
• Spiritus 7y ago
  Maybe just me, but I feel this thread is just validating everything he’s saying. Literally every comment is an explanation/excuse why you should use Rust or why Rust is better at literally everything. Disclaimer: I’ve had a “few” beers so I might talking with my ass, but damn...
  • steeve 7y ago
    Every article about Go you can CTRL-F "rust"
• codeisawesome 7y ago
  I feel this article so hard on so many levels. I've experienced Dante's Enterprise. BUT, regarding what I feel to be a false equivalency - Is Go truly right for the exact kind of Enterprise Mush that the Author is describing? Go was invented at Google to solve Google problems is the claim in TFA. And yet, Google is famous for having a very high bar for engineering hiring with a strong focus on CS prowess. So, is the kind of code mush that gets created at Enterprises who put production code written by one-week-of-pluralsight Junior devs headed by analyst-preached-cargo-culting managers - the same as - the Software produced at Google? If not, does Go still fit that former zeitgeist?
  • kristoff_it 7y ago
    Hello fellow lost soul. I don't ultimately know, I think some enterprises are doomed to fail regardless of the technology they end up choosing. In some ways their inevitable doom is capitalism's greatest gift to society, but I've worked in a shop where we had both Go and C# at the same time, and I would have quit way earlier if I had to work on the C# code full-time. Both green-field projects btw.
• shmerl 7y ago
  To summarize the answer, Go was created as a better replacement for Java and other managed languages. Rust was created as a better replacement for systems programming languages (the author brings this point in the conclusion). This claim however is somewhat misleading: "Rust is a C++, not a C". It's clearly not either of them - it's a new language. However, it's a good replacement for both C and C++. May be the above idea means, that those familiar with C++ concepts can find Rust easier to understand - that's true, it uses major ideas from it like scope based resource management (aka RAII) and so on. But it uses other ideas as well. No language is perfect in absolute sense, and each has its own trade offs. But the above gives a rough framework to answer "why Go and not Rust" or "why Rust and not Go" in some particular situation. There is always going to be some overlap area, where both are adequate enough, so any answer to such questions would be moot there.
  • kristoff_it 7y ago
    This comment on Reddit I think explains why I think there is a big difference between C and C++ and why in my opinion Rust is not the best substitute for the former: https://old.reddit.com/r/programming/comments/d50u9g/why_go_and_not_rust/f0j5na2/ https://old.reddit.com/r/programming/comments/d50u9g/why_go_...
    • shmerl 7y ago
      I agree with the view of "portable assembly", or to say it more correctly, language that allows high level of control. Rust at least aims at that, so it should be a good replacement for C. Some things were still missing though, if I remember correctly something like handling memory allocation errors was an issue, which is important for embedded systems and similar scenarios. I suppose there was some plan to address that.
• johnklos 7y ago
  "Rust has provably-correct concurrency"? Too bad they're so busy being passive-aggressive that they won't fix the build of Rust itself so that it's deterministic.
• acje 7y ago
  I come from a network background where it is common to separate data plane (speed) from control plane (complexity). I think Rust and Go can fill one of these niches each. Because I wanted speed, Rust became my choice. But that zero cost abstraction, does not extend to the programmer. The cost is in the productivity. Although productivity in Rust is likely better than most older languages, C in particular. I also like Starlark, very weak language in terms of features. That is its strength imho. For the sake of context. Rust is my eleventh language, but I haven’t written much software, and most of it was ten years ago.
  • steveklabnik 7y ago
    We've even seen this in shipping products; Linkerd 2 is exactly that: data plane in Rust, control plane in Go.
  • kristoff_it 7y ago
    That's a very good point. There's a comment on Reddit [1] that outlines how this distinction is one way of seeing how Rust and Go embody two ways of understanding "C", I think you both make two excellent points, I'll keep both in mind. [1] https://old.reddit.com/r/programming/comments/d50u9g/why_go_and_not_rust/f0j5na2/ https://old.reddit.com/r/programming/comments/d50u9g/why_go_...
• maxpert 7y ago
  Fortunately I've used Go, Kotlin and C# in production building systems dealing millions of rpm. I can correlate my experience with different parts author has described. But I would disagree with few parts, specially simplicity part. You see the so called "simplicity" comes at a cost of extra verbosity and pain e.g. no generics; I have to add 3 extra lines of code, and repeatedly do casting and `ok` checks to just get value out of an in-memory LRU cache. Now some of folks might argue well this is the right way to do it. IMHO generics is one example of compiler slacking on me, and putting the burden on developer to maintain those extra lines of code. I do agree with C#'s breakable TPL model where you can choke threads; and I think that problem exists due to Tasks being slapped on to legacy down the road. If they were to reinvent another language I bet no-body with sane ideas will ignore the async programming model. Kotlin is one such example. I can keep going on and on, but to cut it short; yes I would write a high performance router, reverse proxy, or a very simple micro-service in Go. But I would never recommend anyone to write a high business complexity service in Go. It's a matter of time before somebody writes a transpiler that would take these short comings of Go, and fixes them (Like Kotlin, Nim etc.).
  • kristoff_it 7y ago
    I'm honestly conflicted about generics. I see your point, and I have felt the need for them in the past. My main concern is that as of now the lacks of generics forces people to rethink a little their approach to development, while with generics I fear there will be a proliferation of not-always-great patterns that will be copypasted from equivalent Java/C# code. The Go community has a lot of good ideas on designing interaction through interfaces that I really hope won't get lost in Go 2. That said, yes, casting interface{} manually over and over is stupid, let's hope we can get the best of both worlds.
• norswap 7y ago
  Why are people upvoting this religious language war drivel? The arguments aren't even good. Heck, they aren't even substantiated, not even badly. I'd like to offer constructive criticism, but really, there is nothing to salvage here. - Go is much easier to learn than Java or C#. - The Go community regards as anti-patterns many abstractions regularly employed by Java / C#. - With Go, it’s easier as a junior developer to be more productive, and harder as a mid-level developer to introduce brittle abstractions that will cause problems down the line. Huge red flags all.
• deleted 7y ago
  [deleted]
• jaichabria 7y ago
  There is a lot of why go in the article, but not much about why not rust. I couldn't tell why the conclusion was that Go is better than Rust at certain things.
  • std_throwaway 7y ago
    "The devils you know vs. the devils you don't." It's been keeping C alive for decades. Now go is an old boy, too. Rust is the new kid that seasoned developers don't trust. It's got not enough features and yet too many already.
• zbraniecki 7y ago
  I'm not discounting your experience, nor am I trying to devaluate the problem, but I think there are more than one reason why someone may ask "Why not Rust?". In my case, I sometimes ask it to learn about particular real or perceived shortcomings of Rust, which may be fixable. If I believe that Rust should address the problem, and someone chose not to use Rust (which is different from choosing to use Go!) I am curious as to what obstacle the person hit. We should tame the zealous members of our community, but don't cluster everyone into the same bucket :) Some of us are just trying to build a great ecosystem and that requires us to find blindspots and notice hard-to-observe-from-inside problems.
  • kristoff_it 7y ago
    > I think there are more than one reason why someone may ask "Why not Rust?" Strongly agree, that's how I concluded the blog post :)
• spion 7y ago
  A good answer is: if you can afford it (and you often easily can for server side code), GC is a no-brainer as it offers memory safety, ease of use and very good performance all at the same time.
• streetcat1 7y ago
  Go was designed by ken Tompson. Arguably the best programmer alive.
• maximp 7y ago
  I love this. I haven't found many articles comparing and contrasting languages this way, and I really appreciate it.
• desc 7y ago
  Warning: brain dump ahead. Broadly speaking, in any system, there is necessary complexity (imposed by the problem domain) and unncessary complexity (imposed by the tools, the developers, the customer's interpretation of The Matrix, etc). Go aims to minimise the latter, which is a worthy goal: I understand very personally how easily it is to add unnecessary complexity while trying to 'contain' the necessary complexity... However, languages also provide useful and usable means to tame the necessary complexity. It's a tradeoff. These days I try to write C# like Go: no IoC, composition over inheritance, specificity over genericity, etc. But enforcing those kinds of limitations at the language layer places a hard cap on the abstractions available later on. To some extent, again, that's a good thing: far too many abstraction astronaut libraries in DotNet-land, spawned by someone's pet project getting overgeneralised. Such things need to be better considered and better contained within the developer group using them, unless they're extremely well-designed which is rare. But if you remove the clean way to do something, people will do it anyway and it will be a mess. Quite probably in an 'edge' codebase, in a system where the senior devs have enough to deal with already, and the clique of devs looking after that particular edge develop their own little dialect of the language. (I don't care how much you think 'any dev can modify anything' in your code, if you've got more than ~10 devs you have 'preferred' people for certain areas, and some newbies will pick up some bits preferentially.) Or you could give them a tool with higher-order concepts, and they'd be able to work within its idioms. Restricting the available idioms just forces people to create new ones. You get doubleplus ungood code from that in fairly short order. Idioms get generated when the culture doesn't already have them, and the culture fragments according to the idioms its subcultures generate if they can't crosspollinate effectively. Don't try to solve a social problem with technology. Solve it with education, discussion and code review instead. If you don't have time for that, you don't have time to fix the mess resulting from the technical solution either. That said, the smaller the service the less likely that it's going to need to deal with higher-order abstractions. If you really are 'just' gluing together services in interesting ways (note that the filesystem is a service of sorts, and Git LFS is written in Go) and you can confine your code to solving specific problems, you probably don't need the higher order abstractions anyway. In which case any other language could probably do the job too, to be honest, but they'd make it easier to sprawl... which brings us back to a language which puts an 'awkward' cap on making things sprawl. Remember that it's very easy for a project to grow beyond its initial scope, and choice of language can encourage, enable, smother or doom that, and any of those outcomes can be good depending on your outlook...
• alexnewman 7y ago
  I like them both but honestly if you don't know which one to use for your task, you probably don't know them both well enough.
• tomohawk 7y ago
  As an experienced Java dev, I switched to golang for a few years and really liked it. Recently, I find myself on a "enterprise" job with Java. I really miss golang. Boxed types? What a crazy idea that an int can be null. Just fixed a bunch of bugs related to that. String can be null? Just say no. golang's value types are much less error prone. You can go out of your way and pass a pointer to a string, but having to always worry about whether something is null in Java is a PITA. The concurrency story in Java is also horrible. So much effort is required to achieve simple things. You're always having to make trade offs with the heavy weight threading model. Thread pools? What is this, the 90s? With golang, I never once messed with the gc. Not once. We have a gc related discussion about once a week with Java. And the deployment story. So simple with golang. So much extra work for nothing with Java. Just give me an executable I can run. How hard is that?
• worik 7y ago
  AFAICT This is a "GO is great" article not "GO Vs. Rust" article as the title suggests. It is OK to love and propmote a language. GO is terrific and we have been waiting for it for a long time. But so is Rust. If you want to say GO is better choice than Rust ("Why GO and not Rust" is the title after all) listing featurs of Rust ("...Go doesn’t want unused variables or imports...") is not a convincing way to proceed. Horses for courses and we should have stopped language wars in 1995!
• jillesvangurp 7y ago
  Knowing very little about go, I jumped in to do some maintenance on a few go projects two weeks ago. I was able to do what needed doing within a few hours and implement a few simple changes. I did not consult any books or tutorials. But simply learned by example and did a few targeted searches to figure out basic stuff like "how do I assign a value to a variable", "what syntax do I need to use to create a struct". Mostly, it's all fairly straightforward. The code base has a history of non go programmers doing work on it. It's not pretty but it works and is maintainable. IMHO that is impressive. I'm sure a few senior go developers would be all over the code base to improve it. But as it is; it kind of does what it is supposed to without much fuss. Having looked at but not really used Rust, I'm pretty sure there's no way I can be productive in that language on a similar timeline. Unreadable rust is a thing if you are not familiar with all it's syntax, macros, type voodoo, and pointer juggling. That being said, go does look kind of ugly and verbose too me. I've never seen so many "if err != nil" statements before. The code I was working on is littered with it. Error handling is going on all over the place along with a lot of conditional logic around that which is a bit of a code smell. I also noticed a poor man's version of OO where you have structs and then a bunch of functions operating on that struct as the first parameter. I think I'd prefer the real thing. It seems variables are mutable by default, which seems a bit backward these days. So, there's also a lot not to like.
• Myrmornis 7y ago
  I haven't used go much yet but I can say that the O'Reilly book on Rust is a really enjoyable educational experience.
• apta 7y ago
  > Go was created at Google to solve Google problems Still, the vast majority of critical and infrastructure code at Google remains written in C++ and Java. Languages with superior performance, ecosystems, and that have actually proven to work in large scale programming (as opposed to hand wavy incorrect claims about being that). golang is more or less a hobby project with a lot of bad design decisions that went too far.