Hacker News Reader

Comment by gameswithgo | Hacker News Reader

I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving. I hope Rust can settle down into a similar focus soon.

View on HN

I think Go is the only software release at this point to whose releases I respond with ‘Ooh shiny’ and not ‘Oh god’. I love the way they’re doing this — calm, collected, slow, and with ample heads up.

At this point, I think we all have some JavaScript PTSD.

i feel the same way!

C# obviously has a very different design philosophy than Go, but its releases are moving along at a similar (and IMO, reasonable) pace.

Yeah, for me the turnaround point for JS was when they added classes - JS is not an oop language and trying to make it look like one doesn't work. Worse, they didn't even implement it properly - no access modifiers.

Call me a bit of a luddite but this is one of the reasons why I'm skeptical about generics in Go - it'll be another language construct to keep in mind. Mind you this opinion of mine is baseless because unfortunately I haven't had the opportunity to do any serious go development yet.

Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async.

Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way.

Rust has a much wider ambition : all the modern languages facilities (generics, metaprogramming, etc) with the speed of C, AND breakthrough memory-safety features.

Go doesn't try to innovate, and i suppose the author see innovation as something you should stay away until it's nothing new anymore.

> a better C, aimed at server-side data plumbing

I agree with all what you said but this. Go isn't a better C, it's a better Java.

I think in practice it has become something closer to a better python than a better java.

Personally, I don't think it's better than any of those languages.

More like a "different Python" than a better one. Way more performant, way more verbose, and (IMO) way better concurrency.

Not to go off on too much of a tangent, but I think asyncio is a huge mess and was a mistake. I still use gevent for everything in Python. https://glyph.twistedmatrix.com/2014/02/unyielding.html is frequently cited as an argument for why goroutines and gevent and green threads suck and why explicit asyncio-style concurrency is better, but I have a lot of issues with this article and find the former two way easier, simpler, and faster to work with.

> it's a better Java.

Ah ha ha ha ha ha ha. No. Just no.

I say this as someone who writes Go day in and day out and wrote Java for a decade.

Maybe it is if the last time you touched Java was 2001.

Can you explain why they're wrong?

Java got async I/O in 2002, generics and "for (x : iterable)" in 2004, and lambdas in 2014. Vintage 2001 Java was drastically harder to read and slower, though error handling was always less cumbersome than Go.

It sounds like the point the person was trying to make was in use-case, rather than language semantics. As in, where one might've used Java before, they would now use Go. Not that Java and Go are semantically similar.

When did Java get versioned modules, value types, installable binaries, dynamic heap size?

Installable binaries, around 2000, when the first commercial JDKs started having AOT compilation to native code.

Currently available on PTC, Aicas, IBM, OpenJDK AppCDS (originally from BEA J/Rockit), GradleVM native images, Android ART AOT compilation.

Dynamic heap size, since ever. Every JDK vendor had their own specific switches to configure it.

Versioned modules, since Java 9 alongside Maven/Gradle.

Value types, yeah point taken. There were Azul and IBM specific extensions, ObjectLayout and PackedObjects respectively, and the 2nd experimental release for value types was just made recently available.

Except that in the real world no one use installable binaries and everyone is embedding 150MB of JRE / JDK.

If that would be the case, the companies that sell commercial JDKs would be out of business, and yet here they are, selling Java tooling since around 2000.

Maybe you are referring to the "real world" where developers don't pay for their tools.

As for embedding 150MB of JRE / JDK, it is hardly any different than embedding the Go's runtime into every static compiled executable.

Practically speaking this is a non-issue, since its not 1996 anymore. You install the JRE / JDK into your VM or container image. And you basically never think about it until you need to do an upgrade...

You have to stop using interfaces to avoid boxing your value types. Go should monomorphize functions.

"error handling was always less cumbersome than Go" You mean useless stack traces 50 lines long?

You're free to filter any of that out, and the boilerplate that generated it doesn't obstruct your reading of useful code.

I feel like there is a better way of posting this argument than laughing at them and dismissing what they say, and not providing any reasons why you disagree.

This sort of comment will get you banned here. Please post thoughtfully and substantively, or not at all.

https://news.ycombinator.com/newsguidelines.html

