Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: