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

271–280 of 474 posts

Re: Rust is mostly safety

#271

Post by zzzcpan »

kbp wrote: post #260
zzzcpan wrote: post #225

Earlier quoted context omitted.

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?

I would like it to tell me if I accidentally converted to a narrower type. This is a problem, because I don't necessary see the type I'm converting from due to type inference or simply am too far from the context where that type is declared and have to make assumptions to keep going. These assumptions of course fail sometimes and cause bugs. Same problem with precisions, by the way. I'm not sure how exactly compilers should fix this, the easiest fix seems to simply have different operators to explicitly allow lossy conversions, when necessary. But the bigger deal would be to treat numbers as sets of possible values with solvers or whatever to warn about mistakes where you use unhandled values in the code somewhere.

Re: Rust is mostly safety

#272

Post by echelon »

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

I've written web services in Rust, and I'm quite happy with it. Iron is a pleasure to use, and the stuff I write is incredibly performant. There's also something amazing about compiling a project to a single binary and deploying.

Rust is only about a year old. Once the library support grows, it's going to be a giant in just about every space I can think of.

Re: Rust is mostly safety

#273

Post by steveklabnik »

smitherfield wrote: post #268
steveklabnik wrote: post #266

Earlier quoted context omitted.

Integer overflow is defined to panic in debug builds, and either do that or two's compliment overflow in release builds. The current implementation overflows. However, zero is not false.

I assume that treating 0 as false was intentional in this case (it probably was written in PDP-11 ASM) and a direct translation of the Therac code therefore would be if counter > 0 { deploy_radiation_shield(); }

Yeah, you'd certainly have to see the actual code to be sure, I bet you're right.

Re: Rust is mostly safety

#274

Post by stcredzero »

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…

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"

If what you are suggesting is true, isn't the biggest problem by far the fanboyism posing as knowledge? Wouldn't complaining about Rust be like living in the age of alchemy, and complaining about someone's particular potion? Isn't the epistemological squishyness of the entire field the biggest problem by far?

Re: Rust is mostly safety

#275

Post by duneroadrunner »

msbarnett wrote: post #246
duneroadrunner wrote: post #240

Earlier quoted context omitted.

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 tran…

Hmm. Is it less transparent than vectors which use implicit run-time bounds-checks? Don't RefCells use implicit run-time checks? (Btw I don't know Rust very well, so feel free to correct me.) And what about the question mark operator for dealing with exceptions/errors? Isn't there a lot going on under the hood there?

But yeah, I can understand the sentiment of wanting to minimize that kind of thing in a lot of cases. Perhaps, like C and C++, Rust might consider bifurcating into a "high transparency" language, and a "high productivity" superset of the language. In that case, would all of the existing Rust language make it into the "high transparency" subset?

Like I said, the problem is that no one's defining what a "system" is. Haven't they written a browser rendering engine in Rust? Is that a "system"? Is there any part of the browser that does not qualify as a system?

Re: Rust is mostly safety

#276

Post by nnethercote »

geodel wrote: post #253
steveklabnik wrote: post #230

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.

It's perfectly reasonable to say "Rust isn't appropriate for my use case". Your comment higher up was more along the lines of "Rust isn't appropriate for anyone" which is far less reasonable.

Re: Rust is mostly safety

#277

Post by steveklabnik »

duneroadrunner wrote: post #275
msbarnett wrote: post #246

Earlier quoted context omitted.

> 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 tran…

Hmm. Is it less transparent than vectors which use implicit run-time bounds-checks? Don't RefCells use implicit run-time checks? (Btw I don't know Rust very well, so feel free to correct me.) And what about the question mark operator for dealing with exceptions/errors? Isn't there a lot going on under the hood there? But yeah, I can understand the sentiment of wanting to minimize that kind of thing in a lot of cases.…

RefCell does use run-time checks; that's it's entire reason for existing. They're "implicit" in the sense that they're inside of the functions, but that's the job of calling the function, so.

Question mark is roughly six lines of code, it's a match statement on Result, which has two cases.

Re: Rust is mostly safety

#278

Post by lobster_johnson »

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

The way the industry is moving, it seems that:

(1) Web apps are increasingly being split into a separation between presentation-only frontends + multiple "purely API-oriented" backends;

(2) There is a trend towards static typing in webapps.

We're currently using Go (plus some legacy Ruby apps we haven't rewritten yet) to implement microservice backends that serve APIs, and the frontend is all client-side JavaScript using React. (We also use Node.js to do server-side rendering of static HTML for Googlebot, but for a typical visitor, all the magic happens in the browser.)

For us, Go works well, and the compilation and static typing is a much-appreciated safety net compared to the everything-goes world of Ruby, not to mention much better performance and memory usage (one app is went from being multiple Unicorn processes consuming 2GB RAM in total, down to a single process using ~60MB and a fraction of the CPU usage).

But this isn't "systems programming" at all, and yet for me, Rust is very much on the table as a possible next language. I'm not sure if its complexity is large enough of a hindrance yet. Go is already a challenge for junior programmers who are used to dynamically typed languages, Rust much more so. I'd love to be able hire all seniors, but all the hot startups are taking them. (Though in that sense, Rust may even serve as a good carrot.)

As for static typing on the web side, TypeScript — which is essentially static typing for JS — is also most definitively in our future. The last year or so, Microsoft has made it easier to work with a mix of legacy JS and TS, so you no longer have to convert the entire codebase to migrate, which is great.

I don't think every company is going to move away from their classical Rails or PHP stack, of course, but there's definitely a trend, and I can imagine Rust becoming a popular alternative to the other statically-typed languages, including Scala and Java.

Re: Rust is mostly safety

#279

Post by llogiq »

fortytw2 wrote: post #38
camus2 wrote: post #28

Earlier quoted context omitted.

> i am always asking myself, how often "little" things like race conditions break something in production It can basically corrupt the whole program. I bet half go apps out there have data race. People who boast about Go's simplicity can't even see the elephant in the room. A simplistic type system doesn't fix unsafe concurrency. You'd think that safe concurrency would be an important design goal for a highly concurr…

In fairness, Go has an extremely good race detector (run/test with -race to enabled it), and makes no guarantees about memory or correctness if you write code with races in it

Last time I checked, the race detector could only find a certain percentage of data races – those easier to detect .

The crux with such systems is you tend to rely on them...

Re: Rust is mostly safety

#280

Post by EugeneOZ »

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…

when compiler doesn't let you write race conditions or unintended variable mutation - it's a huge thing, not just "decreasing unsafetyness". Although I hope Rust will also get rid of arrays bounds errors.
Post reply on HN