Hacker News Reader

Comment by pdq | Hacker News Reader

The quickest comparison I'd say between choosing Rust and Go is:

- if you like C or Python, you will probably prefer Go

- if you like C++ with templates or D or Ruby (especially Rails), you will probably prefer Rust

We will see how the languages evolve, but so far I really enjoy Go having native channels, having a stable language definition, and a simple yet stable and powerful standard language API. Also the public/private access system based on capitalization is genius, and the package management is very intuitive.

View on HN

If you "like C", then Go is a really poor substitute, because Go doesn't allow one to juggle with memory like what people are normally doing in C. Rust is not comparable with Go, because Go relies on a non-optional GC, a difference that changes everything, Go being in the same league as the JVM, except that the JVM is better at almost everything, like garbage collectors, tools and libraries available, multiple languages etc. The JVM is even better at concurrency.

Go in my opinion is the best proof that our industry is fashion driven.

>Go in my opinion is the best proof that our industry is fashion driven.

It's not though. What is fashionable about Go? Most testimonies I've seen state solid reasons for choosing it. Nobody claims it to be a marvelous language like Haskell. It's a simple language that's easy to pick up, implement an idea, and deploy. Much like python, but with much greater performance.

I don't see what fashion has to do with it.

OCaml offered the same proposition for 10+ years. No-one was interested. Oddly enough, now that Go and Rust are getting attention, people seem to also be taking a second look at OCaml. What's that, if not fashion?

While Ocaml is a really nice language it doesn't have a runtime well suited for fine grained concurrency or multi processors, at least at the moment. If you compare standard libraries, commercially backed languages have also far more of the tedious groundwork for "real world" applications done for you. Of course depending on your project this might be relevant or not.

Ada & Rust show the same thing: the computer world is a fashion industry..

"OCaml offered the same proposition for 10+ years."

No, it didn't. In addition to the already-observed point that Go's concurrency story has always been better than OCaml's, Go also offers it to you in an Algol-esque syntax. It isn't C, but if you know C the differences are dialectal, whereas OCaml is from the ML tradition and is radically different. ML is the language family probably most distant from C in current medium-scale usage.

I don't like or celebrate this fact, but it seems that broad-scale success right now requires that you be an Algol-descended syntax.

Allow me to summarize your post as "OCaml syntax is not and never was fashionable", thus proving the OP's point :)

You can still "like C" without needing to juggle memory (similarly, you can need to juggle memory and hate C). The core Go team is likely evidence of that: they created a language that, in some sense, retains the spirit of C and yet they felt that manual memory management was unnecessary for the problems they're now solving.

> Go in my opinion is the best proof that our industry is fashion driven.

Go itself isn't flashy or trendy or fashionable. It doesn't introduce exciting new concepts. It's as notable for what it doesn't include as what it does include. It is, in my experience, an extremely practical and pragmatic language. Saying it's proof of a fashion-driven industry is like saying the Honda Accord is proof that the automobile industry is fashion driven.

I believe some of the initial interest in Go was due to its newness and its affiliation with Google. But traffic-baiting bloggers have moved on to the next thing, as have programmers who are more focused on the process of programming (i.e., "I want the act of programming to be fun") than the results. I think it's settling into a comfortable role as a practical choice for teams who want to get work done.

and ruby/rails didn't prove this? with all those mustachio'd hipsters?

