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

241–250 of 474 posts

Re: Rust is mostly safety

#241

Post by rubber_duck »

svckr wrote: post #110
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…

I absolutely agree. If you look at Rust from a systems programmer perspective and compare it with the systems languages OP lists then, yes, safety is THE most radical feature. But Rust can compete on so many more levels. Web services, user facing applications for example. Languages competing in that space usually bring memory safety, so it's kind of a non-issue. Safety enables Rust to be a viable choice for these tas…

>But Rust can compete on so many more levels

How ? There are languages with more expressive type systems high level type systems (Haskel/OCaml presumably). There are languages with much more mature libraries, ecosystems and tooling (C#/Java). There are languages with both (F#/Scala).

What is it that makes Rust a good applications programming language ? You said it your self GC doesn't really matter that much in this space and GC based languages are just more elegant and not to mention the tooling is way more mature. Runtime also doesn't matter that much and with the recent changes to .NET can be avoided anyway.

This Rust fanboyism is turning in to the new node hype "use node for everything node is web scale fast because it uses an event loop io instead of thread based io", "use rust for everything because the type safety is literally the best and it's the only language with a strong type system out there". I get it it's new and shiny, I like it to, and it has a strong argument to make in the systems programming - the designers are doing a good job of making trade offs that let you retain low level control while still having memory safety - but these tradeoffs are just that and they come at the expense of higher level stuff, higher level languages don't need to make these because they don't pretend to be systems programming languages.

Re: Rust is mostly safety

#242

Post by MichaelGG »

alkonaut wrote: post #163

Its the safe and performant that attracts me. If you look at Rust from C then the point is safety, but if you look at it from the other direction, e.g from F# then what attracts you is that you will get the same safety guarantees (and perhaps a few more) but without the GC and heap overhead.

Bingo. I've written high perf F# for a DB indexing and searching. The entire time I was wishing for allocation-free inlined closures and stack allocation. And for a few places, I'd really like an easy way to do asm or get really top notch codegen (integer decoding). Rust seems a lot like a fast ML. Not quite as concise as I'd like but worth it for the perf without being ugly mentally.

And the perf will surpass C in some situations due to abstraction. One popular open source platform spends 30% CPU time on malloc and strcpy because tracking ownership was so difficult and it wasn't obvious it'd be a hotspot. In Rust that would be a non issue from beginning.

Re: Rust is mostly safety

#243

Post by eridius »

zzzcpan wrote: post #225
eridius wrote: post #208

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.

Why would the compiler complain? Doing a narrowing type conversion is a perfectly legitimate thing to do. So when you ask the compiler to do it, it should.

Re: Rust is mostly safety

#244

Post by AsyncAwait »

Thaxll wrote: post #130

The daily post about Rust and Go is getting tiresome... every single day we've got one.

I read them all, you don't have to - just scroll by. I for example don't like the 'daily' snake oil salesman type of posts that pop up here, so I just skip them - easy.

Re: Rust is mostly safety

#245

Post by Animats »

Manishearth wrote: post #238
Animats wrote: post #217

Earlier quoted context omitted.

Exactly. Which is why I've been so critical, in Rust discussions, of the excessive use of "unsafe". The reply is usually something equivalent to "it's not unsafe the way I do it". Sometimes the claimed performance gain isn't there. I had a link yesterday to a forum post where someone was complaining that using an unsafe vector access function didn't speed up their program. Optimizer 1, programmer 0. (Early in my care…

I am still skeptical that "excessive use of unsafe" is actually a thing happening in Rust. Almost all the unsafe I see is for doing FFI (either for interfacing with a library or OS primitives). There's a bunch of it for implementing datastructures and stuff, and extremely little unsafe being used "for performance". Off the top of my head nom and regex do this in a few places, and that's about it. Grepping through my…

You keep making that claim without backup. Two days ago I posted links to extensive use of "unsafe" in matrix libraries. (Some of that code was clearly transliterated from C. Raw pointers all over the place.) That's entirely for performance; all that code could be safe, at some performance penalty.

I'd suggest using only safe code for whatever matrix/math library gets some traction, and then beating on the optimizer people to optimize out more checks.

Re: Rust is mostly safety

#246

Post by msbarnett »

duneroadrunner wrote: post #240
bassislife wrote: post #31

The issue with safety is that nothing is really safe. Once you have some level of safety in your programming language, you realize that there are still a lot of other sources of hazard (hardware errors, programming logic errors etc.) So I guess, it would be better to say that Rust is about decreasing unsafetyness or whatever the correct word for that is. edit: since I see posts about Go, this is evidently another app…

Yeah, I'm a bit worried that Rust is raising the floor, but maybe lowering/hardening the ceiling when it comes to code safety. I mean, if you consider static (compile-time) versus dynamic (run-time) safety, Rust leans heavily toward the former, and presumably gains a performance benefit because of it. But Rust acknowledges that it is not practical to achieve memory safety completely statically and so provides dynamic…

> If you subscribe to this idea, then it sort of follows that Rust's borrow checker may be "in the wrong place". That is, rather than forcing you to write code that is memory safe in a particular statically verifiable way, Rust could have instead enforced memory safety by injecting run-time checks into the code and optimizing them out when it recognizes code that appeases the borrow checker.

That kind of lack of transparency about what in the hell your code is doing at runtime is really inappropriate in a system's language.

It's an interesting idea, and it would be neat to play with in a language that wanted to restrict itself to more business-logic level safety concerns, but it would absolutely come at the cost of not being appropriate for systems-level tasks.

Re: Rust is mostly safety

#247

Post by jules »

MichaelGG wrote: post #242
alkonaut wrote: post #163

Its the safe and performant that attracts me. If you look at Rust from C then the point is safety, but if you look at it from the other direction, e.g from F# then what attracts you is that you will get the same safety guarantees (and perhaps a few more) but without the GC and heap overhead.

Bingo. I've written high perf F# for a DB indexing and searching. The entire time I was wishing for allocation-free inlined closures and stack allocation. And for a few places, I'd really like an easy way to do asm or get really top notch codegen (integer decoding). Rust seems a lot like a fast ML. Not quite as concise as I'd like but worth it for the perf without being ugly mentally. And the perf will surpass C in s…

You may be interested in MLton, which is an ML compiler that achieves high levels of optimisation by aggressively specialising your code: generic functions get specialised to the type and higher order functions get inlined to eliminate closure allocation.

Re: Rust is mostly safety

#248

Post by andrewflnr »

rubber_duck wrote: post #241
svckr wrote: post #110

Earlier quoted context omitted.

I absolutely agree. If you look at Rust from a systems programmer perspective and compare it with the systems languages OP lists then, yes, safety is THE most radical feature. But Rust can compete on so many more levels. Web services, user facing applications for example. Languages competing in that space usually bring memory safety, so it's kind of a non-issue. Safety enables Rust to be a viable choice for these tas…

>But Rust can compete on so many more levels How ? There are languages with more expressive type systems high level type systems (Haskel/OCaml presumably). There are languages with much more mature libraries, ecosystems and tooling (C#/Java). There are languages with both (F#/Scala). What is it that makes Rust a good applications programming language ? You said it your self GC doesn't really matter that much in this…

Yeah, on any given dimension, even safety, you'll find languages that are stronger than Rust. It excels IMO because of the balance it finds between type system, safety, functional vs imperative code, etc. It puts all these together in one package that I feel like I can use for actual work. I don't know of any other solid contenders here, except maybe Swift.

I have to agree that the "Rust all the things!" game is getting old.

Re: Rust is mostly safety

#249

Post by computerphage »

p0nce wrote: post #97
pjmlp wrote: post #79

Earlier quoted context omitted.

The reason why Java lacks a primitive unsigned type is that Gosling asked around at Sun about unsigned arithmetic and almost everyone got it wrong.

Java definately made the best decision here. Sad that we still have to live with unsigned types and the promotion rules.

Can you explain why?

Re: Rust is mostly safety

#250

Post by 1wd »

kbenson wrote: post #200
1wd wrote: post #102

Earlier quoted context omitted.

Errors in the software of the radiation therapy machine Therac-25 directly lead to the death or serious injury of six patients. Three patients died within weeks or months. http://radonc.wdfiles.com/local--files/radiation-accident-th... Errors in the software of a MIM-104 Patriot resulted in failure to locate and intercept an incoming missile and the death of 28 soldiers. http://www.gao.gov/products/IMTEC-92-26 Errors…

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.
Post reply on HN