Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

201–210 of 474 posts

Re: Rust is mostly safety

#201

Earlier quoted context omitted.

Go doesn't protect you against race conditions, it merely offers some concurrency tools. There is nothing to declare ownership of objects in memory. So the compiler doesn't (can't) complain if you share memory and access it simultaneously. At best, there are runtime checks. Rust does offer compiler protection against that. Edit: "merely", relatively to Rust :) on an absolute scale, still way better than C for concurr…

As a total beginner (learning programming by myself since 2 or 3 years), i am always asking myself, how often "little" things like race conditions break something in production. Sure thing, some applications need to be safe-super-safe. But is it worth to switch over from go to rust as a beginner, since go is the unsafer language? I know, that there is no ultimate language. But i always asked myself i am missing a poi…

>As a total beginner (learning programming by myself since 2 or 3 years), i am always asking myself, how often "little" things like race conditions break something in production

Rookie mistake (and a shoot-yourself-in-the-foot-at-2-am) mistake coming up:

package main

import ( "fmt" "sync" )

func main() { var wg sync.WaitGroup

for i := 0; i

		go func() {
			fmt.Printf("i= %d\n", i)
			wg.Done()
		}()
	}
	wg.Wait()
}

https://play.golang.org/p/XDzFq_XK_1

And what about this code:

package main

import "fmt"

func main() {

var intArray []int for i := 0; i

		intArray = append(intArray, i)
		fmt.Printf("i= %d\n", i)
	}

	fmt.Println(intArray)
}

https://play.golang.org/p/UuI4uESZ_f

If you don't care if intArray is in the proper order, you might do something like this:

package main

import ( "fmt" "sync" )

func main() { var wg sync.WaitGroup var intArray []int

for i := 0; i

		go func(i int) {
			intArray = append(intArray, i)

			fmt.Printf("i= %d\n", i)
			wg.Done()
		}(i)
	}
	wg.Wait()
	fmt.Println(intArray)
}

What's wrong?

On my multi-core computer (though not on playground), len(intArray) could be as low as 500!

Why?

Because a = append isn't atomic.

Go, which is so pedantic about "stupid" mistakes (including something, changing your mind, and not "unincluding" it), didn't catch this. Not an error and no warning.

But the worst part is that when you loop until 10, it works. You can unit test it, integrate test it, and have it break at any point in time.

Re: Rust is mostly safety

#202
post #6

In case you missed that there's a big disillusioned C++ crowd out there. Just hear the pain: https://news.ycombinator.com/item?id=13276351 And some of them are watching you with great interest.

And there's a tired security crowd watching Rust with great hope; C++ and C have created innumerable security holes at the expense of "convenience". Cryptographic libraries, codec libraries, image conversion libraries, OS kernels, sandboxes, virtual machines, browsers, (the list is endless) have all suffered glaring security holes from the lack of memory hygiene afforded by C and C++. Any time your code takes in untr…

Rust may ultimately be the better solution for many or most cases, but right now SaferCPlusPlus[1] may be the more expedient solution for existing C/C++ code bases.

> Any time your code takes in untrusted input, it should not be written in an unsafe language.

Not just that, but my theory is that untrusted input should only be stored in data types specifically designed for untrusted input [2], and should undergo safety/sanity checks during conversion to more high-performance types. For example, a general rule might be that untrusted integer inputs may only be converted to (high-performance) native integers if their value is less than the square root of the max integer value.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[2] https://github.com/duneroadrunner/SaferCPlusPlus#quarantined...

Re: Rust is mostly safety

#203

I think Rust is mostly about safety in the same way that skydiving is mostly about safety. Having safety features that you know you can rely on allows you to take risks that you normally wouldn't in order to accomplish some really awesome things. (I guess in this analogy C is a parachute that you have to open manually, while Rust is a parachute that always opens at exactly the right altitude, but isn't any heavier th…

Rust safety is ultimately a productivity boost. For example, if I have a big string, I may create a hashmap where both keys and values are references to some portions to that original string. Then, I may pass this hashmap to another function that will transform this hashmap into structs that contain reused portions of those string references. Rust compiler will make sure that the original string is not destroyed or m…

I wrote about this concept a bit in http://manishearth.github.io/blog/2015/05/03/where-rust-real..., with an example of a situation where in Rust I was able to make things work but in C++ I'd be totally terrified and use a shared_ptr or something.