One day, when it has proper generics, interface validation without compiler error tricks, and an usefull portable UI library, it might be a better Java.

I went to a Go meetup where I use Go as a complement to Ruby. The speaker and most of the others there were using it as a more expressive/easier C. The middle ground it has carved out seems to let everyone say that their language does something better, but there seems to be a good chance that Go does a reasonable job at what their language doesn't do well (and isn't too far off to learn).

it is a better-java language with c blood.

Nah, Kotlin is a better Java, Go has a mostly different use case.

I don't know if "all the modern languages facilities" was a goal of Rust from the start. It seemed like the initial goal was to be able to develop a web browser with memory safety.

"all the modern languages facilities" seems to be something that's come along more recently (last couple of years) as a result of a lot of non web browser developers taking an interest in the language.

I feel like Go is the way it is, mostly because its maintainers are also responsible for the continued productivity of thousands of engineers working on Google's numerous Go codebases. Any "breaking change" that requires rewriting Go code is a tangible negative for them, in that it'll interrupt Googlers from getting real work done, and the blame will come back to them.

In a sense, Go is more like a corporate-internal DSL that the public just happen to be able to use. (Erlang is—or at least, was, for the first ten years of its life—another language that is this way.)

Personally I think this is a pretty positive thing. If a language is at all popular then any breaking change is going to mean work for users, and having those users sitting next to you in the office keeps it fresh in your mind when you're tempted to make that "one small change" to the language.

This thread isn't about breaking changes, though. Neither Rust nor Go make breaking changes.

Rust doesn't really introduce breaking changes. There is just a lot of cognitive power required to keep up with everything, which can make it hard to read other people's code, or know which is the 'best' way to do a thing, etc. People who disagree with this may simply have more cognitive power/time to devote to keeping up with everything in Rust. I have a day job in an entirely different universe, so keeping up with Rust is hard.

I hadn’t thought of this before, but I think you are onto something critical about Go.

In a different life, I worked deep in C# and the bowels of the CLR. New versions of C# were both exciting (woo, LINQ, anonymous things, lambdas, and a dozen others each release) and frustrating (ugh, visual studio doesn’t have specialized tools to handle this new stuff).

I’ve been writing Go for 8 or 9 years now and I value the tool chain improvements far more than the language features. Race detection was a godsend. Indeed, even taking away capabilities (or just being more strict) has been valuable—like when multi-threaded access to slices became an error.

In this release, I don’t much care about the new literal prefixes. But I’m excited about the improvement to defer performance and the improved range check panic messages.

In a sense, other languages make it easier to to write new code with each release, but every iteration of Go makes my old code better too.

Rust moves slowly too. I'm not sure where the idea that Rust makes changes willy-nilly came from, but anyone saying that is deeply unfamiliar with the RFC process. It's extremely hard to get new features into Rust.

Perhaps it's the number of things changing that leads to the feeling of rapid movement. After all, 60 1mph increases are all tiny by themselves.

Not sure if that's true or not though. Rust is my daily driver for the last year and even coming from Go (after 6 years) I don't feel the pace is hard to keep up with, or that my code breaks frequently.

In fact, I don't think my code has broke as a result of changes once since I switched to Rust. It has happened .. twice maybe, via dependencies, though.

Maybe Rust moves slowly, but not nearly as slow as Go. I know because I use both languages daily. I spend almost no time in Go code keeping up with deprecations, new APIs and new language features. Not all of those things need to go through the RFC process. For example, I don't think there's any backpressure against deprecating stuff right now. As soon as a replacement comes along, a deprecation pretty routinely occurs just a couple releases (a few months) after it. I don't spend a ton of time in Rust responding to churn, but it's definitely noticeable.

This is why I've been bleating a bit more now than I have before about reducing churn.

N.B. On reflection, perhaps I do have some bias here. My daily work on Go is mostly for $work, and involves one large codebase. My daily work on Rust, however, involves maintenance of dozens of crates. So if there's churn, I feel it repeatedly. So its effect might be magnified for me personally.

One example where Rust is moving faster than Go is the compiler:

* Excluding patch releases, Go has a release twice each year [1], while Rust has a release every six weeks (about 9 times per year) [2].

