Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

251–260 of 474 posts

Re: Rust is mostly safety

#251
post #155

Earlier quoted context omitted.

> Many would love a better language. Matter of fact, they tell us in Rust threads here. Absolutely, but my emphasis was on the difference between "love" or "want", and "need". Switching a programming language is extremely expensive, doubly so in systems programming. Organizations won't pay the price for something that doesn't make a big impact. Unlike many other new languages, Rust does have the potential to make a b…

"I don't think max performance is an issue at all" I'll consider believing that when you remove both the performance-enhancing aspects and their marketing from your company's products that appear to target enterprise space of people using GC's and concurrency. Rust's safety w/out performance hit affects those two, specific areas. I think they might be interested. Not to mention businesses doing analysis they want to…

> Rust's safety w/out performance hit affects those two, specific areas. I think they might be interested.

:) Let me put it this way: if for some reason Rust ever takes a serious market share from Java (or other similar languages) in the enterprise space, I will surely be well into my retirement by then, so my interest isn't financial. I was a C++ developer for many years, working on very large soft (and some hard) realtime systems, and I was a Java holdout, but once most of the defense industry switched, virtually nobody (including us) ever complained about a performance decrease. So even if the claim that GCs adversely affect performance in large, complex programs (where RAM overhead isn't an issue) were true, the number of organizations that build software of that kind and where this performance would matter more than in defense, is very, very small (not to mention that most of the current performance deficiencies in Java are not related to GC). If that's the kind of user that would be a significant portion of Rust's userbase, then Rust is in trouble. Companies that sell ultra-low latency GCs for a fraction of the cost it would take for enterprise shops to adopt a language like Rust, are, well not exactly on their way to the Fortune 500. The systems software space -- drivers, kernels, filesystems, and the entire embedded space -- is at least one, if not two, orders of magnitude bigger.

Re: Rust is mostly safety

#252
If you're a C++ programmer, Rust is mostly about memory safety.

If you're a Java programmer, Rust is mostly about tighter resource usage.

If you're a Python programmer, Rust is mostly about type safety and speed.

Re: Rust is mostly safety

#253
post #226

Earlier quoted context omitted.

Maybe it will change in future. Currently slaps seems so hard that developers are still smarting and not producing code for production

Rust is being used in a number of places in production for a wide variety of things: https://www.rust-lang.org/en-US/friends.html

I know and I would also try Rust if I can make some small but useful things at work. But I mostly deal with various combinations of XML, SOAP, HTTP, LDAP etc. Rust does not have anything over Java, which I use currently, in my usecases.

Re: Rust is mostly safety

#254
post #226

Earlier quoted context omitted.

Maybe it will change in future. Currently slaps seems so hard that developers are still smarting and not producing code for production

Rust is being used in a number of places in production for a wide variety of things: https://www.rust-lang.org/en-US/friends.html

[deleted]

Re: Rust is mostly safety

#255
> "Safety in the systems space is Rust's raison d'être."

I think this quote points to the REAL underlying issue here.

Rust is a language primarily built for systems programming. It has many strengths to celebrate, and brings curated best practices as well as its own novel features to systems programming.

However, most programmers in 2016 aren't "systems programmers" anymore. At the very least, most programmers who actively talk-up new technologies on web forums are not systems programmers. The majority (or at least the majority of the vocal and socially engaged) are web developers, mobile developers, CRUD apps and microservices, etc.

As interesting as Rust may be in the systems space, it doesn't bring much compelling new hype to the table for web stuff.

You have yet-another-concurrency-approach? That's great, but most web developers rely on an app server or low-level library for that, and seldom have to think about concurrency up at the level of their own code.

You have an approach for memory safety without a garbage collector? That's great, but most web developers have never even had to think much about garbage collection. Java, Go, etc... the garbage collection performance of all these languages is on a level that makes this a moot point 99.999% of the time.

You have a seamless FFI for integrating with C code? That's great, but after 20 years of web development I can count on one hand the number of times I've seen a project do this. And those examples were Perl-based CGI apps way back in the day.

