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

381–390 of 474 posts

Re: Rust is mostly safety

#381

Post by Manishearth »

sidlls wrote: post #379
Manishearth wrote: post #339

Earlier quoted context omitted.

What did you find complicated or terrifying there? The fact that the code was complicated was sort of the point; the generic deriving code in the Rust compiler is in general a very tricky and confusing area and pretty complicated to deal with. In C++ I would have been very careful around code like this and not introduced new pointers. In Rust, I could do this without being afraid of memory issues. You're not supposed…

I'd argue that in order to properly evaluate your statements regarding C++ (and Rust, for that matter) it actually is important to understand the code and what you're trying to do. Given that there generally is more than one way to solve a problem it isn't unreasonable to think you found a solution that doesn't map (well) to C++ and from there generalize (perhaps incorrectly) that therefore it's impossible in C++ (wi…

Well, in this case there aren't multiple solutions -- my solution was literally the problem statement. I wanted to make a particular array accessible later in the pipeline in a specific API. That was the problem statement (the reason behind this problem was that the plugin API needed to be able to expose this array). This itself was pretty simple. The array arose from a particularly entangled bit of code. Possible ways to persist it are with a regular or smart pointer/slice to the vector, in both Rust and C++.

This isn't an instance of the XY problem.

Re: Rust is mostly safety

#382

Post by jjnoakes »

nickpsecurity wrote: post #312
pron wrote: post #251

Earlier quoted context omitted.

> 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) r…

I wasn't saying you were shilling to dodge competition so much as better performance is in your marketing material like many others. ;) I agree that a lot of the space they should be targeting won't have a humongous difference between a well-tuned GC and a typical, native implementation. You're right on that. "Companies that sell ultra-low latency GCs for a fraction of the cost it would take for enterprise shops to a…

With rust you don't need to rewrite though. Just integrate it a little at a time.

Re: Rust is mostly safety

#383

Post by kazinator »

white-flame wrote: post #375
nurettin wrote: post #123

Earlier quoted context omitted.

Wait, Rust has macros that expand to code and mess up debugging, confuse tooling and everything else just like C++? Isn't that exactly what the language should have avoided?

C++ macros don't expand to actual semantic "code", in terms of an AST or even lexed terms. It blindly expand spans of textual characters, which I agree no post-C language should ever do again. Languages as old as Lisp do AST-level macro expansion, with the actual programming language itself computing the expansion. Any code template blocks in the macro body are processed and validated in the native syntax of the lang…

C and C++ macros are worse than textual.

They work with abstract token sequences.

This, per se, is not inherently worse, except that, oops: undefined behavior is worked into the spec. For instance, if you have a macro argument X which holds the ( token and another one Y which holds 123, and you paste these together using X ## Y, you get undefined behavior: two tokens are pasted to form something which is not a single, valid token.

A purely textual preprocessor wouldn't have an UB issue of this type.

Re: Rust is mostly safety

#384

Post by zerofan »

> Well, I just re-read your list of 'clever' features, and can't really see how any of them is incidental

Couldn't find one thing that could be simpler, eh? I think you just said you wouldn't admit you're wrong under any circumstances.

> Not sure what to make of this comparison, given that Rust beat Swift in the majority of the benchmark tasks.

Are we looking at the same page? Swift wins the first 3, ties on the next 2 and loses on the last 4. You can call that 6 to 3 if you want, but it seems pretty neck and neck for languages with comparable safety promises.

> Also, you have to look at the quality of the compilers themselves. Rust is universally acknowledged to be a high-quality compiler, while Swift (especially together with Xcode) are often bemoaned as buggy and crashy.

Now you're just showing your ignorance. Rust uses LLVM for it's code generator. The Swift language is headed up by Chris Lattner, who started the LLVM project. Swift and Rust use the same code generator. Rust is riding on LLVM's coat tails. I have no idea who's in charge of Xcode, but I don't currently program on a Mac or use IDEs, so I don't care if that crashes.

> Well, I have to say they are an extremely lucky bunch. Most systems programmers don't have the luxuxy of writing script-sized programs which use the OS as their garbage collector.

Most programmers don't have the discipline to keep their programs simple. So yes, I'm lucky to be in a place where lines of code is considered a cost instead of a benefit.

> 'Would you like to do high-performance concurrency with statically guaranteed no data races?'

No, we also tend to use multiple processes instead of multiple threads. This scales very easily across a cluster of computers, something Rust won't do for you.

Go ahead and have the last word if you like - I won't reply. I've clearly made you defensive, and I don't think this discussion is likely to turn friendly again.

Re: Rust is mostly safety

#385

Post by kibwen »

mahyarm wrote: post #331
kibwen wrote: post #263

Earlier quoted context omitted.

I think this comment and the OP are both correct. The point of Rust is safety, in the sense that memory safety should be the default for all programming languages, and has been the default for all non-systems languages since the 90s. The only holdouts have been because people used to claim that memory safety wasn't possible without making a language unusably slow, which Rust has disproven. In all my years of teaching…

If you know swift/objc pretty well with it's ARC reference counting memory management, do you pick up the borrow checker faster?

AFAIK Swift doesn't really have references or anything to enforce unique ownership. If you've ever used a language with pointers before, including the simple pointers that Go has, then that's a good start. If you further understand how escape analysis works in Go (or the various escaping annotations in Swift), then imagine a language where every variable must never escape, and where this is enforced by the compiler.

Mostly I think that the fear of the borrow checker has become more meme than truth at this point. The difficulty with Rust is that it has things found in different languages, so no matter who you are you probably have to learn something: a strong type system and unique ownership and pointers, and if you're coming from a language like Python and Javascript you may know none of this! But that's what we're here for (that's where I came from!), and we like to help. :)

