[zerofan]

Have you done much skydiving? I used to go three days a week, for a couple years, between 4-10 jumps a day at a place that had world class experts. My experience is that only beginning skydivers are constantly preaching safety. They go around (vocally) judging everything they see, and I think they do it because it alleviates their own fear. Instructors would teach safety, but really only to their own students.

I think the safety aspect of Rust appeals to a lot of beginning programmers. They can feel safer looking down their nose at us dangerous C or C++ programmers.

> Rust is a parachute that always opens at exactly the right altitude

This isn't a good metaphor. Frequently it's safer to pull higher, and on some occasions, you're safer opening lower than you had planned... I think a canopy that always opened at the prescribed height would cause many unnecessary deaths. That doesn't say anything about Rust, one way or the other.

[dllthomas]

> I think the safety aspect of Rust appeals to a lot of beginning programmers.

Maybe, but it also appeals a lot to many of us experienced programmers who know how hard things can bite us. It's not so much that we can't get things right. It's that it's really expensive to revisit old assumptions when circumstances change, and it's phenomenal to be able to document more of these in a machine-checked way.

[zerofan]

Please don't get me wrong - I would take safe over non-safe if everything else were equal. It's just that Rust made many other choices that are worse for me than what's in C++. Also, I think it would be very painful trying to explain some of Rust's features to my coworkers (who are generally very smart, but generally not interested in clever programming languages).

> It's that it's really expensive to revisit old assumptions when circumstances change, [...]

That's very dependent on the type of work you do. Over the last 23 years, my job has been to write many small programs to solve new problems. It's not expensive for me because I've aggressively avoided making monolithic baselines. I have medium sized libraries that I drag from project to project, but I can fix or rewrite parts of those as needed without breaking the old projects.

[dllthomas]

> That's very dependent on the type of work you do.

True, if your code never gets big or old, you can keep all of it in mind and write correct code without too much worry. Though in my experience, it really doesn't need to be very old or very big before tooling starts paying big dividends.

> I have medium sized libraries that I drag from project to project

I'd wonder in particular about those libraries. Certainly you know more about your context. But I expect that there are both contexts where it wouldn't be helpful, and also contexts where it would be substantially helpful but authors don't know what they're missing. I don't have a way of distinguishing the two here.

[yawaramin]

I think it's a misconception to classify type-safety and memory-safety techniques as 'clever', they should be seen as the bread-and-butter of day-to-day coding. To put it another way, Rust's memory safety is no more clever than C++'s smart pointers, the only difference is what people mistakenly believe about the two.

[zerofan]

> I think it's a misconception to classify type-safety and memory-safety techniques as 'clever'

I didn't call Rusts type-safety of memory-safety clever. The clever stuff is lifetime specifications, a multitude of string types, traits as indications to the compiler for move vs copy, Box Ref Cell RefCell RefMut UnsafeCell, arbitrary restrictions on generics, needing to use unsafe code to create basic data structures, and many other things.

If I tried to advocate Rust in my office, many of my coworkers would simply say, "I didn't have to do that in Fortran, and Fortran runs just as fast. Why are you wasting my time?!"

[yawaramin]

Almost everything you mentioned as 'clever' is trying to achieve either type-safety or memory-safety. To your coworkers I would reply: would you like the compiler to handle error-prone memory deallocations? Or do you want to keep doing it manually and wait till runtime to find potential mistakes?

[zerofan]

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: would you like the compiler to handle error-prone memory deallocations? Or do you want to keep doing it manually and wait till runtime to find potential mistakes?

They don't really care about memory deallocations - the program will finish soon anyways, and the operating system will cleanup the mess. Sorry, they've already excused you from the office and have gotten back to getting their work done.

Btw, modern C++ programmers don't worry about memory deallocations either. You should find a better bogeyman.

[1] http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... (yes, most people disregard benchmarks, but you need someway to discuss performance)

[kibwen]

> a multitude of string types

There are two string types in Rust, `String` (growable and heap-allocated) and `&str` (a reference to string data). Anything else is just a shim for FFI.

[zerofan]

> There are two string types in Rust, `String` [...] Anything else is just a shim for FFI.

I guess I don't have to worry about the non-Scotsman strings then... You've heard the criticisms about Rust's strings before, and I'm unlikely to tell you anything you don't know.

[rcthompson]

No, I haven't done any skydiving. After writing my comment, I suspected my analogy might not hold up if I knew more about skydiving. I guess just imagine an abstract form of skydiving where you just need to have fun in the sky and then open your chute at the right altitude, and you'd like to wait as long as you can before opening it.

I still think the point is valid, though, even if the analogy isn't.

[zerofan]

Fair enough. I'm sorry about calling you out on the metaphor. Instead I'll call you out on the point itself :-)

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