I don't see how affinity for Python on one hand or Ruby on the other would make you prefer (a) channels hardwired into the language (which neither Python, Ruby, nor Rust have); (b) a batteries-included standard library (Python and Ruby are pretty batteries included; Rust is not as much); (c) public/private based on capitalization (which neither Python, Ruby, nor Rust have); or (d) Go's package management system (Python's, Ruby's, and Rust's are fairly similar, while Go does something different).

Not the OP, but I suspect he's making this categorization based on fundamental philosophical principals of the language. Python and C are "New Jersey School" languages. C++, D, and Ruby are "MIT school" languages. (For references, Google [worse is better].) The OP is saying that Go is firmly in the New Jersey School (understandable, since the developers worked at Bell Labs on C and UNIX), and I assume that Rust is in the MIT school. I haven't written enough Rust to have an informed opinion, but a quick read of the Rust tutorial makes me think the OP's assessment is correct.

The fundamental difference between the two schools is in how they view corner cases. The New Jersey schools suggests punting entirely on corner cases to keep the design simple; the complexity is either offloaded to the developer, or the language designer says that the language is simply not suited for that problem domain. So you have the Go devs saying that you just don't need generics or Guido van Rossum saying you don't need execution speed. The MIT school says "We should solve the problem and make things easy for the programmer, goshdarnit", and so you get things like the STL (where every algorithm is built for maximum generality at no performance cost) or Rails's auto-pluralization of database tables. Or another way to look at it is that the New Jersey school asks "Why?", while the MIT school asks "Why not?"

You can extend the analogy out to other languages: C, C++, Java, Python (borderline), Objective-C, Go, PHP, Javascript, and Perl are New Jersey school languages, while Scheme, Common Lisp, C#, Ruby, Dylan, Erlang, and Haskell are MIT school languages. Note that they very often occur in pairs (C <=> Scheme, C++ <=> Common Lisp, Java <=> C#, Python <=> Ruby, Objective-C <=> Dylan) with a similar purpose and timing in the market, but generally the New Jersey school language does better commercially. It is not universal, though - Python and Ruby are both commercially successful but in slightly different niches, as are Java and C#. Usually when the MIT-school language is successful, it's because they manage to differentiate themselves with a strong killer app or framework (eg. Rails for Ruby, .NET for C#).

In the first paragraph you characterize C++ as "MIT School", and in the last paragraph you characterize it as "New Jersey School".

I'd revised the post several times before posting it; initially I wanted to label the categories as "OAOOW" (One and Only One Obvious Way) vs. "TMTOWTDI" (There's More than One Way To Do It), then I figured that using the labels from "Worse is Better" more accurately captured the intent of the grandparent post, then I went back and re-read "Worse is Better" again to make sure I had a fair characterization of Dick Gabriel's argument. In the process C++ switched categories, but I forgot to update the first mention.

...now that I'm rereading it again, I wonder if my original phrasing was better. The idea that I want to capture is that there's a difference in how these languages approach corner cases: the C/Python approach is to punt and say "We're not designed for that", while the C++/D/Ruby approach is to add a feature to the language to solve that one case. C++ is basically what happens when you extend a New Jersey school language to cover the corner cases that it originally chose to ignore; that doesn't actually make it MIT school (which is more a philosophy on how to design systems, not how they end up), but it does put it in a different category from C and Python.

(Disclaimer: this is merely nitpicking, I get the gist of your original post).

