Hacker News Reader

Comment by honest_joe | Hacker News Reader

Rust's not there yet and I wonder if it can compete. The thing is it is too specialized and low level (not that it is a bad thing for what it is intended for). The problem with all of the low-level things is that they are seriously undervalued.

I am glad that there is servo but we need something like an operating system (IoT might work for the start). I hope Samsung changes its plans with Tizen and eventually will develop something with Rust in mind.

View on HN

I have heard a couple of comments about Rust not being "there" yet. Why is it not "there" for you? Where, precisely, is "there"? I certainly hope you are not basing this opinion on a blog post from 2014 with terrible methodology (even the maintainer of the benchmarks came down to comment on how egregiously he was misusing the numbers).

Lets put it this way. Rust is great and all for somebody who is willing to invest in it but there are simply other "mature" alternatives that are just as good.

Can you describe for me the alternatives to Rust that are memory safe without mandatory garbage collection and allow safe deallocation? The only industry language I'm aware of that meets these criteria and isn't a full-fledged theorem prover is ATS, and to call it a "mature alternative that is just as good" is kind of laughable.

Rust isn't memory safe. You have to use unsafe blocks to do a lot of useful stuff.

Rust is only not memory safe in the same sense that any language with C FFI or a runtime written in C++ that isn't formally verified isn't memory safe. Which basically includes every language.

You said garbage collection. You can't make whatever data structures in Rust that you want, without unsafe blocks or garbage collection (or no deallocation).

I didn't say "you can make any data structure you want without unsafe blocks or garbage collection." I said that you can write safe Rust without mandatory garbage collection and with deallocation. You're responding to a point I didn't make.

In any case, part of the point of Rust is the ability to write safe abstractions over unsafe code. Arguing that the data structures like vectors are not memory safe is identical to the argument that other languages' runtimes are not safe.

> I didn't say "you can make any data structure you want without unsafe blocks or garbage collection."

I didn't say you said that, I gave an example of a useful thing you can't do in Rust. It is very meaningful to say that Rust isn't practically memory safe if you have to resort to unsafe code a lot of the time, or pay performance costs. I'm not talking about data structures like vectors, by the way. And it's not just data structures themselves, it's what you can do with them on the outside.

Obviously you can make pretty much whatever abstractions you want in Rust if you use some GC'd heap or allocate stuff in vectors and use indices instead of pointers. But if you're doing that, you're probably going to not be doing it for long, there's a reason you aren't using Java.

I don't disagree with you. I think Rust has a long way to go before it can practically match well-optimized C in many cases without unreasonable amounts of unsafe code (obviously, this is subjective). But it at least offers the possibility of doing so, which is much more than I can say for essentially any other language. And even in performance-critical, optimized-assembly-output code in Rust, a lot of it is safe already.

At some level you have to talk to the OS to do IO and allocate memory. ATS needs escape hatches for these just as Rust does. And in languages that don't give you escape hatches, they just drop down to C to implement their garbage collector.

Oh, my bad! I didn't know I needed to talk to the OS to make a linked list.

Yeah, you do: https://github.com/python/cpython/blob/master/Objects/listob...

You don't need unsafe code to make any data structure in Rust. Cycles can be made just fine using std::rc::Rc. The fact that it uses `unsafe` blocks under the hood doesn't mean it's not memory-safe. You seem to be vastly misinformed about what memory safety means.

Rc is garbage collection, so it doesn't qualify for "any data structures you want without unsafe blocks or garbage collection (or no deallocation)."

You can make cycles without Rc, of course.

RC without cycle collection isn't garbage collection by any definition that I'm aware of. :)

It certainly is. http://researcher.watson.ibm.com/researcher/files/us-bacon/B...

Here is a post by pcwalton on the same subject: https://news.ycombinator.com/item?id=9095314.

Indeed, I have disagreed with pcwalton in the past over the inclusion of non-cycle-collected reference counting as garbage collection, because I feel that it unnecessarily muddies the waters in a world where "garbage collection" is so often understood to be merely a shorthand for "tracing garbage collection". And intuitively to me anyway, the phrase "garbage collector" implies something that is doing the collecting! In any case, the phrase has been too thoroughly co-opted. I prefer that we think up a new term to account for non-collected reference counting, such as "dynamic lifetime management". Propose your own term, I'm not picky. :)

The number of unsafe lines of code used in Rust codebases is essentnially close to zero. unsafe is useful for library writers of very specific bit twiddling and memory management or very particular (and unsual) memory management tasks.

