Hacker News Reader

That last paragraph is ridiculous. Name one feature in Rust that you think is too much complexity and I'll tell you where I need it to get my job done in Servo.

Without generics and traits, for example, there would literally be no reason for Servo to exist, because it would be too slow. Performance is not optional. Safety is not optional. They are my job. If I opposed language features that are needed for competitive performance or safety on the grounds of complexity, I would be failing to do my job.

I'm responsible for a lot of Rust's features. I have never posted on LTU, and I've never written more than 50 lines of Haskell. I find most of the Rust community's philosophical language debates tiring and pointless; languages to me are tools, not philosophies. The entire core team is largely with me here. I think you have a deep misunderstanding of the language design if you believe Rust has features "just because".

I don't read his/her criticism that way. It's that users of Rust tend to make over complex systems.

Can you provide an example of Rust users making overly-complex systems? Rust is a systems language, and systems themselves have intrinsic complexity that language designers must either choose to ignore or tackle. Scripting languages have the luxury of removing complexity by ignoring systems concerns so you don't have to care that your language is, say, copying strings around like a maniac behind your back. But somebody has to compete at the bottom of the stack, and while you can still seek ergonomic wins there's an enormous amount of essential complexity that can't be abstracted away.

Then let me be clear: contrary to the parent comment, Rust is not "for" people who do that. Rust is for people who have a job to do.

I find it counterintuitive, that generics and traits improve speed. I would enjoy a deeper explanation of that :)