* For minor (patch) releases (security updates, etc), Rust only cares about the latest version released. Go provides patch releases for the last two releases [3].

* The latest release of the Go compiler (1.13, Sept 2019) is able to bootstrap itself from Go 1.4 [4], released on Dec 10 2014. The latest release of the Rust compiler 1.37.0 (Aug 15 2019) needs Rust 1.36.0 (Jul 04 2019) for bootstrap.

* For the language, I think relative to itself, Rust has considerably slowed down with development compared to the pre-1.0 times. Now it's still evolving more quickly than Go. Rust is getting async_await, const generics, etc while Go is discussing about an error handling operator that Rust already had two revisions of since its 2015 release (try! and ?).

I'm not saying that all of this churn that Rust has is bad. Some of it is good, like the tighter release schedule that prevents half finished stuff to be released. But other things, like the tight version range that the compiler can bootstrap from, could be improved.

[1]: https://github.com/golang/go/wiki/Go-Release-Cycle

[2]: https://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

[3]: https://github.com/golang/go/wiki/MinorReleases

[4]: https://golang.org/doc/install/source

Does the compiler bootstrap version matter though? Taking the principle that compilers should compile on the most easily accessible toolchain, writing the compiler in C++ would be the best option of all. But nobody wants to do that.

Yeah, if you take the principle further it would be even better to write it in C89 because this language is comparatively easy to write compilers for. But the principle is not absolute and it doesn't stand above everything else.

There are major differences in how easy it is to write compilers in C++ vs C89. There are major differences between C++ and Rust with its ADTs and pattern matching. But are there major differences between, say Rust 1.32 and Rust 1.36? I'd argue no.

There are real use cases like distros wanting to maintain/bootstrap a Rust compiler independently from upstream binaries. The more often these people have to port a compiler, the more troublesome it is for them.

Rust seems like it's the odd one out: Swift is written in C++, Go supports bootstrapping from years old compilers, LLVM does so as well, and GCC has probably some of the best backwards compatibility stories out there.

Why the odd one?

D has been replacing the C++ code with D, .NET made a major reboot with Rosyln where VB.NET and C# got bootstraped (F# was already bootstrapped), OCaml and Haskell have only the runtime in C due to convinience with everything else bootstraped, FreePascal is bootstraped, OpenJDK has the long term goal of replacing C++ with Java/Graal, Jikes was bootstraped in Java, ...

You are misunderstanding me. I don't have problems with the fact that Rust is bootstrapped, but with the high rate this bootstrapping is happening. That a 12 week old compiler is already considered as too old to compile the newest rustc. This seems wrong.

Ah, yes that is indeed a bit too much.

I also agree an yearly baseline would be much better.

According to the notes here[1], it sounds like companies care enough about bootstrapping Rust that they are doing it via mrustc. Which seems pretty extreme and suggests they care... a lot. (This was surprising to me to find out, at least, the degree to which they care. I understand why bootstrapping is itself an important ideal.)

[1] - https://users.rust-lang.org/t/rust-in-large-organizations-me...

Russ Cox gave a talk at GopherCon 2019 and talked about the 4 R's of Simplifying:

Reshaping

Redefining

Removing

Restricting

And he follows up with examples of how they applied those to the code base. If you've not seen it you might enjoy it.

https://www.youtube.com/watch?v=kNHo788oO5Y

Russ Cox also recently wrote a series of blog posts about Go proposal process, which is also interesting: https://research.swtch.com/proposals

Rust has a focus - it is articulated through the roadmap.

- 2018 roadmap https://blog.rust-lang.org/2018/03/12/roadmap.html

- 2019 roadmap https://blog.rust-lang.org/2019/04/23/roadmap.html

It's a big community, and it has time for a lot of development

Rust needs to settle down to reach broader adaption, because the ecosystem must stabelize. No business oriented project manager would choose Rust as an alterative to Go or Java while Rust has "only" a community http lib on version 0.12.

Sure, async needs to be shipped and polished, but then Rust needs to tell the world: "We have all you need and as stable as you need."

Heh, I like the way Rust proceeds as a language, with regular releases and improvements. I hope Go can make quality of life improvements with similar speed.

Reply on news.ycombinator.com