Hacker News Reader

This meme really should die.

It has never been true so there's nothing to forget.

The number of full-time Rust people paid by Mozilla is roughly the same as number of Go people paid by Google.

Mozilla is a wealthy company and while Google is even more wealthy, it doesn't mean that it spends all its money on Go. Both v8 and Dart are staffed with more people and Dart is not taking off the way Go is.

People are trying to rationalize away the explosive popularity of Go with all sorts explanations, the "it's all because it's Google" being one of them.

The simple explanation is: people use Go because it's a good language. That's the big factor in Go's success.

> Go because it's a good language.

Go fits a niche and is good enough, for now. But Go as a language is seriously flawed, and its flaws will become more and more obvious as the language gets more popular. People can certainly understand Go made the choice of "minimalism". But minimalism doesn't mean the language shouldn't have features people really need. The infamous "You don't need that in Go" sentence will not fly that much longer,especially given how the Go team and community tries to answer Go short comings. The biggest insult to intelligence is that "go generate" feature.It's just embarrassing.

Go for me is a missed opportunity. I still like it but I keep a close eye on alternatives that don't have their core library riddled with "interface{}" like types.

Because there is a need for something simpler and safer than C,that is easily accessible to "script kiddies",that is fast,that has easy concurrency, that compiles to machine code,that has type safety,that isn't tied to windows, in order for people to produce executables that can easily be distributed or concurrent servers.

Whatever language succeeds in that niche will be the biggest language of the next 10/20 years. Mark my words.

> that has type safety

Actually, there is no need for that. Type safety has nothing to do with software being more reliable or more secure. There is, however, a need in language creators, who understand that large standard library with static binaries and cross compilation are super important in a fast moving world where many different operating systems live together on many different architectures.

> Type safety has nothing to do with software being more reliable or more secure.

It is true that type safety doesn't necessarily mean that software is more reliable and secure (it depends on the type system, the semantics of the language, and a host of other things), but saying it has "nothing" to do with it is incorrect. In particular, preventing undefined behavior certainly has an effect on security, whether or not it's through a static type system. As pcwalton has mentioned on several occasions, something like 50% of critical CVEs in Firefox exploited attack vectors that would have been prevented by Rust's type system.

This is where I disagree and believe that such way of thinking about bugs cannot take us anywhere.

Bugs have nothing to do with formal properties of the language. They are the result of people's thinking process. And type system may just as well be the thing someone was dealing with while making his next CVE-worthy mistake.

Factually, Rust's type system guarantees, if consistently upheld, would have eliminated those bugs. Empirically, we know that in typesafe languages like Java, these types of vulnerabilities are far less frequent. These are facts: you cannot "disagree" with them.

Even if we assume that people write buggy code at about the same rate in C++ and Rust, as long as the vast majority of Rust code is not inside an unsafe block, Rust still reaps this benefit, because bugs in safe Rust shouldn't cause memory unsafety.

Finally, yes, bugs do have something to do with formal properties of a language. Really. They do. You can prove that software matches its specification, or fulfills certain properties. People have. SeL4 is a thing. Relying on a static type checker means you only need to trust the static type checker to be correct in order to enforce the appropriate properties, not all code written in the language, and "the Rust type checker" is a much smaller kernel to trust, and will be more widely exercised and heavily scrutinized, than "all other Rust code ever written." This is literally the entire point of static type systems.

I apologize, but this is going to be my last response to you, because I don't think we can have a productive conversation about this.

> Factually, Rust's type system guarantees, if consistently upheld, would have eliminated those bugs.

You are missing my point. It doesn't guarantee to not cause other bugs. And saying that something eliminates some type of bugs is completely misleading, because this is not what matters. It matters to not cause other bugs as well as eliminate some bugs. Which is impossible to guarantee with formal methods. And which is why current academic approach to languages cannot bring us anything, until the whole system changes.

Psychological approach to programming language design is what has to happen. Anything else is broken.

It's impossible to eliminate all bugs, no matter what you do. Psychological design will eliminate some bugs but not all. Static type system will eliminate some bugs, but not all. The best you can do is try to eliminate as many bugs as possible, by doing multiple things that give the best returns, given the bugs you're targeting.

> Actually, there is no need for that. Type safety has nothing to do with software being more reliable or more secure.

If you said this to me in an interview I would politely end the interview there and you would not be hired. A high school student with no programming knowledge at least can be taught. If you're confident in what you just said, you're both ignorant and unteachable.

I really can think of no more scathing indictment of Go than this is the thinking of a typical Go user.

Let's make a small amendment to your simple statement.

>The simple explanation is: people use Javascript because it's a good language. That's the big factor in Javascript's success.

>The simple explanation is: people use PHP because it's a good language. That's the big factor in PHP's success.

Doesn't feel right, does it?

Google and corporate sponsors are incredibly important in building the ecosystem of programming language. Traction may be the single major defining characteristic of language success and one can certainly buy traction with money and influence.

But it's true. Google's association is a big factor in its success. It's not the only reason nor likely the biggest now but it was important at least at the beginning. The fact is that every week we hear about new programming languages. Almost none of them end up being widely used.

Having someone like Google, Mozilla, Apple, Microsoft etc behind it makes a big difference.

It's not so much that Google promotes Go. It's that Google uses Go internally for production code. Thus, the compiler, and the library modules used for web-type services, are thoroughly exercised, and used by in-house people who can insist that bugs be fixed quickly. It took Go far fewer years to achieve stable libraries than, say, Python.

The biggest factor probably was that Rob Pike had basically been prototyping the language for 20 years.

(But google's name certainly helped.)

Not to take anything away from your comment on this being a language that has been brewing for years, but people really should give Robert Griesemer more credit for his influence on the language design.

I know he's the least publically visible of the three, but IIRC godoc and gofmt are mostly his babies. After getting used to those I think I miss them more in other languages than I miss the concurrency.

Well said.

Rob Pike is explicit about early Go development; everything that went into Go was agreed upon by Robert, Ken, and Rob. If all three didn't agree it didn't go in.

But it's not as if they threw a massive amount of manpower or budget at it. I think Go succeeded more by association (to Google) and the fact that it hits a sweet spot for many people - it produces native code, but does not have the complexity of C++ or the unsafety of C.

I have written a fair bit of Go code. But I will switch to Rust without a second though once the ecosystem takes of. The lack of simple things like generics or algebraic data types in Go is jarring.