You seem like a forthright person, but with or without metaphors, we're still talking past each other.
My point about remote exploits, airplane crashes, and cops is not about me. Yes, public facing software needs to be careful, but (fun metaphor) that's like saying prostitutes should use condoms. Web servers, browsers, firewalls, and the like are built specifically to communicate with untrusted entities. That's some of the most promiscuous software out there, and yes it gets exploited. But most people don't need to use condoms with their wives, and nobody is going to exploit software a newbie wrote and runs on his home computer. Safety should not be the fundamental criteria for a newbie programmer to choose a language and learn how to write fibonacci or hello world. When they're ready to write nginx, then they should be careful.
My point about the questionable productivity gain and safety was a reply to your estimate of the billions of dollars lost. If you're not more productive, and you aren't really safe, then you aren't going to save those billions.
> What, you can't use that explicit separation of what is known safe and known unsafe to point out computational problems and ways they can be solved? I find that hard to believe.
I didn't say anything like that. We're talking past each other.
> Unless you think unsafe is Rust but "lesser, not really". It isn't. It's part of the language.
(Metaphor time again) I've got a really safe bicycle. When the safety is on, children can't get hurt while riding it. If you care about the safety of the world's children, they should use my new safer bicycle. Oh, but you can't pedal it on paths I don't provide unless you disable the safety. Is my bike really that safe?
I have no idea how many people compiled and ran a program today. It's probably millions. Bayes's theorem might be a useful way to normalize that long list you linked. I don't see a single program from a home programmer on that list.
> > The city I live in now has many bike paths, completely separate from major roads.
> Which wasn't the point of that at all. It was to point out that you[r] assessment of how much time is wasted working around problems in each case is irrelevant given your vastly different experience levels.
That was almost my exact point, and it's odd you're repeating it back to me. I guess I could've laid it out more plainly.
> [Metaphors] Driving it into irrelevancy through focusing on minutiae is a useful rhetorical trick. [...] at the extreme end if done purposefully is not acting in good faith
Using a metaphor is a rhetorical trick. If you want to explain something to a non-technical audience, maybe analogies "get the hay down to the horses" so they can have at least a limited understanding. However, we both seem to understand programming languages so talking about roads obfuscates the discussion, leaving me to wonder whether there really is a parallel between the two topics. I know more about programming languages than I do about bike paths.
> Depending on the segfault? I could. It would take me a lot of work, because it's been nearly 15 years since I paid much attention to that, but I have done it before.
Even if I offer to run malicious data, it sounds to me like a low probability event - probably lower than my being in an airplane crash or shot by a cop. It's not something I should fear today. Over the last 25 years, I've had lots of segfaults, but I think I've done the most damage by accidentally overwriting files. I'm a little afraid of that.
> No, you don't optimize your life around them, but you might also support checking of identities on international flights to prevent access to your nation from known terrorists.
No, I definitely would not. It's very easy to get into this country, and an organized (dangerous) group would have no more difficulty than the drug dealers do smuggling cocaine. There is no benefit to harassing millions of citizens if you can't actually stop the problem.
> Here's the thing. It's not about you.
Are you suggesting the only people allowed to share their experiences in a thread like this are new programmers and the people pushing their language? I was new once, and I survived lots and lots of segfaults. Don't you think neophytes should hear that? They're definitely getting a large dose of doom and gloom about the bad old days.
> Some percentage of C and C++ programmers are neophytes. [...] I think that reducing this has such a large impact, that this is of vast benefit to society at large (given the botnets we are currently seeing), and would total billions of dollars.
In one of your other comments, you indicated you haven't tried Rust yet. You should - you sound interested. It definitely has its nice parts. However, I don't think you will find the safety features to be a big productivity gain, and you will have to use unsafe code to accomplish tasks from a freshman level computer science book. Think about that - you can't cleanly use the safe subset of Rust to teach computer science to beginners... (you could do it with a lot of compromises)
I think you have an inconsistent threshold for civility. The post I replied to had it's fair share of snarkiness, insincerity, exaggerations, and patronizing.
> 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.
To me, Rust's &str seems a lot more like const char* (with a size tacked on for bounds checking). But you're the expert, so if I did agree they were the same, then C++ adopting it in the STL is practically proof it's a mistake in Rust.
You never addressed my other "too clever" items in Rust. Does that mean, other than strings, we agree?
Who are you fooling? I'm well aware of the author's history with Rust. Sorry if I confused you. Do you support his "experienced" view that all of the C or C++ programmers who don't put a particularly high value on safety are either ignorant or negligent? Now's your chance - take a stand and support your team mate!
> Can you give me an example of a comment in this thread that you find to be from a pretentious beginner?
No great examples in this thread. Does that mean I'm wrong?
> 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.
> 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.
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.
Sorry, next time I'll say something like "If you're going to misrepresent his intention" so as not to confuse a quoted sentence. And I won't use the word "say", because clearly nobody says anything in a text forum. /s
I find it very obnoxious when people exaggerate what someone else said so as to make it easier to contradict. I gather you don't have any problem with that? Yet you do have a problem with people calling it out as bad behavior? Are you sure you know why you're policing anything?
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.
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.
> 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.
> 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?!"
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?
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.
> > 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).
If you're going to put words in his mouth, you should make them much stronger words. It's not a valid argument either way, but it'll seem more dramatic. (He didn't say either of your quotes...)