Hacker News Reader

Comment by Animats | Hacker News Reader

This should be titled "A Ruby programmer looks at Rust". There are now a very large number of programmers who have zero experience with anything below the level of a scripting language, and have never had to think about memory allocation. To them, Rust is rather intimidating, and this writer is trying to make it simpler.

Unfortunately, it looks like he doesn't really understand borrowing. The key idea of borrowing is that a borrowed reference can't outlive the thing it came from. It's a lifetime thing, not an immutability thing.

Go is a hard-compiled language compatible with the mindset of scripting language programmers. That's just what Google needs. They have a lot of server side code to write, and it has to go reasonably fast or they have to build additional acres of data centers. With Go, they can put programmers from the scripting language community on the job.

View on HN

Your analysis is good except that last part. Google hires tons of geniuses who could handle Rust easily with a bit of training. The extra efficiency would reduce datacenter requirements even more. Most of their tools are also internal where scripting community has minimal contribution.

So, I don't see a clear benefit for them to choose Go over Rust except saving face. They'd be better off investing in both for various reasons with critical stuff like F1 RDBMS in Rust and rapid dev in Go.

"The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."

-- Rob Pike (http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro...)

Yeah he said that, but presented no evidence to support his claim.

EDIT: quote at 20:40. Not a response to the question.

Do you have a timestamp for this quote? It would be interesting to hear the context--what was said before and after. Was this a response to a question?

That's a good point.

That vontradicts the reported justifications for their selection and interviewing processes. He's telling us they can handle all that but not learn Rust like many average programmers are doing successfully? Does. Not. Compute.

Rob Pike has his ambitions. Great. Meanwhile, almost no one at Google uses Go. They use C++ and Java almost exclusively. Not Python either, outside of Youtube. (There's a reason GvR left.... all of the stuff he was proud of writing in Python got re-written, e.g. Mondrian.)

Pike is right that a significant fraction of Googlers are young and fresh out of school, and aren't 'researchers' (like maybe 33%?). They're also crazy smart, and can learn whatever language you need them to. Note that Google makes new grads learn a new storage model (BigTable etc), learn a bunch of custom infrastructure (everything except compilers and VCS is custom-built), learn all sorts of crazy shit. What Google does with these facts about their developers is that it uses C++ for huge-scale things (underlying infrastructure like BigTable, or massive-scale products like Search) and Java for the less-incredibly-demanding. Not Go. Unless you're Rob Pike and someone asked you if you could take care of something that needed a rewrite anyway.

It only makes sense to talk about Go as a Google language if you are under the mistaken impression that there are about 40 engineers at Google.

Look at https://golang.org/doc/faq#Is_Google_using_go_internally That's basically an admission of defeat. "We eat our own dogfood, and also a few tiny projects use it (one of which is tiny but super important)." Note that "scaling MySQL" is not exactly a long-term priority in a company that built three or four alternatives to MySQL, all superior.

It's possible that, if Google were starting from scratch, that ideas like "write the fast stuff in Rust and the less-urgent stuff in Go, which is still fairly fast" would be good choices. Sounds like a good idea to me. But the value proposition of Go over Java is, I suspect, not big enough to bother turning the enormous ship.

I'd love to hear any current Googlers chime in about a Google product written in Go that actually matters and took more than a hundred engineer-hours to write.

The linked section of the FAQ was written a few years ago. I'm not a Googler, but I can tell you some things visible from the outside.

>Note that "scaling MySQL" is not exactly a long-term priority in a company that built three or four alternatives to MySQL, all superior.

It might be more valuable than you think since GCE sells a hosted MySQL service. I'm speculating here; they could be using something else that's MySQL-compatible, but I doubt it.

>I'd love to hear any current Googlers chime in about a Google product written in Go that actually matters and took more than a hundred engineer-hours to write.

Kubernetes is a non-trivial Go project largely done by Google that's important to the future of GCE.

Thank you, those both seem like convincing evidence that, at minimum, it's not quite as bleak as I had believed.

Note, however, that kubernetes is not used within Google (rather, they use a C++ alternative).

Part of why kubernetes uses Go is that it's in a docker-centric container ecosystem. Docker picked Go for its own reasons, not because of Google, so in a way, Kubernetes is picking Go because of the outside community, not because of Google or the language itself.

GCE operates GKE which is a hosted Kubernetes as a service. I'm not saying that Google is using Kubernetes instead of Borg, but that doesn't mean they don't use Kubernetes at all.

TheParent's explanation makes more sense. Note that the key use case they mentioned for that was an offering for the Docker ecosystem:

http://www.infoq.com/news/2014/11/google-cloud-container-eng...

So, people are using Kubernetes in the Docker community. Google offers a GCE service for that. This seems incidental to Go with community and demand really driving its use. That they avoid it internally where possible is still a strong point given the large ecosystem developing around Go. Assuming it's true that they avoid it for C++ and Java of course.

Oh I was just commenting similar to this above. Is the C++ alternative Borg? I believe this spins up a VM like KVM and the runs the container inside the VM.

Does a mysql compatible product include the bugs? :)