Unless you rush to publish a public facing version of your code, I can't see why you'd be afraid to take risks in any language. What's so scary about a buffer overflow on your home workstation running data from a source that's never even seen your program? It will just segfault, which is no worse than a Rust panic. If I could exploit your new code, it means I've already gotten so far into your workstation or server that I could just run my own code. Where does the fear come from?

[rcthompson]

I think it's more like: since you know the compiler won't let you write a buffer overflow, use-after-free, data race, etc., you no longer have to waste time worrying about whether your code might contain such problems, which frees up more mental bandwidth for other concerns. But unlike other languages, you still have confidence that your code will compile to equally performant machine code (e.g. No GC overhead).

The scary thing isn't causing a segfault on your local machine. The scary thing is writing code that could segfault but doesn't do in testing until after you've deployed it publicly. If your compiler rejects code that can segfault, this is no longer a concern. (Or replace segfault with a buffer overflow that leaks your private keys or something equally bad.)

I guess the analogy would be that you can have more fun cavorting across the sky if you knew with 100% confidence that your parachute automatically would deploy itself at the appropriate time (and not a moment sooner).

[zerofan]

> I think it's more like: since you know the compiler won't let you write a buffer overflow, use-after-free, data race, etc., you no longer have to waste time worrying about whether your code might contain such problems, which frees up more mental bandwidth for other concerns.

I've spent a lot of time figuring out how to do completely mundane things in Rust. At this point, buffer overflows and use-after-frees are not my biggest concerns in C++.

> The scary thing isn't causing a segfault on your local machine. The scary thing is writing code that could segfault but doesn't do in testing until after you've deployed it publicly. If your compiler rejects code that can segfault, this is no longer a concern.

If your testing didn't catch the problem (which I can fully understand), a panic at runtime is not much different than a segfault.

> (Or replace segfault with a buffer overflow that leaks your private keys or something equally bad.)

I firmly believe the OpenSLL team would've used unsafe blocks in Rust to disable the performance overhead of bounds checking. That whole exploit was caused by sloppy optimizations, and Rust is not immune from that.

[kbenson]

> I've spent a lot of time figuring out how to do completely mundane things in Rust. At this point, buffer overflows and use-after-frees are not my biggest concerns in C++.

I could visit a country with a completely different set of laws regarding driving and a different road marking system. After a few days of driving, I might also feel like I've spent a lot of time trying to figure out how to navigate the rules of the road rather than actually getting to my destination when compared to driving in my native lang. I would also be unable to accurately ascertain whether one system was better than the other, because of inadequate experience with the new system. It would be a mistake to assume that I could become proficient enough in such a complex system in such a short period of time as to ascertain whether one was better than the other.

To put it another way, I don't feel like avoiding bicyclists is my biggest problem when driving, but having a dedicated bike lane at all times would probably be a good idea anyways. Sure, maybe you've never hit a cyclist, and never will. That doesn't mean it doesn't happen enough that we shouldn't do something about it, because it does.

> If your testing didn't catch the problem (which I can fully understand), a panic at runtime is not much different than a segfault.

No, a segfault at runtime is something that is possibly exploitable. A Panic is not.

> I firmly believe the OpenSLL team would've used unsafe blocks in Rust to disable the performance overhead of bounds checking.

Even if they did, that would still reduce the portion of the code that needs to be audited to those blocks. Effort could be made to reduce the size and scope of those blocks. There is something to be said for having the ability to categorize and enforce different safety levels in your codebase, when the alternative is no categorization or enforcement.

[zerofan]

> I could visit a country with a completely different set of laws regarding driving [...]

Arguments by metaphor aren't my thing. It's very likely I would become more proficient at Rust if I programmed in it more. It's also very likely the poster above would worry less about memory errors if s/he programmed in C or C++ more. Yes, Rust is safer in some ways, but I still can't understand where all the fear of other languages comes from.

> having a dedicated bike lane at all times would probably be a good idea anyways.

I used to live in a city with a lot of dedicated bike lanes. I commuted to work on a particularly long stretch that was very popular for cycling. The majority of the cyclists refused to ride in the lane. It turns out that cars naturally blow the dust and small pebbles out of the main road way, but bikes don't do that in the bike lane. Cars also smooth out the pavement in their tire tracks. The result was a road that's 5 foot narrower for cars (speed limit 45 mph) with bicyclists in it (not moving 45 mph), a generally unused bike lane, lots of uncomfortable passing, and a lot of indignation from cyclists who claimed an equal right of way despite having a separate lane designated for them.

> Sure, maybe you've never hit a cyclist, and never will. That doesn't mean it doesn't happen enough that we shouldn't do something about it, because it does.

The city I live in now has many bike paths, completely separate from major roads. It's also a different climate, so there are less pebbles and they have street sweepers clean the road after snow season to remove the sand. There really doesn't seem to be much interaction between the cyclists and the cars. So should I choose a programming language with bike lanes on major roads or separate paths though the parkways? :-)