I think your split of "Worse is Better"/"Better is Better" languages is a bit arbitrary. Everyone agrees that C is a Worse is Better language, but the rest? In particular, I cannot decide whether you equate OAOOW with Worse is Better or not -- Python is OAOOW, but I wouldn't say it's a Worse is Better language (and claiming it is because "you don't need speed" is like saying Haskell is a Worse is Better language because "you don't need the ability to easily reason about runtime performance". Every language claims "you don't need X"; that's clearly not enough to classify it as WiB).

I don't get what you mean by "Worse is Better" while I understand "One and Only One Obvious Way". The old phrasing is, IMO, better.

"Worse is Better" is in reference to a fairly famous essay describing the dynamics of language & system software adoption:

https://www.dreamsongs.com/WorseIsBetter.html

http://www.jwz.org/doc/worse-is-better.html

http://en.wikipedia.org/wiki/Worse_is_better

Great posts. I'd like to add that 'OWLs' (one way languages) and 'MTOWLs' (more than one way languages) made the most sense to me. WiB and BiB makes sense too, because I knew what you were getting at. Having used many programming languages I've settled on 'WiB' languages as my preference. Though I consider WiB to actually just be better. :D

Complexity creeps in too quickly and too easily. While I don't like the WiB moniker, I definitely prefer OWLs. :)

I don't see Python vs. Ruby specifically as worse-is-better versus better-is-better though. If anything, Ruby is a worse-is-better Smalltalk, while Python gained a lot of its initial community from its perception as a better-is-better Perl (based on popular articles by ESR, etc. at the time). Dynamic features like automatic pluralization of tables in Rails isn't "better is better"—it's just highly dynamic (or "magic"), and many people think of magic as a worse-is-better thing to do (for example, many functional programmers would consider any sort of reflection to be a worse-is-better feature, since it breaks parametricity and so forth).

I also don't think it's right to think of Rust as a better-is-better language in philosophy. Many folks coming from languages like Haskell find Rust full of design choices that seem at odds with its "functional programming" reputation: lack of higher-kinded type parameters, for example, lack of an IO monad (or the use of the term "monad" at all), a willingness to have subtyping in the language, heavy use of macros, etc. etc. The reason is that we actually have a heavy bias toward pragmatism and simplicity wherever possible.

It's our constraints that required the language to have the concepts that it does (performance-competitive with C++; no global garbage collection; data-race free; runtimeless/embeddable). We simply couldn't have copied another language and said "here's our language, now let's write a browser engine in it". It would not have the performance characteristics or the safety characteristics we need. It's not a difference in philosophy so much as in requirements.

I think the point may be that once you embrace those constraints, there's nowhere to go but a language with a fair bit of complexity. While Go chose simply to not embrace those constraints, and tell developers "You don't actually need C++ performance, and you really want a GC, and you should ditch Python entirely instead of trying to embed Go in it." Perhaps this is why Go found that their userbase didn't actually consist of the expected C++ developers and instead ended up being mostly ex-Pythonistas who are willing to ditch Python entirely for better performance.

FWIW, I'm glad that Rust didn't choose that path, as I've tried Go out and found that it really didn't work for me as a Python substitute, and am now dreading the day when I (hopefully) will have to rewrite parts of my startup in C++ for performance. I'm actually seriously considering Rust as a substitute here, but would like to see more stability in the core language before investing serious time learning it.

But I'm also someone who has never shied away from complexity in a language before, which probably puts me more in the "likes C++, Ruby, and D" camp even though I chose Python as my main scripting language. One of my main concerns with Rust is whether it will be possible to hire & manage developers who can work effectively in it, since I know that not everyone is as willing to learn new languages and language features as I am.

I actually think it will be easier to find folks willing to dive into Rust than folks willing to dive into C++. The reduction in complexity, corner cases, and memory safety have all allowed many developers with a background in dynamic languages to feel comfortable approaching Rust.

> The reason is that we actually have a heavy bias toward pragmatism and simplicity wherever possible.

And functional programming languages are just arbitrarily complex and obtuse because it hates its users? No, it simply has different constraints, like the following...

> It's our constraints that required the language to have the concepts that it does

And it's Haskell's constraints that lead to it having to be a pure language, and so on. Rust is just opinionated in a different way, and because of different constraints. Do you want functional programming in Rust? - it's probably not going to be as accommodating in that regard as a functional language. Do you want to have zero-cost abstractions in Haskell? - the language is not made with that in mind, so you will probably have to wrestle a lot with extensions and custom abstractions in order to achieve that, if it is even possible.

I would actually consider Rust's philosophy to be 'better is better', at least within the core ideas: no nullable values, borrow checking, trait oriented work. Although, perhaps, that was how it started and not how it's being released?

>C++, D, and Ruby are "MIT school" languages.

What are you basing that on? C++ is a "lets add everything and let the user sort it out" language, how is that in line with the principles of the "MIT school"? Ruby is literally perl--, how is that MIT school? Because rails does incredibly dumb stuff like incorrectly pluralizing table names by default? That's not MIT school, it is just dumb.

>and I assume that Rust is in the MIT school.

I can't imagine any way to rationalize that idea. Rust is at its core all about trade-offs and "good enough"s. It is supposed to be a better systems language, not an ideal language. I can see claiming scheme, or SML or haskell or clean are "MIT school". Basically any language people spread FUD about being "not practical". But rust is explicitly intended to appeal to the people who pretend good languages are not practical.

Can you elaborate on why you group Rust and Ruby together, and group Go with Python?

I would like to know that as well. The strictness and cleanliness of Rust reminds me more of Python than of Ruby. Not to say that Go is messy or anything, Ruby on the other hand...

What if you like js?

Go will be a shorter journey from JS. Rust may someday be a better complement, partially for the exact same reason that it's more distant from JS, but Go's 1.0+ today and production ready, whereas Rust is still a ways away from that, so consider your target timescales, too.

Then i'm afraid none will suit your taste. Go has hiddeous variable initialization ( make just for two types, and no unique syntax for initializing struct in general), and basic structure manipulation ( i still have to look the doc whenever i want to do anything with an array, or anything non trivial with a dictionary), and from what i've read rust will drive you mad with lifetime scopes.

These "if you like Foo you will like Bar" claims are really silly. I've never seen one that was accurate at all, and I don't think they can be. Different people like the same things for different reasons. For example, I like C and despise go, and I despise C++ and ruby, and like rust.

Reply on news.ycombinator.com