Hacker News Reader

Comment by hannibalhorn | Hacker News Reader

It's worth noting that the author is Eric S Raymond, who we all know of...

I'd definitely agree that at this point Go is better for network services, and the learning curve / documentation / infrastructure of Rust is a bit scattered. I believe that as Rust matures it'll be better for the non-server stuff (no GC, etc.) and eventually become competitive with Go in this space. I'm quite fond of both languages, though!

View on HN

Yes, he is notorious, but the reasons for his notoriety aren't specifically and instantaneously relevant here. Your statement is indirect, but still quite clearly praeter hominem.

I think it is very relevant - the author of "The Cathedral and The Bazaar" tried out two fashionable new languages, one coming from a corporate team and one designed by a community ... and went with the Cathedral option. As a fan of both languages, I just find it very interesting!

He actually addressed precisely this issue on his personal blog: http://esr.ibiblio.org/?p=7303

My apologies, I can see the rails now.

I'm not certain how you concluded Go was the Cathedral option. I came to quite the opposite conclusion: you'd better cross yourself and genuflect in Rust.

Go started out to address the problems of a particular large corporation with a gigantic C++/Python codebase, and was conceived by a small team of well respected industry experts.

Rust started out as the new generation engine of an open source browser, conceding that no existing language met its needs, and has been community driven since that point, often making breaking changes in pursuit of the ideal.

Go has indeed been very open to community input, but of the two, it seems clear that Rust is the bazaar, and Go is the cathedral, no? I'd love to hear how you arrived at a conclusion to the contrary.

From the outside, Rust and Go were both originally developed by corporations eventually with community involvement. The credit line for Rust has been changed from the original Mozilla to the Rust Project Developers. Go has remained Google.

https://github.com/rust-lang/rust-packaging/pull/49/files

But I don't see this corporate history as at all indicative. By comparison, Unix was originally developed by Ma Bell whereas Lisp was developed by a community. My view is based more on the resulting languages rather than the process that got them there.

Again, though, this is from the out outside.

Rust was created before Mozilla got interested in it: http://www.steveklabnik.com/history-of-rust/

For anyone else who gets confused by this empty-seeming page: it's a slideshow. The right arrow key moves through slides.

To be fair, Mozilla is a very different sort of corporation than Google. Notably the Mozilla Corporation is owned by the Mozilla Foundation which is a non-profit.

(As a disclaimer, I'm a biased ex-intern.)

Rust was in development for 3 years before Mozilla's involvment.

I would also note that Rust's development model is a lot more open, Go doesn't even accept pull requests.

Go does accept pull requests, just not GitHub ones: https://golang.org/doc/contribute.html#Code_review

(I don't disagree with the premise though, Go does seem to be less community-driven than Rust; e.g. Rust has 3 mozilla employees in the top 10 contributors for the most recent release[0], where as Go has 9 Googlers in its top 10[1].)

[0]: https://github.com/rust-lang/rust/graphs/contributors?from=2...

[1]: https://rakyll.org/go18cls/

It also seems to require a CLA and a bunch of other barriers. Everyone's on Github - not accepting pull requests on there (without a CLA) limits the contributor pool.

The copyright for Go has been

  Copyright YYYY The Go Authors.

ever since its public release in 2009. Google only holds the copyrights for the subset of contributions to Go made by Google employees, but there's no Google credit in the sense you're describing.

Rust may lambast you at compile time. That gives you more security and less need for genuflection at run time.

I totally appreciate that value proposition. I chose Rust over Go.

I agree. Go seems to have adopted a worse-is-better approach in a few areas and according to this article, it's paid off.

OTOH, something he doesn't mention in the article is that he's a big Python fan. And Go seems to appeal to the same developer base.

If you read why ESR is a Python fan, it turns out to be similar to the reasons he liked Go in this article: ease of learning and a simplicity that led to writing working code on the first run.

http://www.linuxjournal.com/article/3882

> a simplicity that led to writing working code on the first run

...whereas Rust optimizes for the property "Once it compiles, it's probably going to work flawlessly on the first try."

You do spend a lot of time having a conversation with the compiler first. But I like that mode of working; even in Ruby, I have a long "conversation" with my unit tests before I ever run anything.

> writing working code on the first run.

Rust very much lets you write working and less buggy code at first run, if perhaps not the first compile.

Indeed, it's a mentality I don't share, but I understand the attraction of a gentle on-ramp. Of course, a bit of time spent understanding why Rust made different decisions might have been illuminating.

Would we be discussing this if it were anyone else writing a language review after 4 days? And for a 62kloc project?

Have to agree with you there, the post is mostly light on details, but it's interesting that ESR can't get over the borrow checker. I wonder if he really tried or was already set on Go anyway.

This seems like a common enough complaint. I don't think there's a conspiracy theory against Rust. :)

No, I meant it that Go already felt like the right tool, so unless he could get into Rust really quickly, the decision was already made.

Ah, my mistake!

Reply on news.ycombinator.com