Re: Rust is mostly safety

#386

Post by ssalazar »

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…

More to the point, Rust and other statically typed languages* eliminate type errors at compile-time.

In e.g. Python, the following code:

    foo = Bar()
    foo.baz()
will compile without complaint but, supposing that baz() is not a member of class Bar, will cause errors when the code is actually run. In statically typed languages this will be caught by the compiler and treated as an error; type errors are simply not allowed in compiled programs.

This distinction is significant, as Python and other dynamically-typed languages require comprehensive test suites for any non-trivial software written in them, shifting the burden of ensuring type safety to the programmer. Testing systems for statically typed languages don't need to concern themselves with type safety. Dynamic typing also carries performance penalties at run-time (checking type safety for e.g. every member access).

* Some statically-typed languages (e.g. C++) allow for very specific subversions of type safety at run-time, but its usually clear to the programmer when they are doing something dangerous.

Re: Rust is mostly safety

#387

Post by msbarnett »

braveo wrote: post #369
msbarnett wrote: post #223

Earlier quoted context omitted.

There was nothing interesting in what he was trying to say. Yes, no programming language perfectly eliminates all classes of unsafety. But that's no reason to let the perfect be the enemy of the good! "The issue with safety is..." no issue at all. Being safe in a bunch of problem domains (Rust) is still strictly better than being safe in very few if any of them (C).

So you did it on purpose. That just makes you a bad actor in the conversation.

I am not whoever you imagine you're responding to (rkrzr, I guess)

Re: Rust is mostly safety

#388

Post by tblair »

paulddraper wrote: post #288
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. It depends what you call a "type error". Is calling `car` on a `nil` instead of a `cons` a type error?

It is in Rust, although I'm sure you can come up with something where the type system won't save you.

Re: Rust is mostly safety

#389

Post by [deleted] »

yawaramin wrote: post #377
zerofan wrote: post #366

Earlier quoted context omitted.

I don't believe those clever things are necessary for safety or performance. I think many of them are incidental and caused by a lack of taste or just a disregard for the value of simplicity. Rust deserves credit for it's good ideas, but these aren't those, and I believe there will be other high performance (non-GC) languages that are more accessible to non Computer Scientists [1]. > To your coworkers I would reply:…

> I don't believe those clever things are necessary for safety or performance. I think many of them are incidental and caused by a lack of taste or just a disregard for the value of simplicity. Well, I just re-read your list of 'clever' features, and can't really see how any of them is incidental, or in fact how some of them are worse than the exact same features in Swift, which you mentioned. > ... I believe there w…

[deleted]

Re: Rust is mostly safety

#390

Post by yawaramin »

zerofan wrote: post #384

> Well, I just re-read your list of 'clever' features, and can't really see how any of them is incidental Couldn't find one thing that could be simpler, eh? I think you just said you wouldn't admit you're wrong under any circumstances. > Not sure what to make of this comparison, given that Rust beat Swift in the majority of the benchmark tasks. Are we looking at the same page? Swift wins the first 3, ties on the next…

re: https://news.ycombinator.com/item?id=13282559

> Couldn't find one thing that could be simpler, eh? I think you just said you wouldn't admit you're wrong under any circumstances.

I'll happily acknowledge being wrong. Please point out how any of the features you mentioned could be simplified or removed without compromising on safety.

> You can call that 6 to 3 if you want, but it seems pretty neck and neck....

In any case, this is the problem with benchmarks--even with hard numbers we won't agree on who's winning because everything is up for argument.

> Swift and Rust use the same code generator. Rust is riding on LLVM's coat tails.

The code generator backend (LLVM) is not the same thing as the compiler frontend (lexer, parser, typechecker, AST tree shaker, etc.). I am specifically referring to the Swift compiler frontend. If you don't believe me, here's a dedicated repo for tracking Swift compiler crashes: https://github.com/practicalswift/swift-compiler-crashes

> Most programmers don't have the discipline to keep their programs simple. So yes, I'm lucky to be in a place where lines of code is considered a cost instead of a benefit.

I think we're talking about different things here. I'm visualising long-running software that drives automation of your systems. You're talking about quick jobs that do some task and then exit.

> ... we ... tend to use multiple processes instead of multiple threads. This scales very easily across a cluster of computers, something Rust won't do for you.

I mean, which language does scale multiple processes across clusters easily for you? I'm very curious to find out.

> Go ahead and have the last word if you like - I won't reply. I've clearly made you defensive, and I don't think this discussion is likely to turn friendly again.

If you won't engage in discussion, then how am I the defensive one?

    ¯\_(ツ)_/¯
Post reply on HN