Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

Post reply on HN
Print view View original

151–160 of 474 posts

Re: Rust is mostly safety

#151

Post by steveklabnik »

izym wrote: post #35
Annatar wrote: post #30

Wow, I have to admit I have never seen anything pushed so aggressively here on Hacker News as Rust. Rust: "everybody who writes in anything but our invention has security holes, but we don't, because we know what we're doing! And although we broke users' programs in the past, we don't do that any more! We're all grown up now! Trust us!"

When have they broken stuff post 1.0?

Since the parent is content to just argue, in the interest of transparency, we have made one or two small fixes so far.

Specifically, I'm thinking of https://github.com/rust-lang/rfcs/pull/1214 , which was a soundness fix that went through warnings in 1.4 and became an error in 1.7.

Code like this:

  struct Foo {
      f: fn(&'a X)
  }
Would compile on 1.4, but not 1.7. The fix is:

  struct Foo {
The compiler would tell you exactly what to replace, and that's all it took to upgrade. This was worth fixing a soundness hole. We originally thought that it would become an error in 1.5, but we monitored the ecosystem to see how many packages upgraded, and it wasn't until 1.7 that we were comfortable making the change. This meant that there was no effective break, even though code technically broke.

Those are the circumstances in which this might happen: very important, yet trivial to fix. We've only done it once or twice, and the vast majority of code written in the real world that built on 1.0 in practice builds on 1.14 today.

Re: Rust is mostly safety

#152

Post by iopq »

zzzcpan wrote: post #55
rkrzr wrote: post #45

Earlier quoted context omitted.

> The issue with safety is that nothing is really safe. There is a trade-off between safety and expressiveness. Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language). But I think that is beside the point here. This is about eliminating whole classes of errors. A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your prog…

> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs. Do you consider silently trimming value during mandatory explicit type conversion a type error?

No, because if you explicitly converted to another type, that's what you wanted.

Re: Rust is mostly safety

#153

Post by steveklabnik »

pimeys wrote: post #146
dom0 wrote: post #134

Earlier quoted context omitted.

> In my opinion Rust is about doing things right. On the other hand there is a quite dark cloud on the horizon with the stable vs nightly split. You can't run infrastructure on nightly builds; or add nightly builds to distributions.

I don't see a split here. I know lots of cool ideas have been posted to Hacker News lately, that showcase something possible in future versions of Rust. But I seriously hope people keep these libraries as showcases, not production-quality tools. I'd say this nightly/stable split is a bit out of proportion. In 2017 we'll get Tokio and lots of Tokio-ready libraries. Some of them already work and compile with stable Rus…

Tokio runs entirely on stable, though 1.0 won't happen until some language changes land.

Diesel does work on stable today, but its nightly features will be on stable in five weeks with 1.15.

Re: Rust is mostly safety

#154

Post by psyc »

jMyles wrote: post #5

> countless lives lost I have no doubt that people have had their lives ruined, or even died, as the result of flaws in system programming, but is anyone actually tracking this? Is it "countless?"

TDD: "If you're not doing this, you're not a real engineer."

Rust: "If you're not doing this, you're a murderer."

Re: Rust is mostly safety

#155

Post by pron »

nickpsecurity wrote: post #141
pron wrote: post #22

I completely agree. This is what I wrote on Reddit in response to Klabnik's post: Rust can make such an important contribution to such an important slice of the software world, that I really fear that trying to make a better pitch and get as many adopters as quickly as possible might create a community that would pull Rust in directions that would make it less useful, not more. Current C/C++ developers really do need…

"Current C/C++ developers really do need more safety. They don't need a more pleasant language. " The number of C++ developers griping in HN threads about language-level problems effecting their work tends to disagree. It's not as if they wanted C++ to be designed that way. It was just only one with big companies' support that had zero-cost abstractions for programming in the large & great compatibility with C librar…

> 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 big, bottom-line impact, but that impact is almost entirely due to safety.

> They might benefit if the app is aiming for max performance (esp HPC), memory efficiency (eg embedded), or minimal latency

I don't think max performance is an issue at all, nor even minimal latency where you need it (there are realtime GCs, and GC languages do support arena GC allocation in embedded and realtime settings, like realtime Java), but definitely it's a big gain in memory efficiency.

But again, I said they could benefit. It's just that the main focus shouldn't be on those that would benefit, but on those for whom the language is indispensable, or tremendously beneficial.

> I think Rust might have good, network effects if it takes off.

Absolutely, it's just that if you want Rust to really have an impact rather than just be popular, you need that network effect to be in the right network, and for systems programming, that network is not well represented on HN and Reddit. While these venues are good for marketing, and while the message will get to some of the most important crowd, it may have a negative effect as it would attract many that don't really need Rust, and if they end up making up most of the community, they may slowly push the language in directions that may make it less appealing to those who really need it.

Re: Rust is mostly safety

#156

Post by pron »

steveklabnik wrote: post #138
pron wrote: post #22

I completely agree. This is what I wrote on Reddit in response to Klabnik's post: Rust can make such an important contribution to such an important slice of the software world, that I really fear that trying to make a better pitch and get as many adopters as quickly as possible might create a community that would pull Rust in directions that would make it less useful, not more. Current C/C++ developers really do need…

We are doing some work like that, but not a ton yet. You need connections to do so, in my experience, and that's tough.

Doesn't Mozilla have good connections? It's not like you're a small, unknown organization.

Re: Rust is mostly safety

#157

Post by blacksmythe »

geodel wrote: post #20

The original Rust author make great points about safety. I think this new thrust on marketing emerges from Rust Roadmap 2017 which puts Rust usage in industry as one of the major goal. Currently Rust is about Go's age but nowhere close in usage. As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that.

    >> Currently Rust is about Go's age but nowhere close in usage.
However, Go has been suitable for production projects for several years longer than Rust.

Rust sits in a very useful niche not served by other languages, and in steady state will probably be more popular than Go.

Go has a very well designed ecosystem. I like it, use it, and am very impressed with everything about it I have seen. However, I don't see use cases that Go serves vastly better than other available alternatives.

Re: Rust is mostly safety

#158

Post by pvg »

pjmlp wrote: post #126
nickpsecurity wrote: post #119

Earlier quoted context omitted.

I thought it was supposed to be Oberon-2 with some Limbo, C, etc touches. That's part of how it becomes my slam dunk against C in anther discussion. ;)

If you read the Inferno programming guide, you will see how much the languages resemble themselves. Major differences are that Limbo uses a VM based runtime with dynamic loading and Abstract Data Types. But your approach is also good, still Oberon had some issues that were eventually improved in Oberon-2 that Go lacks. On the other hand Oberon-07 is even more bare bones than Go.

Most languages resemble themselves very strongly.

Re: Rust is mostly safety

#159

Post by kincardine »

dom0 wrote: post #134
agentgt wrote: post #94

I'm a lowly ancient Java programmer and I think Rust is far far more than safety. In my opinion Rust is about doing things right. It may have been about safety at first but I think it is more than that given the work of the community. Yes I know there is the right tool for the right job and is impossible to fill all use cases but IMO Rust is striving for iPhone like usage. I have never seen a more disciplined and bal…

> In my opinion Rust is about doing things right. On the other hand there is a quite dark cloud on the horizon with the stable vs nightly split. You can't run infrastructure on nightly builds; or add nightly builds to distributions.

I'm sorry your comment has gotten the response it has.

The looming dark cloud of stable vs. nightly only looks like a dark cloud to those outside the Rust community.

The article that made its way up Hacker News awhile ago (https://news.ycombinator.com/item?id=13251729) got pretty much no traction whatsoever in the Rust community.

Re: Rust is mostly safety

#160

Post by rkrzr »

ytugiuyghvk wrote: post #111
rkrzr wrote: post #56

Earlier quoted context omitted.

> It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. Like I said: It will eliminate a specific class of errors, namely all type errors. Your program will literally not compile if there are any type errors. > The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language. Sure, I don'…

Every type system eliminates all its own type errors by definition. Even the trivial system with one type eliminates all its own type errors (vacuously, since there are zero of them). There is no universal set of errors called type errors. What are type errors depend on your type system. A good type system allows more errors to be encoded as type errors so you can catch them at compile time, but it doesn't mean anyth…

Sure, not all type systems are created equal. And there are indeed type systems that can catch more errors than Haskell's (although that usually comes at the price of losing type inference).

But I read OP's point as "Well, you can never catch all programming errors with PL_feature_X, so why even bother." And my point is simply that a lot of PL features make formerly hard things easy and thus allow you to go faster and focus on more interesting things.

Post reply on HN