[CatDevURandom]

I'm going to try and not come off as frustrated, but as someone who really enjoys and sees a place for both languages, I'm getting a little tired of the rust vs go zero-sum game thing here on HN. And at least you end your first paragraph with the acknowledgment that it's really "Apples to oranges really though." But -- since you did write that paragraph I'm going to address your points.

> Rust is an epic and amazingly rewarding to learn

I liked learning it too because it filled a pain point I've been feeling for years when it comes to systems programming. Can you specifically explain a bit why its "epic" and "amazingly rewarding" to learn?

> Rust is far and away the most modern, state of the art and most important programming language of our time

Holy guacamole that's quite the assertion by someone who, by their own admission, is still learning the language, how do you feel qualified to make such a ... well.. hyperbolic statement?

> Go compiles easily (pay for it later!) By easily, I assume you mean quickly. How do you pay for it later?

> there's a lot of guarantees

Like what?

> After picking up Rust I feel like Go just offers nothing.

Why?

> Why not use Java or .Net instead of Go? Highly unlikely Go will be more performant than the JVM.

It already is, in some ways. Can you be more specific?

> Want something less safe and easier to write in, why not use Python, etc?

Go is less safe than rust?

> You can't write real time systems in Go and you never will be able to. You probably shouldn't write "systems" programs in Go.

Why do you personally think that? For example, I'd say that Rust gives you more control over memory. And has smaller binary sizes. But still, I've been frustrated by the overall size of binaries in both languages. Go in particular makes embedded programming near impossible (I was hoping to write software for my MIPS router in Go but was unhappy to discovery a nearly 12 MB binary file)

>Go has a couple built-in features that other languages can and will get with library addition. Go is a 1-trick pony I feel sometimes. It's an "in thing" that doesn't serve much of a purpose overall I feel. It looks like C but lets face it, it's nothing like it in terms of performance and never will be. It isn't a replacement for C.

Why do you get the impression that is Go's purpose?

> Is it Google looking at the same strategy as Sun/Oracle and Microsoft? Who knows.

Which is what, exactly?

> it feels like a regression

From what? Why?

> Developers, developers, developers!

Oh my god, you are a troll bot.

[4ydx]

Don't let copsarebastards phase you. They seriously hate golang as is obvious from their prolific ranting about its deficiencies in many a thread. I really wish they would just let it go, but some people really obsess over how "right" they are in their thinking. It is myopic really. Golang is a wonderful language (even without generics) :) It is the first language I have ever enjoyed writing concurrent code.

[copsarebastards]

I'm not the person you're responding to, but I agree with most of what they said, and here's how I would respond to what you're asking:

>> Go compiles easily (pay for it later!)

> By easily, I assume you mean quickly. How do you pay for it later?

I think they actually meant easily, not quickly, in the sense that the type system doesn't require a lot from the user. However, you pay for that later when your codebase becomes larger and you start experiencing bugs that could have been caught by a more sophisticated type system.

>> Rust doesn't compile easily but when it does there's a lot of guarantees.

> Like what?

Rust guarantees a number of kinds of memory safety. It's important to note that this is in comparison to C, not to Go (Go actually has stronger guarantees because of GC, I think). But Rust's strong typing also catches a lot of kinds of bugs that are hard to quantify mathematically but are pretty apparent to anyone who has worked in both strongly and weakly typed languages. I wouldn't call these "guarantees" but I would say that I'm definitely more confident in strongly-typed code than in weakly-typed code.

>> After picking up Rust I feel like Go just offers nothing.

> Why?

Because after using both languages, he hasn't found anything that Go offers. What exactly do you think Go offers that isn't available in other languages?

>> Why not use Java or .Net instead of Go? Highly unlikely Go will be more performant than the JVM.

> It already is, in some ways. Can you be more specific?

For general use cases, the JVM has years of tuning behind it. You can't get more specific than that, as obviously there are some use cases where Go might shine. But as projects grow large, many use cases come out and it's highly unlikely that an arbitrary project will just happen to only have use cases that favor a new language without years of performance tuning behind it, especially when the designers of that new language shows no interest in looking at the last few decades of language research.

>> Want something less safe and easier to write in, why not use Python, etc?

> Go is less safe than rust?

Absolutely. Go's type system is decades behind. C++ has a stronger type system. Rust's, meanwhile, is extremely sophisticated, using ideas from strongly typed functional languages. There are some cases where compromises were made to allow low-level memory access which might allow some bugs which aren't likely in Go, but those are calculated compromises. Go's type system offers neither the safety of a modern statically-typed language nor the flexibility of a modern dynamically-typed language. Go's type system is just pitiful.