How is Kubernetes important to the future of GCE? I don't believe thats the scheduler they are using for compute. I know you can run Kube on top of GCE but that's obviously not the same thing. I was also told by someone at Google Cloud that when you launch a compute instance on GCE its actually running inside a VM as well. So this container inside a VM leads to me to think this is true. The VM might be for security, I'm not sure.

Not that it's necessarily better if the projects you are making take over a hundred hours to write, because it does suggest an attraction to monolithic designs.

> Google hires tons of geniuses who could handle Rust easily with a bit of training.

With the quality of tooling we get on Android, I always wonder where those geniuses work.

Lmao. Smart != wise. I'll take above-average, experienced developers w/ track record in good deliver vs QA tradeoffs over new geniuses any day. Google probably does the opposite. I imagine that's what brings such results.

To them, Rust is rather intimidating

I'd argue that Rust's concepts of ownership, borrowing and lifetimes are rather intimidating even to people who have had to think about memory allocation. You can get part of the way there with analogies about stack-allocated vs. heap-allocated in other languages, but ultimately it's just a concept that, say, the average C programmer is going to find alien and difficult at first (largely because it's designed to prevent common types of errors committed by the average C programmer).

> This should be titled "A Ruby programmer looks at Rust". There are now a very large number of programmers who have zero experience (...) To them, Rust is rather intimidating, and this writer is trying to make it simpler.

Funny. I find Rust a more accessible language than Ruby. Rust is certainly not an easy language to learn, but the basic concepts (ownership, borrowing, lifetime) are based on everyday life, and the analogy is precise enough that I don't need to worry about a mismatch between my intuition and the language. For instance, if I let my friend borrow my car, I can't drive it myself until he returns it to me (freezing). And, if a married couple owns a car (Arc), they must take turns to drive it (Mutex, RwLock).

On the other hand Ruby's design principles seem to have been:

(0) The syntax has to look like English. This is non-negotiable.

(1) Each feature must be easy to explain (FSVO “explain”) in isolation.

(2) Interactions between arbitrarily many features are allowed to be arbitrarily nasty.

Ruby doesn't look like English. Hypercard:

    put word 2 of the clickLine into lino

and COBOL-60:

    MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN.

looked like English.

Point taken. I was thinking about how Ruby DSLs are often designed to resemble English text as much as possible.

> Unfortunately, it looks like he doesn't really understand borrowing. The key idea of borrowing is that a borrowed reference can't outlive the thing it came from. It's a lifetime thing, not an immutability thing.

As a rust newbie, this touches on something I've been trying to figure out how to think about. Should I think of `&` in terms of ownership exclusively, or is it also useful to think about passing a pointer vs copying the data?

That is, suppose I have something that, semantically, I want to move into a function, and which the function later returns. I think I could also pass a `& mut` instead. I'm trying to decide how to reason about that decision. Is the compiler smart enough to turn moving/returning into passing a pointer behind the scenes? If it's a large struct do I need to think about that "optimization" of instead passing just a `&` instead of moving the whole thing?

  > Is the compiler smart enough to turn moving/returning 
  > into passing a pointer behind the scenes?

Rust guarantees RVO, yes, and this is even baked into its calling convention.

> That is, suppose I have something that, semantically, I want to move into a function, and which the function later returns. I think I could also pass a `& mut` instead.

That is exactly what `&mut` is for. An &mut gives you an "ownership lease" on an object; you own it as long as you have the &mut.

> This should be titled "A Ruby programmer looks at Rust". There are now a very large number of programmers who have zero experience with anything below the level of a scripting language, and have never had to think about memory allocation. To them, Rust is rather intimidating, and this writer is trying to make it simpler.

C++/C doesn't have ownership concept, it may be similar to references but when starting on rust I had to change mindset and constantly fought compiler.

Article itself is interesting because it explains why there is certain syntax, and not a tutorial how you should code in rust.

C and C++ have very strong concepts of ownership. Anything you allocate must be deleted exactly once. Any use of an allocated object must be during that object's lifetime, before deletion. Access beyond the end of an allocated object is prohibited. Violate these rules and your program will crash, garble data, or be exploited.

But C and C++ don't provide any language level help to programmers who must make their code obey those rules. Rust does. That's the great advance in Rust. The ownership model is explicit and checked.

You have a point, however, what rust enforces is more strict than what you need to adhere to in order to write a correct C program.

The proof of this is that several core concepts that are considered "safe" have "unsafe" portions that make let work. Thus, there are safe things that rust doesn't consider safe, or that rust cannot infer is safe.

  > The proof of this is that several core concepts that 
  > are considered "safe" have "unsafe" portions