> No, a segfault at runtime is something that is possibly exploitable. A Panic is not.

Anything is possible, but it's very unlikely. I will write a program and intentionally put a buffer overflow in it. Can you send me some data that will exploit it?

Here's a metaphor that also isn't one: I'm not afraid of terrorists despite some high profile events in the last 20 years. I certainly wouldn't optimize my life around avoiding terrorist attacks because the empirical evidence shows me the probability is very low.

[rcthompson]

Perhaps a better analogy would be the way that much of modern medicine is enabled by access to antibiotics. Without antibiotics, the risk of post-operation death by infection would be so high as to rule out many of the procedures that we now consider safe and routine.

[zerofan]

I would prefer a surgeon who washed his hands over one who didn't but gave me antibiotics. I've had stitches a few times, but only one real surgery. I never got antibiotics for any of those. Maybe we could skip the analogies? I don't think they help the discussion.

[jibalt]

They help in a discussion with someone intellectually honest.

[kibwen]

> I think the safety aspect of Rust appeals to a lot of beginning programmers.

Is that a bad thing? All programmers start as beginners, and if C is too painful to begin with then they'll learn via an easier language, and then comfortably spend their whole careers using those easier languages. If we want to expand the field of systems programmers organically, then we need to make tools that don't punish beginning programmers.

> They can feel safer looking down their nose at us dangerous C or C++ programmers.

What makes you feel like anyone's looking down their noses at you? Every language in history has been made to address the perceived flaws of some prior language. Safety is a crucial selling point for a huge chunk of people, and C and C++ have failed to appeal to this market. Just because safety isn't a priority for you doesn't mean that the people for whom it is a priority are suddenly pretentious.

[zerofan]

> > I think the safety aspect of Rust appeals to a lot of beginning programmers.

> Is that a bad thing?

The appeal to beginners is fine, maybe even a good thing, but the condescending comments from beginners is a lot like listening to a teenager who thinks they know everything.

> What makes you feel like anyone's looking down their noses at you?

There're are no shortage of obnoxious comments from beginning Rust users here and on Reddit. If you can't see them, it might be because you're aligned with that point of view.

A recent one implied the whole world is going to end because of Heartbleed-like exploits. Don't they realize that despite the occasional high profile exploits, the world is generally running just fine? Don't they realize that the OpenSSL developers would've probably used pools of dirty memory to avoid allocation costs and unsafe blocks to avoid bounds checking had they developed that code in Rust? They got bit by sloppy optimization, and Rust isn't immune to that. I really wish people weren't so afraid of everything that achieving safety is their primary goal.

> Just because safety isn't a priority for you doesn't mean that the people for whom it is a priority are suddenly pretentious.

It's not pretentious if you make your own decision for your own project. It's not even pretentious to spread the good word and say how much you like Rust. It is very pretentious and condescending when you say something like in Graydon's article: """When someone says they "don't have safety problems" in C++, I am astonished: a statement that must be made in ignorance, if not outright negligence."""

Are you going to stand by that sentence? You probably should, because the newbies will love you for it, and it might help increase adoption of your language. It really shouldn't matter if you alienate a few of us old-timers who really don't have safety problems in C++.

To be clear, I like Rust. I've been following it for years, and I'm disappointed that it's not an adequate replacement for C++ (which I really don't like).

[jibalt]

"the condescending comments from beginners"

You like to make stuff up.

"If you can't see them, it might be because you're aligned with that point of view."

Or it might not. It might be that you're just being abusive and dishonest.

[kibwen]

> There're are no shortage of obnoxious comments from beginning Rust users here and on Reddit. If you can't see them, it might be because you're aligned with that point of view.

Can you give me an example of a comment in this thread that you find to be from a pretentious beginner? Alternatively, if you're calling the author of this article a beginner, I can assure you that he isn't.

[jibalt]

The guy's a troll.

[wtetzner]

> To be clear, I like Rust. I've been following it for years, and I'm disappointed that it's not an adequate replacement for C++

Just out of curiosity, what is it about Rust that means it's an inadequate replacement for C++?

[zerofan]

There are many things you could dismiss as style issues, but here is one relating to performance. Rust does not (yet) have integer generics. If I use Eigen (the C++ library), I can declare a matrix of size 6x9 and have the allocation live (cheaply) on the stack. I do this kind of thing frequently (not always 6x9), and in Rust I would pay for heap allocated matrices. The cost in performance can be huge. Maybe this will get fixed in the near future.

[red75prime]

Humans are prone to error (fine), therefore you are prone to error (condescension, not fine). Post-aristotelian logic?

I'm not completely serious, it's more complex that this.

[jibalt]

"Is that a bad thing?"

Regardless, it's a complete mispresentation of Rust, which is all that zero has to offer.