Hacker News Reader

Comment by thewhitetulip | Hacker News Reader

I never got around to use Rust, maybe I'll get some good answers here on HN, how does Rust compare with Go/Python/Java?

They aren't really comparable. Rust is a lower level language that primarily competes with C++ (finally! C++ badly needs the competition). C++ is still around because it is one of the few languages that has a pay-as-you-go model to features and is not GCd, so, you can reasonably do things like write embedded software for micro-controllers, or kernels, etc.

Go, Python and Java (or any JVM language) are all high level garbage collected languages that focus on developer productivity. You pay certain costs just as the price of entry, like garbage collection, and the requirement for a fairly hefty runtime. In return you get various useful features.

Examples:

You would not use Rust to write a large complex webapp as part of a corporate team, that spends most of its time talking to databases or message queues. The best tool for this from your list would be Java.

You would not use Rust to write a small script to do system administration tasks or quickly prototyping a new idea. The best tool for this from your list would be Python.

You would not use Rust to write a small, simple command line tool that nonetheless could benefit from being garbage collected. You could use Go for that (I hesitate to say it's the best tool but plenty of people use it in that way).

Yup. Think of Go as a compiled Python/Ruby/etc.-family language; think of Rust as a fixed C++ with some influence from functional programming.

Possibly some of the reason people think they're similar is that Google's internal use case for C++, as I understand it, involves writing things like HTTP API servers in it—things that the rest of us would write in Python/Ruby/etc., or Java. And they do things like statically link the resulting binaries and deploy them in containers. So Go is replacing C++ at Google, but that doesn't have a huge overlap with what the rest of us would consider C++ for. Rust is more suited than Go for many of those use cases (embedded software, kernels, ABI-compatible replacements for things in existing operating systems, etc.).

The other reason is that Rust 0.x once had features that were pretty similar to goroutines, a garbage collector, etc. Those were all removed before 1.0, but the impression still lingers.

Actually, once the ecosystem is fully there (probably ~6 months to a year), Rust would make a great contender for a complex, large web app. The type system Rust uses alone is worth it...

And if it ever gets Higher-Kinded Types worked out... I'll have to get a drool cup.

I'd just note that Rust isn't that hard to use for higher-level stuff. I am working on a network search engine (capture all traffic, index, search). At first I though I'd just write the capture agents in Rust, maybe some of the PCAP-storage stuff. Then write the entire query engine in F#. More and more, I'm realising I can write a much larger portion in Rust, and leave F# for the parts where performance totally doesn't matter (mainly interfacing with the end-user). It's pretty amazing.

I have found that using Go for system administration tasks could be more productive than Python. Go static types help to discover typos quicker and even with Go 1.5 small programs compiles and start faster than Python starts a script doing the same.

Python just standardized a good bit of static typing! I haven't gotten around to playing with it though.

I'm curious as to what makes you think that Java is preferable to Go for a large webapp that "spends most of its time talking to databases or message queues".

I would have thought that the Go's concurrency model would give it an edge.

> I'm curious as to what makes you think that Java is preferable to Go for a large webapp that

because your large webapp is made by a large team, over a large time span. The same as you don't deploy on power8 but on x86, because x86 is more common than power8 and cheaper.

One of your java programmers leave ? replace him is easy Need to find java programmers ready to do shitty and boring debugging ? easy Your large webapp is in maintenance mode and nobody internally wants to touch it, so you decide to find a cheap company abroad to outsource the maintenance ? easy

Hard to find these three with Go (or rust, and I love both) because right now it's taught in no large scale university nor a lot of people have been exposed "accidentaly" by it. SO if you have been exposed to Go (or rust) and decide to stik with it it's because you actively decide to, not just because of market force. Hence so you don't belongs to those who will want to do shitty bug fixing 8 hours ago, nor to the price of a developer people hire just to have two more hands, nor the kind who will accept a job under-payed for a outsourcing company.

Java, permits your management to feel they can scale the development

Not that this invalidates your point, but there are two university classes being taught in Rust right now; I had the pleasure of guest lecturing at Penn's yesterday, in fact. Here's hoping to more of those in the future.

I certainly agree this is a big plus for Java.

ah great to know ! I also hope to see more in the future.

here I was playing the devil's advocate, but to have been at both seat (having hard time to hire as a CTO and needing to fallback on PHP in one company / trying to push Rust in my current one) I now see why chosing a stack is not only about tehcnical merits.

I think the key word is "shitty". If you're working on a shitty app then aim for shitty languages with developers that don't care.

Hopefully we aim to not work on such shitty apps. And in such a case, the overhead of learning a new language is dwarfed by the overhead of learning the domain-specific stuff.

And Rust, like any good language seems to have a, coherent(?), or elegant design. Stuff makes sense. As compared to some languages where things are just thrown in willy-nilly. This makes Rust easier to learn, as you can somewhat reason about how things must work.

last time i tried to do serious work with go and mssql, i ran away screaming. maybe situation isn't that dire now (this was almost a couple of years ago), but it's hard to beat java in db connectivity.

for the record, i ran to python.

I've used Go in a lot of database work as of late, and it's done a fine job for me. I've used it to connect to MS SQL, PostgreSQL, and Teradata. The Teradata connection was a little tricky, as nobody had written a Go/Teradata driver yet and I had to route it through Windows ODBC, but once I had that sorted out it worked just fine.

I only started using Go in the last couple of years, so I don't know how different it is now from when you tried it last, but I bet you would be pleasantly surprised if you gave it another look.

Java has support for Go-like concurrency and much more in java.lang.concurrency packages.

The only difference is lack of special syntax and being harder to use for basic blog post examples.

Usually people that compare parallel programming in C++, Java or .NET vs Go, never went beyond the basic thread features.

Here's my perception of Rust: It is a system's low level language (more like C or C++) that is very expressive. It's performance is compared to C++, so faster than Go/Python/Java.

----------------------------------------

In term of expressiveness, it offers:

- Expression-based languages (instead of statement-based)

- Has anonymous functions (lambdas)

- It has a match mechanism which is powerful

- Enums are enumerated data-types rather then integer types

- Has traits and explicit implementation blocks for them (vs Go's implicit interface contracts)

----------------------------------------

Other than that, it also offers:

- Built-in concurrency

- It has a thing called the borrow checker that makes sure you're handling memory safely (this will get a little but of getting used to, but it is powerful)

- Everything is private by default. You put `pub` in front of an identifier if you want it to be public

- It isn't very verbose in the Java sense, but you still have to write a crap lot of code in comparison to Go and Python. The trade off is that the code is very explicit, and you get to type more in order to have zero cost abstractions at runtime

- Zero cost abstraction at runtime

Please correct me if any of those points are wrong/misleading, I'd love to learn more about Rust too.

> - Built-in concurrency

This is a bit misleading, rust does not come with concurrency out of the box. The compiler is able to infer some basic properties of your program to ensure that it is 'concurrency safe'[1] any additional concurrency features are offered through libraries that mostly wrap C libraries. The std lib only comes with system threads, and some basic primitives like mutexes and channels. However, because of these features its fairly easy to build libraries that offer concurrency primitives. For example, `mio`[2] can be used for async socket programming, `rayon`[3] can be used for some parallel computation.

[1] http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht... [2] https://crates.io/crates/mio [3] https://crates.io/crates/rayon

Thanks for the explanation.

Would you please clarify something to me?

1. So to say that a language has concurrency built-in is, in general, misleading, correct?

2. Than a language may have concurrency primitives, but the capability comes from C through the OS?

It's more like "We designed the type system to take concurrency into account, and then provided various types ourselves in the standard library (like Send/Sync) to be used with them. We also provide a bunch of concurrency abstractions and tools, in the standard library, but due to the guarantees being more in the type system, others can also write their own. Some of these do rely on OS-level capabilities as well.

In general, very little of Rust is technically "in the language", but to the user, something in the standard library vs the language itself often doesn't matter, it's the same experience either way.

That's very insightful. So my understanding now it that Rust provides low level "blocks" that, as a whole, is an extensible language. Thus language vs standard library doesn't really matter, since Rust = Language spec + standard library. Am I getting close to its definition?

BTW, I remember in the alpha days when the decision was made to make Rust support concurrency in the standard library rather in the language itself. So in that sense (Rust = language spec + stdlib) Rust does have concurrency built-in.

Well, using Rust without the standard library is a big use-case: stuff like device drivers, OSes, embedded, things like that. So to some users, it matters. But there's little use overly qualifying what you're talking about when you're just talking, so someone might say "Rust" to mean "Rust + std + crates.io crates" or "Just the language, no standard library", based on context. But once you get into the details, it's important to get at exactly what you mean.

> So to say that a language has concurrency built-in is, in general, misleading, correct?

Languages with keywords like `volatile` and `synchronized` have concurrency built in to some degree. Similarly, languages where the concurrency/parallelism system cannot be implemented as a library (e.g. Go) have it built in. So, languages can have concurrency[1] built in; Rust doesn't.

You can duplicate Rust's core concurrency abstractions and safety requirements almost exactly in a library. Rust offers lower-level building blocks as part of the language which can be composed to provide safety from data races.

The only time Rust's stdlib concurrency system factors in to the language is in the behavior of `static mut` (it requires `Sync` types), which is a pretty niche feature and not strictly necessary for safety given that `static mut` is `unsafe` to access.

[1]: Also, "concurrency" is the wrong term to use here, too, but that's a nitpick within a nitpick

  > keywords like `volatile`

Obligatory link: https://software.intel.com/en-us/blogs/2007/11/30/volatile-a...

That blog post is about C's `volatile`. Java's `volatile` is for concurrency (also its `synchronized`)

After using rust a bit I would say that unless you requirements dictate being very frugal around things like memory allocation and speed etc.. I would not use rust to write said application.

As other people have posted it seems to compete with C/C++. I am really excited about this since I think there are a lot of problems with C++ we just don't see them because there is no competitor.

For example in C++ reflection and interfacing to other higher level languages is awful. I am hopefully with rust we can do better! That might really open up rust a lot of uses for rust as a language.

Another area where rust is different from python and java: the rust crates in the wild still seem like a wild west of 0.x version packages that break frequently (at least for games programming). It is a great opportunity to contribute to OSS but can also be frustrating.

My recommendation: if you have a pet project unix daemon or CLI tool you wanted to make try it with rust. Most of the rust standard library seems to have stabilized and is nice to use now. For complicated applications be prepared to contribute upstream fixes to crates and bring lots of patience :)

Things that I really like:

-No GC, purely RAII based resource management.

-Awesome ownership with first-class support for move semantics.

-Great functional constructs(Sum Types, Pattern Matching and map()/filter()/etc).

-Compiles down to native code via LLVM.

Nitpick: GC is technically optional in Rust, because you can stick pretty much anything in a reference-counted box or an atomically-reference-counted box (Rc<T> or Arc<T>). It's not the default by any means though.

One day a student came to Moon and said: “I understand how to make a better garbage collector. We must keep a reference count of the pointers to each cons.”

Moon patiently told the student the following story:

    “One day a student came to Moon and said: ‘I understand how to make a better garbage collector...

Nitpick: Rust includes a GC. Box<T> is reference counted, although the reference count is always 1 until it is released by the owner, then it reaches 0. The reference counts are inferred statically for the most part.

:-P

Always inferred statically for box.

No, if you conditionally move a box, there needs to be runtime checks for whether that condition occured when in it goes out of scope. (note that reassignment of a variable effectively causes the old value to go out of scope -- this may have Implications for your loops, though I sure hope you aren't making and destroying boxes in a loop!)

In my experience, this is not however a significant concern.

Ooops yeah forgot about https://github.com/rust-lang/rfcs/blob/master/text/0320-nonz.... [To be perfectly pendantic, one could trade the drop flags for code bloat and have only a finite blow up and statically known everywhere, so its a "weak" form of dynamism.]

Yeah I guess you could have exponentially many statically compiled paths for each combination of drop flags... but then you're just encoding your drop flags in the instruction pointer :)

edit: this of course implies an easy program with 65 conditionally moved boxes that can't be encoded under your system.

It's all true.

Someday, long from now, I'd like to do a crater run with eager drop and see if anything actually breaks.

CStrings and drop guards everywhere break

Sure, much like C/C++ could have GC by embedding Lua, Spidermonkey, etc(fun fact Epic implemented their own C++ based GC for Unreal3).

It's not a forced requirement :).

Hell,

> GC is technically optional in C++, because you can stick pretty much anything in a reference-counted pointer (shared_ptr<T>).

week_ptr<T> - keeps a pointer for a week.

I really wish calendar-oriented programming had taken better hold in the 80's. It's a really elegant paradigm with great separation of concerns. Being able to shard data out into timezones with inter-timezone accesses requiring a delay equal to their clock differences completely eliminates races!

Unfortunately it was pushed out by MIT's cartography-oriented zealots, and we know how well that paradigm worked out!

I am unironically into both of these ideas.

Since C++11, C++ has a standard API for GC integration.

Or use https://github.com/manishearth/rust-gc, https://github.com/fitzgen/rajan-bacon-cc

Or Spidermonkey's GC, correct? My point was more about RAII not being the only resource management strategy.

Yeah, Servo uses SM's GC for its javascripty things, it sort of has to. Hooking into spidermonkey to get a GC for a program where you just want a GC and not Javascript is suboptimal though.

(Note that all of these GCs use RAII under the hood, but not in the simple delete-when-destructor way)

Rust is an entirely different paradigm than Go, Python or Java... It's sort of like C++ meets modern functional lanauges like Scala.

That's a very broad question. Rust does the things that I would say are table stakes for a decent programming language these days: decent type system (similar safety to Java) with type inference (similar conciseness to Python), a sensible approach to errors (errors are values as in Go, but since Rust is a non-joke language it doesn't need to special-case errors at the language level, they're just another type of value). Its unique thing is the semi-manual (but safe) memory management, but if you needed that then you would know you needed that, otherwise it's not terribly important to you.

So it's a decent language, but there are other decent languages around these days. I tried to compare them at http://m50d.github.io/2015/09/28/when-rust-makes-sense.html . I'd look at OCaml first, particularly given their relative maturity levels, but if you really can't stand OCaml's syntax then Rust may be worth a look.

> it doesn't need to special-case errors at the language level

Could you explain this? A lack of explanation makes it seem flippant and is probably why your comment is greyed out.

Rust error-handling https://doc.rust-lang.org/book/error-handling.html - Result is just an ordinary type defined in the language. Whereas go's "if err, res" stuff is special-cased - e.g. you can't use your own custom representation of error vs not.

Tutorial's pretty quick and gets you a good idea of what they're shooting for. https://doc.rust-lang.org/book/README.html

Reply on news.ycombinator.com