[pcwalton]

> Overall though, Go is probably still the more practical choice between the two languages (due to Rust's incredibly high barrier to entry).

It depends a lot on your use case. I wouldn't say that Go is unconditionally more practical: there are cases in which you just can't use it.

[jkn]

Indeed. But looking at the GC improvements in Go 1.8 ("typical" GC pauses of less than 100us), the set of cases where you can't use the language might be shrinking significantly. Now if only they could turn that in some sort of guarantee...

[pcwalton]

The sole performance metric of GC is not pause times! Throughput matters just as much if not more!

GC pauses are not the only reason to use Rust. Rust is not "little Go" that you reach for only if you don't want GC. You might want package management, data-race-free concurrency, a mature optimization framework, runtime-free operation, concurrent data structures, fast C interfacing, etc. etc.

[jkn]

You're right of course about the GC metrics. And there was some disappointing increase of GC CPU usage with the 1.8 changes (I don't now the current status). But some of the items you mention (package management, mature optimization framework) will hardly make cases where Go cannot be used, which was the original point. Same for concurrent data structures which can be implemented in Go, even if the lack of generics makes it less convenient. I do agree with you regarding the other items.

[pcwalton]

Aggressive compiler optimizations are not optional in many domains.

One rule of thumb that a lot of people don't realize is that if you aren't maxing out your sequential performance, your parallel multicore algorithm usually loses to an optimized sequential one. The reason is simple: parallelism introduces overhead, leading to guaranteed sublinear speedups. Compiler optimizations, on the other hand, frequently result in multiple factors of improvement.

[weberc2]

Right, but I think those cases are few and far between. Basically where you need blistering performance and/or deterministic resource usage. I would throw "safety" in there, but many (most?) safety-critical applications are written in C, and Go is certainly safer than C.

[pcwalton]

> Right, but I think those cases are few and far between. Basically where you need blistering performance and/or deterministic resource usage.

No, there's a lot more. See my reply to your sibling comment.

> I would throw "safety" in there, but many (most?) safety-critical applications are written in C, and Go is certainly safer than C.

This argument doesn't make any sense to me. Why is being better than a language from 1978 our sole criterion? Shouldn't we try to make our software as reliable as possible?

Besides, Go is not any safer than C when it comes to data races. I care about those a lot too.

[weberc2]

> No, there's a lot more. See my reply to your sibling comment.

Which criteria from your post can't be rolled up into performance, deterministic resource usage, or safety?

> Why is being better than a language from 1978 our sole criterion?

I have no idea. Thankfully no one made any such argument.

> Shouldn't we try to make our software as reliable as possible?

No, we should make it sufficiently reliable. For example, many applications might not benefit from Rust's pedantic checking of data races (e.g., if the application is sequential), but the impact on development velocity could be prohibitive. By the by, I like Rust, I just think it's not well-suited for most applications.

> Besides, Go is not any safer than C when it comes to data races. I care about those a lot too.

While I absolutely agree, this isn't incompatible with my claim, that Go is at least as safe as C, and thus safety alone doesn't preclude Go from safety critical applications.

[pcwalton]

> Which criteria from your post can't be rolled up into performance, deterministic resource usage, or safety?

Package management. Macros (Rust has a widely used ORM). Generics. Easier error handling. Pattern matching. Functional features, such as map(). A more flexible module system. Built-in FFI. Inline assembly. Etc, etc.

> By the by, I like Rust, I just think it's not well-suited for most applications.

I'm going to push back on this too. In terms of "all programs that anyone has ever written", scripting languages are overwhelmingly the most suitable choice. But in terms of usage, core infrastructure favors reliability, performance, and interoperability with other languages. Consider regex libraries, language runtimes, graphics libraries, codecs, text/internationalization support, windowing systems, UI libraries, browsers, and so forth. This is our core infrastructure, where performance and reliability are paramount, and these libraries have outsized importance.

> this isn't incompatible with my claim, that Go is at least as safe as C, and thus safety alone doesn't preclude Go from safety critical applications.

This assumes that C is OK for safety critical applications. It's not. The status quo is bad. The bar should be much higher.

[weberc2]

> Package management. Macros (Rust has a widely used ORM). Generics. Easier error handling. Pattern matching. Functional features, such as map(). A more flexible module system. Built-in FFI. Inline assembly. Etc, etc

Package management and easier error handling are the only ones that doesn't roll up into safety or performance, and I dispute that Rust's error handling is easier than Go's.

> I'm going to push back on this too ... our core infrastructure ... libraries have outsized importance.

Granted, but that's not "pushing back" on my point, because important though those libraries may be, they still don't constitute a majority of applications.

> This assumes that C is OK for safety critical applications. It's not. The status quo is bad. The bar should be much higher.

Agreed. Rust is better than Go for safety critical applications--note that I never tried to argue the opposite--only that Go is better than the status quo, terrible though it may be.

[pcwalton]

> Package management and easier error handling are the only ones that doesn't roll up into safety or performance, and I dispute that Rust's error handling is easier than Go's.

Generics, pattern matching, functional features, modules, easy FFI, are productivity features! They have nothing to do with safety and performance (although they are incidentally used to implement some speed/safety features, because why not). Inline assembly and FFI are useful for platform interop: again, these are not safety features.

> Granted, but that's not "pushing back" on my point, because important though those libraries may be, they still don't constitute a majority of applications.

I suspect the numbers are like: 95% of applications are best in scripting languages. 4% are best in managed languages (Java, C#, Go, etc.). 1% are best in low-level languages like Rust. If you want me to concede that point, fine. But in terms of importance of projects, which correlates with the number of developers you need on the project, the numbers look very different.

[fizzbatter]

> Besides, Go is not any safer than C when it comes to data races. I care about those a lot too.

Agreed. It may be safer in the realm of "oops i forgot to free memory", but i've had more panics than i could count in Go.

[weberc2]

More importantly, it's safer in terms of using only valid memory.