>> You can't write real time systems in Go and you never will be able to. You probably shouldn't write "systems" programs in Go.

> Why do you personally think that?

Because GC simply isn't to the point where it can be used for real-time programming, and systems-level access often is just easier to do with manual memory management.

>> it feels like a regression

> From what? Why?

From any other major recent language, because it offers no new innovations and actively doesn't include ones that have proven effective elsewhere.

[thrownaway2424]

>>> For general use cases, the JVM has years of tuning behind it.

Much like that Camaro in my cousin's front lawn. The JVM has years of tuning behind it because nobody can make it work. It is so awful that there exist genetic algorithms[1] just to try to set all the GC parameters to something with good throughput and minimal pausing. Meanwhile, the number of times I've been paged in the middle of the night because my Go server's new-gen permanent eden survivor ratio was critically low has been exactly zero.

https://github.com/sladeware/groningen

[copsarebastards]

The number of times I've been paged in the middle of the night because my Java server had any issue caused by the JVM's configuration has been exactly zero, too. Basic configurations for both the JVM and Go are adequate for 99.99% of projects. You haven't run into problems in Go for the same reason that you wouldn't run into problems on the JVM--you're not writing 0.01% use cases.

According to Oracle, 3 billion devices run Java. That means that a JVM problem which occurs on 1 in 10,000 devices occurs on 300,000 devices. An obscure problem in the JVM can affect more devices than you'll probably ever write code for.

The other 0.01% of projects probably just don't exist yet for Go. If people start using Go on the same frequency, variety, and scale as they use the JVM, I'm quite certain that problems will arise which will require tools like groningen to solve. It's ridiculous to compare JVM tuning complexity with Go tuning complexity when Go hasn't been applied to a fraction of the problems that the JVM has.

[microtonal]

Basic configurations for both the JVM and Go are adequate for 99.99% of projects.

No! The standard Java maximum heap size is often not adequate for projects, and you have to find a sane value rather than letting your operating system do memory management.

[copsarebastards]

I said "basic configurations", not "default configurations".

I will say that I have run into this issue twice. In both cases, the solution was to eliminate fix code that were flooding the heap with unnecessary allocations.

There are certainly cases where you would want to increase the heap size, but those really are 0.01% use cases. More often than not, you should fix the code that's using so much memory. If your criticism of the JVM is that you wrote shitty code and your shitty fix for your shitty code was to configure the JVM, I'm not feeling a lot of sympathy for you. If that's the case, go be happy with Go, by all means. And if your use case really was one of the cases where increasing the heap size makes sense: well, that kind of project is going to cause issues for Go, too. Just because it silently allows you to pile your heap into the stratosphere doesn't mean it's going to deal well with your larger heap size. In fact, given that it's parallel mark-and-sweep (and not generational) you're almost guaranteed to have performance issues in larger heaps--it's geared toward low overhead and performance on smaller heaps.

As an aside: Azul systems produces a really cool JVM implementation called Zing that does some amazing stuff with pauseless GC. Worth checking out for anyone interested in GC implementation.

[microtonal]

especially when the designers of that new language shows no interest in looking at the last few decades of language research.

Since this is Hacker News, it's very likely that you are typing this on a machine running either an OS that is directly based on 60/70ies OS design (Linux) or a dead-end in 80ies microkernel research (Mach). Still, Unix powers a large number of devices and is popular among hackers. Unices may be less principled than their later peers, but people appreciate the trade-off between architectural principles (composability, everything is a file) and pragmatism in the form of 'worse is better'.

Go's developers are probably aware of most research in PL design. Go supports structural typing after all (OCaml and C++ via templates being the only other major languages to support it), and has CSP (yes, I know that's 78-85 research). But besides that, in line with its UNIX/C/Plan 9 heritage, Go is relentlessly pragmatic, choosing simplicity over abstraction power.

Evidently, Go has hit a sweet spot for many people, because Go already has big success stories (from Docker to Juju), which is impressive given it's short lifespan.

[Jweb_Guru]

I don't think Go's developers are aware of "most" research in PL design. But that's true of most languages, really, there are a billion papers to read. I think people are frustrated by what research they chose to ignore, though... anyway, saying that OCaml and C++ are the only major languages to support structural typing is a bit silly, since a lot of other languages that are probably more popular than OCaml have it (like F# and Scala). And Go's variant of structural typing is pretty limited.