Static dispatching, and all the possible optimisations from that rather than the "black box" of a dynamic dispatch (you can optimise either side of a dynamic call, but not optimise the whole thing because the compiler can't peek through the dispatch).

Note that this can have a cost in binary size as generic functions and types have to be instantiated to their actual generic parameters (that can be optimised somewhat when the parameters themselves are dynamic, IIRC while .Net uses reified generics Microsoft's implementation uses a single instantiation for all reference types)

The claim was specifically "without generics there would be no point for servo to exist, because it would be too slow". This explanation only limits what kind of generics you can use for speed, but not why generics in itself (and specifically as a language feature) are a necessity to get the job done. You could get the same performance (or better) by not writing generic code or by using code generation.

Don't get me wrong. No one doubts the usefullness of generics (not even the core authors of go. Not even Rob Pike as the biggest advocate against generics in go). Just the necessity. And in this specific case, claimed performance improvements.

> You could get the same performance (or better) by not writing generic code or by using code generation.

There are two ways to work around not having generics: use virtual dispatch/reflection (what you usually do in Go, with interfaces) or code duplication.

Virtual dispatch is a non-starter from a performance point of view, not only because of the virtual call but also because of the heap allocation that's usually required to use it. Reflection is even worse.

Manual code duplication makes it extremely annoying to write well-performing code and reduces productivity. Even worse, though, it reduces safety: lots of the generics in Rust use unsafe code under the hood. If you had to manually duplicate all the code, then the amount of unsafe code would explode. (Imagine having to write atomic reference counting from scratch for each and every type that's atomically reference counted!)

As for automatic code duplication via a code generator, that is what generics are. It's just that generics are a particularly good implementation of code duplication: they're integrated with the type system so that the compiler will automatically generate the appropriate code for you without having to go through the trouble of using a separate tool. Having to use a separate tool buys you nothing, as everyone has to learn the tool to write performance-sensitive code, and having to manually request generic instantiations instead of having the compiler do it is a huge nuisance, one that would push people toward not using generics at all and going to virtual dispatch—which brings us back to the performance problems.

Thanks for the detailed answer :) First let me say: I agree, with pretty much everything you say.

The communication issue is, that you seem to equate "generics" with how generics are implemented in rust. I don't see it that way. To me, generics are a language feature, that has multiple possible implementations, one is specialized code generation, as in rust. I think Russ Cox summarises this better than me [0].

And from that point of view, I was surprised to hear, that people thought they would improve performance. Because in my mind, they probably improve terseness and maybe improve productivity, but not performance, if you can write a generic algorithm as a template and do a search-and-replace for pretty much the same compiled result. I think, these difference in viewpoints was, what made this discussion so more lengthy than need be.

And it's important to note (I think) that no one in the world ever doubted the usefullness, of having generics as a language feature (instead of a standalone tool). When gophers say, that rust is overloaden with features, they don't mean useless features, they just mean, that there are a lot of features. Every feature in C++ is usefull. Every feature in python is usefull. But there are just so many of them, which creates a lot of cognitive overhead and always creates the impulse to contemplate "what's the most elegant way to express this", instead of just expressing it and going on to more important things (Mind you, I don't say this is a philosophy that needs to be shared by everyone, but it's the one people have, when they complain about the number of language features in e.g. rust). I think, Gustavo Niemeyer puts this very well [1].

Anyway, I hope you now understand my question better and also understand better, what the philosophy behind go's minimalism is and what people mean, when they complain about too many features :)

[0] http://research.swtch.com/generic [1] http://blog.labix.org/2012/06/26/less-is-more-and-is-not-alw...

  > you seem to equate "generics" with how generics are 
  > implemented in rust

Given that your question was specific to Servo, and given that Rust is largely motivated by Servo, it should come as no surprise that pcwalton's response was specific to the implementation of generics that makes the most sense for use cases like Servo's.

  > I was surprised to hear, that people thought they
  > would improve performance.

Making the compiler aware of generics makes it easier to collapse duplicate implementations, which can have a cascading effect on reducing binary size and thereby reducing icache pressure.

It's all about specializing code to a certain type at compile time and therefore removing any kind dynamic dispatch during runtime.

  > Rust is for people who debate language semantics on 
  > Lambda the Ultimate and program in Haskell for fun. Go 
  > is for people who have a job to do.

This is a mischaracterization of Rust to the point of incredulity. I've been talking to companies experimenting with Rust and all the engineers I've spoken to have praised Rust for its ability to let them do their jobs with confidence. These engineers are in domains where GC is intolerable and C++ is considered too much of a risk (in fact, one of my biggest surprises in this current endeavor is discovering how few people in industry will describe themselves as comfortable with C++ to the point of being willing to use it in greenfield projects with confidence). Without Rust, these companies would be forced to buy more hardware to throw hardware at the problem or hire C++ specialists to throw at the problem; fortunately Rust threads the needle and provides extreme business value.

Rust was created to solve a specific pain point. It's not some language that sprang fully-formed and perfectly-designed out of the ether. It solves problems that no other language even attempts to solve (no, Ada doesn't do what Rust does (and likewise, Rust doesn't do what Ada does)), and the mechanisms that it uses to do that took years of iteration and concerted effort on large codebases.

Not everyone needs to be working at the level that Rust does, and I think that's great. I'm a polyglot programmer myself, and I like Rust because at last there exists a language that lets me perform at the level of C with the same level of memory correctness that I expect from Python (or really, any language designed post-1995).

I never heard that phrase "thread the needle" before that's good

I brought Rust into my job for some non-essential stuff and so far it obliterated my usual tools (Scala, Python to be more specific) in shear speed and low memory consumption. I've written no more than a thousand LOC of it and most of it is still clumsy bearing it mind the fact that I'm new to it, but the potential that it has cannot be denied. To me it's a missing link I was waiting for - a low level language that feels like a high level one.

I'm currently reaching out to people using Rust for their jobs so that we can establish a more formal relationship with corporate users, and I'd love to hear more about your use cases. :) My email is on my profile page here.

> shear speed

Do you write tools for a woollens manufacturer?

> C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.")

Which is why Java gets used instead.

In some situations, yes. But Java can suffer from similar complexity and maintainability issues too.

Go, for all it's short comings and missing features, is closer to the "instant gratification" state that Python and it's ilk enjoy while having performance closer to that of Java.

I'm not trying to say one language is better or worse than the other though. Just my observations as to why Go is gaining popularity.

I think its a bit premature to predict critical mass for Go and maybe your python comparison is a reasonable prediction of where Go will finish up.

> I think its a bit premature to predict critical mass for Go

If Go was only used by it's sponsoring company and a few "language-whores" on non-critical systems, then I might have agreed with you. But in spite of Go being one of the "new kids on the block", there are already quite a few sizeable projects and organisations outside of Google who are using Go for fundamental parts of their software stack (eg Cloudflare, Canonical and Docker).

So like or loathe the language, I'd argue that it's already reached critical mass.

How does go prevent complexity?

Mostly by making abstractions harder. By making it pointless to think about "what is the best type-hierarchy for this software" or "what is the most general way this problem can be formulated and solved", it forces you to focus and solve the problem at hand, which leads to more straightforward and easier to understand code.

Most people I've seen, that are frustrated with go, are people who want to have an impact on the community by writing a package that a) solves a simple-ish problem with the simplest API possible (e.g. "password-hashing libraries") or b) solves a complicated-ish problem in the most general way possible (e.g. "generic containers" or "graph algorithms"). As go makes both of these very hard, these kinds of people get frustrated with it.

go generally agrees with people who want to solve complicated specific problems, e.g. "I want to find all dead links on a website", because it gives you a relatively straight way from A to B.

Is there any detailed article on this topic that you know of?

The canonical answer is [0], though unfortunately, that's not very good to illustrate this specific point :) I came to this conclusion from reading the golang-{nuts,dev} mailing lists and whan pops up in the community. The usual answer to a proposal of a new language feature (most famously some form of generics) is "what real-world problem is this trying to solve and maybe we can solve it in other ways". And "real-world" always means "real-world", i.e. code that is currently running in some real project out there. And the answer of the people propositioning is almost always something in the neighborhood of "I want to write a foo-library, that makes bar simpler".

I remember reading an article a while back by someone explaining exactly that very well, but I can't seem to find it…

[0] https://talks.golang.org/2012/splash.article

I'm not sure it does. On the one hand Go generally requires less boilerplate code than Java does. But that's only if you're writing simple models; once you factor in stuff like generics you can quickly find the simple becomes unnecessarily complex within Go.

Like with most things, it really depends on what problems you're specifically trying to solve.

Often Java is too slow too. (Slow == overhead from GC of unwanted object metadata and heap allocated objects)

In those Techempower benchmarks Java destroyed Go for web app style requests.

And given that the JVM is so dominant in big data (e.g. Spark, Storm), online betting and applications like high frequency trading you could make the reasonable assumption that Java is anything but slow.

Go has a gc. That doesn't seem to be the problem. Google also uses Java quite often.

> program in Haskell for fun.

What about the people who program in Haskell for work?

> Go is for people who have a job to do.

People use Go for fun.

Does Google use Go in any high-load services?

download.google.com is completely powered by Go at this point, iirc.

Indeed: https://talks.golang.org/2013/oscon-dl.slide

Vitess (https://github.com/youtube/vitess) scales mysql for youtube level of usage.

> Rust is for people who debate language semantics on Lambda the Ultimate and program in Haskell for fun.

Very smooth. /s

> Other than that, there are few killer problems with the language when doing server-side stuff.

Which ones?