I don't understand this argument. Rust could have built those features (e.g. `Rc`) directly into the compiler itself and it wouldn't have made the language itself any more safe, and it wouldn't have made the safe bits of the language any more or less powerful.

In fact, `Rc` was once a first-class part of the language itself, and was indicated by the `@` sigil. The fact that it now lives in the standard library rather than the compiler is because library code is easier to audit for correctness than the compiler internals; to prove that the language is powerful enough to permit user-defined smart pointers and memory management primitives; and to permit alternative implementations of basic language features to be swapped in and out via custom standard libraries (which is way easier to do than forking the compiler).

> You have a point, however, what rust enforces is more strict than what you need to adhere to in order to write a correct C program.

And C enforces stricter type checking rules than what you need to adhere to in order to write a correct Python program. This is not a bad thing; having an automated assistant that can catch errors as you make them is highly useful. Rust simply pushes this to the domain of memory management and once its rules become more engrained in our development habits, I'm sure it'll be about as painless to deal with than it is to deal with type checking.

> The proof of this is that several core concepts that are considered "safe" have "unsafe" portions that make let work

I think this is actually a common pattern in many different domains. For example, the OS kernel's virtual memory subsystem does many things with "unsafe" primitives -- it has direct access to page tables and can map anything anywhere -- yet it provides a "safe" abstraction of isolated process address spaces.

The way I think about it is that you have to define basic building blocks somewhere. It's not reasonable to build a static analysis that understands the N different varieties of smart pointers, and refcounting, and dynamically-checked mutability (RefCell), and custom allocators (TypedArena), and all that. It's much more elegant to separate concerns, have only raw pointers and lifetimes/borrowing built-in, and put those pieces together in "blessed" ways with all the unsafe code in one place in the library. If you try to build that understanding into the compiler instead, you're just moving the same unsafe-has-to-be-correct algorithm down one level, and unnecessarily complicating things.

> Thus, there are safe things that rust doesn't consider safe, or that rust cannot infer is safe.

That's also true for any programming language that claims to achieve safety in any sense. At some point you have to have a trusted computing base, whether it's your hardware or the standard library.

In other words, the presence of "unsafe" in the implementations of some things doesn't make Rust unsafe--if Rust is unsafe then so is every other safe language.

I think that swsieber's point was not that Rust is unsafe, but rather that Rust is too paranoid. There exist safe things that Rust will not let you do (without turning off the safety catches)!

Of course, the answer to that is still pretty much exactly what you said: it's true of every programming language that claims to achieve safety in any sense. If Rust is too restrictive then so is every other restricting language.

swsieber, according to says some guy named Gödel, every type system that is sound (and decidable) is not complete. Since decidability is kind of not optional, and most people are not okay with your type system sometimes telling you that something is okay when it's not okay, well, you're gonna have excessive constraints in your language.

I'm pretty sure the answer actually is that certain things are provably safe, at least in a way that can easily be accomplished by the compiler, and some aren't (at least simply by a compiler at our current understanding). We may be able to reason about a situation and prove to our understanding that something is safe, but that doesn't always mean we can encode those rules in a deterministic and terminating way.

I imagine rust would happily extend what it considers safe if it can be determined in an effective way and if it requires additional decoration, doesn't conflict with current syntax.

Decidability actually is optional; some folks experimenting with dependent type systems are bullish on giving up decidability (allowing type checking to fail to terminate in some cases). Typechecking is already 2^(2^PROGSIZE) for, say, ML. That could easily - in theory - lead to impracticably long compilation times. Yet in practice, it doesn't. So why not go whole hog?

Too late to edit, so here it is in a separate post:

My point is that rust is a little more strict than C (even correct C). So even if you are a good C programmer who writes without memory leaks, you'll still probably have to battle the compiler for a bit.

Not hating on rust or its abilities - I think it's great.

Is Rusts concept of ownership any different from C++ unique_ptrs?

It's not identical (Rust statically enforces a lot more than C++ does, move semantics are opt-out rather than opt-in, there's no such thing as move constructors in Rust, etc.), but if you understand unique_ptr then you'll understand Rust's concept of ownership.

As an example, here are two roughly equivalent programs. First Rust:

    let x = Box::new(5);
    let y = x;
    println!("{}", x);

Now C++:

    unique_ptr<int> x(new int(5));

    auto y = std::move(x);

    cout << *x << endl;

(I'm being a bit sloppy with namespaces, and both need a main(), but you get the idea)

Here, the C++ will compile and (probably) segfault, as x is nullptr after the move. The Rust will fail at compile time, with "use of moved value."

Basically, a (possibly over-)generalization of the situation is "Rust is move by default and captures errors at compile time, C++ is not move by default and cannot statically prevent as many errors as Rust can."

Reply on news.ycombinator.com