Rust people seem almost dumbfounded that everyone hasn't jumped all over their language yet. And from a systems programmer perspective, memory safety without garbage collection does sound amazing. But you guys really need to understand that Hacker News and Reddit hype is driven by web developers, and that community isn't even sure whether or not type safety is a worthwhile feature! So really, it's amazing that you've managed to draw as much hype as you have. It's not about the mainstream popularity of your language, it's about the mainstream popularity of your field.

Re: Rust is mostly safety

#256
post #226

Earlier quoted context omitted.

Maybe it will change in future. Currently slaps seems so hard that developers are still smarting and not producing code for production

Rust is being used in a number of places in production for a wide variety of things: https://www.rust-lang.org/en-US/friends.html

[deleted]

Re: Rust is mostly safety

#257

I'll probably be writing a slightly longer response post to this later, but for now... EDIT: here it is: http://words.steveklabnik.com/fire-mario-not-fire-flowers I think the core of it is this: > Safety in the systems space is Rust's raison d'être. Especially safe concurrency (or as Aaron put it, fearless concurrency). I do not know how else to put it. But you just did! That is, I think "fearless concurrency" is a b…

I would argue that if the Rust project would have just one mission statement, it wouldn't be "create a safe systems programming language". It would be "move towards a world where safe systems programming is the norm". What's the difference? Both of the statements have the premise that Rust is – and ought to be – a safe systems programming language. However, the latter captures not only the REAL goal, but also the nua…

It's important to get the nuance of this statement right. Consider, for instance, the PSF's mission statement:

> The mission of the Python Software Foundation is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers.

"Facilitate the growth" does not imply that dominance of a certain practice (whether that is use of Python, or adoption of its core principals) is a goal. So you have an incentive for the PSF to say "our international community is growing at a sufficient rate" and focus instead on "advancing the language," which may or may not be aligned with adoption. In such a framework, it becomes easy to justify backwards-incompatible major releases that, regardless of whether their opinion is justified, many users consider to be user-hostile. Framing Rust towards a larger mission that implies user adoption of core principals as a fundamental goal seems much cleaner in that regard, and could conceivably avoid similar pitfalls.

Re: Rust is mostly safety

#258
post #250

Earlier quoted context omitted.

There was no error in the Toyota throttle control system. It was a pedal error with floor mats, and a separate pedal design error for other models.[1], combined with operator error. If you are interested, I highly recommend Malcolm Gladwell's podcast Revisionist History, which did an episode on this[2]. Long story short, your brakes can easily stop your engine at full open throttle, and in not much more space than br…

I agree that the pedal design, human error and floor mat problems are much more likely causes. I don't claim it was a software error for sure. My understanding is that indeed no specific software error was identified, but it also was never ruled out for sure. Neither of the two links seem to contain anything to that effect either.

To my memory, the podcast lays out a fairly comprehensive argument that it was just human error in the case of mechanical problems (as we'll as noting the car computers in all the cases show the brake wasn't pushed), and back it up with decades of research showing that this is a common problem, so that's about as close to definitive as you can get in this situation IMHO.

Re: Rust is mostly safety

#259
post #253

Earlier quoted context omitted.

Rust is being used in a number of places in production for a wide variety of things: https://www.rust-lang.org/en-US/friends.html

I know and I would also try Rust if I can make some small but useful things at work. But I mostly deal with various combinations of XML, SOAP, HTTP, LDAP etc. Rust does not have anything over Java, which I use currently, in my usecases.

I have to deal with a pre-REST, pre-SOAP XML API, which I would love, love, to be able to handle in Rust. But until Serde-XML is able to deserialize more of that stuff and preferably handle XSDs, I'm stuck too.

Re: Rust is mostly safety

#260

Earlier quoted context omitted.

What do you mean by "silent explicit type conversion"? If you said "silent type conversion" I'd read that as "implicit type conversion". But you said "explicit", which means you've got it very clearly in your code that you're doing a type conversion (to a smaller type), so what's silent about that?

Silent in terms of compiler not complaining.

It forces you to explicitly say that you know you're forcing a value into a narrower type; I think the fact that might mean loss of information is understood, by definition. What would you like it to do?
Post reply on HN