The number of unsafe lines doesn't even matter, because the person you're responding to fails to understand that code can be memory-safe while containing code in `unsafe` blocks.

You don't have to. Example: https://github.com/iron/iron/

And Python uses to implement its basic data structures, so does that mean Python isn't memory safe? What languages are memory safe, by your definition?

Not take this as a post against Rust, I like the language and what is trying to be achieved.

Just listing some of the issues, from my point of view, Rust currently faces.

It is not there if one is looking for uses cases where GC performance doesn't matter e.g. Haskell, OCaml, .NET, JVM. All existing alternatives enjoy more mature libraries, editors, supported OSes and so on.

It is not there if the goal is to replace C++ on the mobile platforms, as it introduces hurdles and increases the development time versus using the vendor tooling.

Specially in the iOS and Windows Phone, where C++ is a first class language. A kind of Objective-Rust, Rust/CX are needed there, even if rustc is able to cross compile.

On Mac OS X it is not there in regards to Swift tooling and available libraries, additionally for many developers ARC and GDC might just be good enough, even if Swift is less safe than Rust.

Sure, I agree with you that in many cases Rust would be inappropriate and that Rust needs to work on its C++ interop story. I just don't like it when people make sweeping claims like "Rust isn't there yet" without justification.

What makes you suspect that Swift is less safe than Rust?

Multithreading safety with GDC is not ensured as in Rust, as for the rest, I would say it is as safe as any Cedar/ML descendant.

I wouldn't be worried about Rust competing, just because HN revolves around web tech doesn't mean the rest of the world undervalues systems programming. :)

I meant financially undervalued by companies. Yes you have some players here and there but overall the market is not that big. And an investment to this area from a developer's POV is too much of a risk. Also the learning curve is too steep.

Web tech is just the simplest way to reach the end user. Mobile apps or desktop apps are becoming a hassle as well. It just takes time to "install" something and use it.

I hope thing change but I am skeptical.

I think you yourself underestimate how big the market is here. :) One of my tasks for the past few weeks has been to get in touch with companies using Rust, and whereas I expected to be talking to nothing but early-stage startups, to my surprise there are some biiiig companies out there using Rust. People in more conservative environments are only just picking it up now that 1.0 is here, expect many more announcements as to who is using Rust to emerge in the next 6 - 12 months.

Can you give more detail? Which companies and/or where are they based?

I'm not at liberty to say which companies are using Rust without asking their permission, but one enormous company that's been publicly open about their usage of Rust is Dropbox. To avoid divulging anything myself, I'll just link to what they've posted elsewhere:

https://www.reddit.com/r/programming/comments/374mre/we_just...

https://www.reddit.com/r/rust/comments/2xvtll/getting_acquai...

https://www.reddit.com/r/rust/comments/387ucr/question_are_e...

Having met them for lunch a few weeks ago, I can confirm that this project is still going strong. :)

EDIT: And if you were asking for the names of any startups using Rust, our next SF meetup has the theme "Rust in Production", with presentations by Tilde, MadeSafe, Ironworks, and Terminal.org: http://www.meetup.com/Rust-Bay-Area/events/222260315/

Well ok but Dropbox was more or less a startup in the past. Also from what i know Samsung is also invested in the Rust eco ?

Samsung does lots of Rust via Samsung OSG, but they're a secretive enough company that it's tough to get them to reveal what they're up to on the inside.

Every big data platform I know of is or already has implemented manual memory management (they all run on the JVM). I can see Rust doing well in this world. It's hard to say things like Spark are undervalued. (Two data points: ~$50M investment in Databricks, the company commercialising Spark. IBM just committed ~3.5K developers to working on Spark projects.)

Big data could be huge for Rust. I have a friend who works in the Hadoop ecosystem who's about to take a 90% pay cut to leave his current job in favor of using Rust at a startup. If I had gratuitous amounts of money, this is the field that I'd be investing in.

Shameless self-promotion for big data in Rust:

https://github.com/frankmcsherry/timely-dataflow

https://github.com/frankmcsherry/differential-dataflow

Nothing much useful to contribute, except that they mostly work, are largely unsafe-free (unsafe in some sorting, and a Drain replacement), and build on 1.0 stable.

The new Cockroachdb implementing in GOlang https://github.com/cockroachdb/cockroach

Reply on news.ycombinator.com