[brandur]

I've taken a very similar path recently myself and started looking into Rust.

> 2. Proper error handling. I love error checking

Hugely agree here. I can get behind Go's overall mentality of returning errors instead of throwing exceptions, but in my mind there are not enough primitives in the language to keep this style of coding safe and sustainable.

Rust's `Result` type, `try!` macro, and pattern matching are an incredibly powerful combination, and make Go's approach look downright medieval in comparison.

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

[olauzon]

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

Does Rust really have an "incredibly high barrier to entry?"

I've been using Rust for a few months, and just deployed my first high-throughput application a month ago, and my experience has been the opposite. Yes, the first couple of weeks were a bit rough while I was getting used to the ownership system, but since then I have been progressing at a relatively quick pace. The package and dependency management facilities are incredibly good, and I've found high-quality libraries for nearly all my initial needs.

Compilation times could be faster, but the error messages provided by the compiler are so useful that I have come to depend on compilation errors for refactoring. The gains in predictable performance and resource utilization have far outweighed any initial cognitive overhead in the learning process. The community and the resources they provide are fantastic.

Coming from a mixed dynamic language and functional programming background, I could see room for improving certain FP aspects of the language, but am impressed with the pervasive pattern matching and collection handling.

Not a knock on Go, but rather an endorsement of Rust and its future.

[grayrest]

> Yes, the first couple of weeks were a bit rough while I was getting used to the ownership system, but since then I have been progressing at a relatively quick pace.

This is the very definition of "high barrier to entry". Clearly it wasn't too much of a barrier for you but I can see how it'd be an issue for people. I'm expecting editor support and wider adoption (differently constructed tutorials, SO answers) to lower this barrier. I think Rust has the potential to be very popular, particularly if the reputation shifts from "high barrier to entry" to "slightly harder to get started but fewer problems in production".

[olauzon]

I can see that, but a couple of weeks of investment doesn't seem "incredibly high" to me.

[brandur]

It took me about a week of fairly vigorous effort to start writing it fluently, but I also have the advantage of having seen and written many other programming languages. I have a few anecdotal examples of friends who are great developers, but still have trouble with Rust's ownership system.

When I say something like "incredibly", it's after thinking about trying to teach it someone more junior (like you'd see in a corporate environment with a mix of skill levels). I think that this would be a very difficult task.

[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.

[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.