I like to say that Rust lets you toe the line perfectly, and dance near it as much as you want. C++ does not, since you're afraid you may accidentally cross it.

Re: Rust is mostly safety

#204
post #160

Earlier quoted context omitted.

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

You completely misunderstood what he was trying to tell you.

Re: Rust is mostly safety

#205
post #134
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.

There are very few libraries that are nightly-only in Rust. Clippy is a big one, but clippy is a tool, not a library, so it's no big deal (we're working on making it not require a nightly compiler).

Rocket is a recent one. I talked with the owner of Rocket and one of their goals was to help push the boundaries of Rust by playing with the nightly features. With that sort of meta-goal using nightly is sort of a prerequisite. Meh.

You can use almost all of the code generation libs on stable via a build script. Tiny bit more annoying, but if it's a dependency nobody cares. A common pattern is to use nightly for local development (so you get clippy and nicer autocompletion) and make the library still work on stable via syntex so when used as a dependency it just works.

The most used part of the code generation stuff will stabilize in 1.15 so it's mostly not even a problem.

Re: Rust is mostly safety

#206
post #84

Earlier quoted context omitted.

It is not my intention to show Rust in bad light. I roughly mean to say both languages have put about 6-7 years of engineering effort by now but usage differs by an order of magnitude or so. I agree that they had very different priorities in beginning and it changes with time. My goal was to merely point out core rust people in Mozilla and elsewhere now recognize that industry usage is an area of high importance in c…

I think your not looking at this correctly. Swift also had a very fast pasted release cycle like Go. Rust took a different path, the developers until the 1.0 release basically said; use at your own risk, we reserve the right to change anything and everything and break it all. This freed them of trying to keep the language backward compatible. After the 1.0 release, there have been nearly no breaking changes introduce…

I said 6-7 years of engineering effort not development cycle which are often linear. I am not blaming for taking long to get things right. If authors think they need more time then of course they need more time. Right now they really want to have broader industry usage and this can't be any clearer when they say:

"Production use measures our design success; it's the ultimate reality check. Rust takes a unique stance on a number of tradeoffs, which we believe to position it well for writing fast and reliable software. The real test of those beliefs is people using Rust to build large, production systems, on which they're betting time and money."

Re: Rust is mostly safety

#207
post #152

Earlier quoted context omitted.

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

Sometimes you want it to be lossy, but not most of the time, and yet there is no choice. I had a bug caused by that, that's why I remember it. Silent explicit type conversions are essentially unsafe.

In Rust, lossy conversions only occur if you you explicitly write `var as type` and even that syntax is limited to certain types e.g. you can't coerce an integer to a function. In order to do something crazy like that, you'd need to call the unsafe `mem::transmute` function. The language cannot be much safer in this regard short of disallowing any sort of type conversions.

Re: Rust is mostly safety

#208
post #152

Earlier quoted context omitted.

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

Sometimes you want it to be lossy, but not most of the time, and yet there is no choice. I had a bug caused by that, that's why I remember it. Silent explicit type conversions are essentially unsafe.

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?

Re: Rust is mostly safety

#209

Earlier quoted context omitted.

As a total beginner (learning programming by myself since 2 or 3 years), i am always asking myself, how often "little" things like race conditions break something in production. Sure thing, some applications need to be safe-super-safe. But is it worth to switch over from go to rust as a beginner, since go is the unsafer language? I know, that there is no ultimate language. But i always asked myself i am missing a poi…

I don't know why you are downvoted since your question is legit. I'll answer given my own experience : At my former company, we had a websocket-based service that allowed symetric communication between the clients. We had around 10% connection failures, and we thought it was causes by websocket well-known incompatibilities with some network stack, and we had a fallback to ajax polling. Several month later, someone to…

These are some of the bugs I hate the worst. When you have a plausible explanation about why it's slow, or fails sometimes, and it isn't under your control (or is way out of your purview), it's far to easy to stop lookingand not find your own bugs that exacerbate the problem. Because if you don't have a bug, and it is all that external problem, you just wasted all that time looking. Finding that bug later is especially painful, as you realize a little more time initially may have saved so many problems later. :/

Re: Rust is mostly safety

#210
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.

> As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that.

C (and later C++) became popular because Unix was successful. Safe systems programming and safe browsers are nice to have but not completely safe if the underlying OS is unsafe (Windows in particular). Rust's "killer app" would be a safe OS. The first attempt (Redox) is already there.

Post reply on HN