I take issue with the notion that languages can have competitors. Languages are tools, and some languages are more suited to some tasks than others, but each has their place.
Saying languages compete with each other is a bit like saying different kinds of hammers compete with each other. They don't, each is just optimized for a different kind of hammering.
Your productivity in any language is directly proportional to your time and effort investment in it. It's in your best interests to pick the language that's likely to thrive and spend time learning its ins and outs. On the flip side, betting on a horse that doesn't win could mean the loss of months or years of effort. This is why people evangelize the platforms they're invested in - convincing other people to join improves the health of the platform, increasing their return on investment. More adoption => more libraries => more projects => more jobs => more adoption. A virtuous cycle.
This evangelizing can sometimes become contentious if others perceive it as an attack on their platform. People defend their language mostly because they don't want to see it lose popularity. If it did, their language's viability is threatened and their investment is in jeopardy.
It's also partly because they've spent so working with this language that it's become a part of their identity. A critique of the tool is perceived as an attack on the person.
Developers do get emotionally invested in their tools, and I've seen an uncountable number of holy wars because of that. But all of them strike me as being ludicrous.
If another dev uses a language I would not have chosen, that's not a personal affront to me. I assume they made an engineering decision that made sense for their situation. It's all good.
> If it did, their language's viability is threatened and their investment is in jeopardy.
I sorta see this, but in my experience, it's very easy to overstate this case. If a language is viable enough to develop in initially, it's viable. How popular it is or becomes isn't really that important except in terms of being a business decision ("is it possible to hire people in the future who know this language?")
https://www.nytimes.com/wirecutter/reviews/best-hammer/
Sure they do.
If you're doing framing, you might prefer a rigger's axe or a framing hammer.
If you're hanging an axe, you might prefer a mallet or a dead blow hammer.
There's lots of overlap, and hence competition, between different hammer types.
You are both correct, but I was using "competition" in a different sense. I was thinking in terms of how people often talk about these issues: as if there was a One Language To Rule Them All. That is the notion that I object to.
When considering the best tool for a particular job, the different contenders are competing in a sense for that job. But I see that as not being the same as when people are asserting that a given language is always the superior choice independent of the task at hand.
The responses to my initial comment really surprise me. I had no idea I was saying anything controversial, but apparently I am!
Then someone invents a hammer. You no longer use a rock for driving nails.
Then someone invents a can opener. You no longer use a rock for opening cans.
Then someone invents gigantic sledge hammers. You no longer use a rock to smash things.
Languages definitely have competitors. Java took a lot of projects that would have otherwise been written in C++. Rust will take a lot of projects that would have otherwise been written in C or C++, but languages like Java weren't suitable for. Eventually, those two languages might be completely supplanted (but it would take a very long time). Because they lost to competitors in each space.
Some languages can certainly become obsolete (although even then, I'm hard pressed to think of a language that is no longer used at all) or relegated to very niche uses, of course.
Just stop. Programming languages aren’t like carpentry tools at all.
For a programming language to survive you need a critical amount of users so that they can support each other by teaching each other, writing libraries, and influencing management in private and public industries to adopt the languages that are wanted. That naturally leads to at least some competetition for mindshare among developers, even (especially?) among the grassroots.
Just let this lame analogy die already.
Like the strawman argument where it creates a flawed argument to declare victory over, the strawman attack picks out the most extreme case to declare victory over
You'll see this done on left/right political debates where instead of recognizing that most people can find agreeable common ground on 80% of issues, extreme advocates will pick out the opposing extreme advocates to vilify each others' groups
I think a lot of Rust programmers appreciate where C is the right tool, & a lot of C programmers can admit that memory errors are a pain in the ass
That's true, however IME C++ programmers are the most in denial. And yes, RAII has helped a lot. But still we see way too many memory errors coming from C++ code bases.
The first F in FFI [1] means that you have an interaction of non-Rust and Rust. (Or two non-Rust languages but that's moot).
[1]: https://en.wikipedia.org/wiki/Foreign_function_interface
FFI is inherently unsafe regardless of language.
The standard library and ecosystem follow the philosophy of making it easy to do the right thing, and preferably impossible to do the wrong thing; made possible by a very expressive type system. Of course logic bugs are possible in any language, and I wouldn't suggest rewriting a battle-tested Java application in Rust. But if you are already committed to rewriting (or starting a greenfield project) then Rust is a good choice for more reasons than just memory safety.
While that's true, memory safety bugs are particularly dangerous from a security perspective.
IMHO the big advantage here is not languages that are memory safe, so much as catch many of those misunderstandings at compile time, or runtime in a better way than "Crash" or worse - silent corruption (Much of this is available for c++ in static analysis and sanitizers and other runtime checks, but them being non-default options seems to make them oddly ignored). I feel them being non-default also means there isn't the same focus on performance - and it's an everything-debug-and-slow-as-hell with a UX purely designed around the dev debugging their own code, or no-checking-at-all-no-brakes rather than in between.
The classic "memory errors" that are purely local and just not checking the bounds of an array or similar have been pretty much eliminated if you actually use the features (containers, iterators etc.) of the c++ standard library.
> better way than "Crash" or worse - silent corruption
My point is that the current crop of c++ compilers and standard library implementations have the ability to check for the vast majority of these issues, just they're relegated to non-default "debug" options.
Just flipping that, so you had some level of checking on by default and you had to explicitly ask for "Go fast and break things" mode would help - as it feels like the vast majority of native code doesn't need to get that last few percent. And even that is questionable, I remember doing some (micro-)benchmarks on simple stuff like array bounds checking and the performance difference on modern big CPUs was pretty much within noise. Maybe it's a big deal on microcontrollers or small embedded systems, but that's the "I Know What I'm Doing" non-default mode is for.
My apologies, I could have sworn that your text was 'better way than "Crash" <end>'. And not in fact, 'better way than "Crash" or worse - silent corruption'.
Although, silent corruption is a possible problem in memory safe languages. True, memory safety gives you some sort of protections, but threads and/or setting the wrong value can still give a memory safe corruption.
No, I was talking about the ability for an attacker to craft malicious input such that a memory unsafe program begins executing that input as if it were the program. Something that you generally do not have to worry about in a memory safe language.
Security of technology is really a process, not a boolean. "Memory Safe" doesn't mean "Safe", and "Not the current crop of Memory Safe" languages doesn't mean "Unsafe". There's so much we can do with the tools we have right now to help with current codebases and apps, too many people seem to have the idea you have to do a ground up rewrite using the latest and greatest language, or you're an idiot and/or lazy.
Honestly, the whole world isn't going to be rewritten in rust tomorrow, imagine the time and effort that would take and all the other errors a ground-up rewrite of well-tested systems would cause. But we can probably rebuild 90% of the existing world in a "Safer" manner right now. We should be promoting that too, and not let perfection be the enemy of better.
> But we can probably rebuild 90% of the existing world in a "Safer" manner right no
I strongly agree with this mindset. The only caveat I would offer is that some architectural structures that c and c++ allow probably don't amend themselves to fixing even if you can detect them.
Although just like you can write any language horribly, I think you can write almost any language well.
It's hard to see how tools that allow you to do that can be a bad thing. I'm certainly not going to be paying to rewrite everything from the ground up in rust or otherwise.
Same thing with features. Fewer, better-vetted features mean more secure systems.
C encourages better, simpler designs, but at the cost of making it nearly impossible to write safe code. Garbage-collected languages remove entire classes of errors, but they make it easier to implement lazy, unnecessarily complex designs.
Maybe Rust offers the best of both worlds? (I say this mostly but not entirely tongue in cheek.)
AFAIK Rust's solution for tree/graph is to replace pointers by indexes. IMHO this is worse because if you get it wrong with pointers you may have a core, with indexes you just get silently the wrong node..
Is it? Large companies with huge code bases (meaning lots of statistical significance) have said 70 percent of their CVEs could not have happened if that code was written in Rust. Not only are those kinds of errors very common, they can be IMHO a pain to debug.
So given the prevalence of memory safety issues, why do you find it important to remind people that other kinds of bugs exist?
At a point, one surgeon discovered that, with incontestable proof, and started advocating for hand-washing. When almost all surgeons noticed that something so simple and easy had that much impact, they immediately adopted it and saved a lot of suffering from their patients...
Ok, of course they didn't. Almost everybody fought the few wand-washing advocates, tried to shame and discredit them, tried to generate bullshit evidence saying that it didn't help, tried to convince everybody that it didn't matter, all the time denying to themselves that it worked. Surgeons only started washing unanimously their hands when that generation of them retired.
> Despite various publications of results where hand-washing reduced mortality to below 2%, Semmelweis's observations conflicted with the established scientific and medical opinions of the time and his ideas were rejected by the medical community. He could offer no theoretical explanation for his findings of reduced mortality due to hand-washing, and some doctors were offended at the suggestion that they should wash their hands and mocked him for it. In 1865, the increasingly outspoken Semmelweis allegedly suffered a nervous breakdown and was committed to an asylum by his colleagues. [...] His findings earned widespread acceptance only years after his death, when Louis Pasteur confirmed the germ theory, giving Semmelweis' observations a theoretical explanation, and Joseph Lister, acting on Pasteur's research, practised and operated using hygienic methods, with great success.
I am not very familiar with Rust, but I thought it permits full control over memory?
I can't think of any. The borrow checker still checks your code but you can forge, twiddle, and cast pointers, there's really nothing you can't do that I can think of.
> In both unsafe functions and unsafe blocks, Rust will let you do three things that you normally can not do. Just three. Here they are:
> Access or update a static mutable variable. Dereference a raw pointer. Call unsafe functions. This is the most powerful ability. That’s it. It’s important that unsafe does not, for example, ‘turn off the borrow checker’. Adding unsafe to some random Rust code doesn’t change its semantics, it won’t start accepting anything. But it will let you write things that do break some of the rules.
Undefined behavior is a completely separate conversation. UB is necessary to output performant code. If dereferencing a null pointer were defined behavior, then the compiler would need to insert a check for every dereference, which would slow down your code.
Hum, no, unless you count inline asm, it simply doesn't.
And for more control over memory than C, Rust allows mapping high-level types into fixed memory, so the compiler can actually use the correct asm primitives and make your access fast. On C you either have to use a general purpose array abstraction or try to map your types over the memory and pray the compiler resolves all the UB the way you want. Most C developers do the later.
For projects where you do need rust, obviously "This is literally impossible to do any other way" takes precedence over "It's best practice to do it this way", but the rest of the time.... I'm not sure I see the tradeoffs unless you're doing some crazy hand optimized low level library, or you just have a strong preference for direct control.
The existence of Redox OS in my mind is enough to prove that Rust can do just about anything and lower level stuff is needed less than people seem to think
Then again, I haven't worked much with Rust, it's only just now supported on any platforms where I'd have a reason to use something lower than JS/Python.
Performance matters in every project, and the way you get performance on modern processors is by using the cache effectively. That requires a certain amount of control over memory layout and access.
It's not so much about what's possible in a given language, it's about what features you're using and what features are getting in the way. Sure, you can write a bunch of unsafe Rust, but at what point are you fighting against the language and adding unnecessary friction?
High level languages are good at enabling high level optimizations like caching and special case handling of things, which might be a bigger gain than anything to do with memory layouts except in a few inner loops.
High performance and reasonably focused low complexity stuff might be a good fit for C, until compilers get even better.
But in a web browser? I guess time will tell, but my guess is the ability to more effectively manage complexity will let people do more high level optimizations with less fear of buffer overflows from more code.
Things like "In this specific case I can fall back to this very simple plaintext rendering for this one section" might save more CPU than "We made all rendering a bit faster" especially if you just keep doing the performance critical stuff in C.
Those that fought against a new idea are colleges of those that fought for an idea and colleges of those that are ambivalent to the idea
This talk is what convinced me to move to Rust definitely. The audience is the perfect representation of the C++ community.
I can count with my fingertips exactly zero times that has happened to me. The times my personal information was compromised happened to me is when I downloaded malicious software. Malicious software doesn't care whether your process has "memory safety", it'll extract anything from the processes memory it wishes. Sure memory safety would at least rule out simple binary exploits, but to be targeted by one is not exactly common.
I don't get the narrative of an ever increasingly threatening world. If anything things have only been getting better, at least for the individual users. I remember individuals getting pwned very frequently in the old days. Now, not so much, with DEP, ASLR, and stack canaries. The attacks on businesses have increased, but those attacks are mostly just phishing or otherwise human error related.
Attack vectors for actual PI retrieval rarely incorporate some obscure memory bug in a program allowing RCE or remote access. Unless you're a high value target.
It happens with some frequency. WhatsApp was exploited due to a memory safety vulnerability, for example. Chrome 0days for memory unsafe vulns are definitely exploited in the wild.
Typically companies have much much larger attack surface, so a technique like phishing is going to be far cheaper to execute. But even still, I've seen a memory safety vulnerability used in an attack against a company.
The thing is that most companies' attack surface isn't in C/C++ because... that would suck, so they don't do it. Or if they do they use a specific codebase that's been heavily invested in over decades and they sandbox and isolate the services.
So on the one hand, yes, most attacks on companies are not due to memory safety issues but that's in part because of the investments into memory safety.
> I remember individuals getting pwned very frequently in the old days.
Yep, significant efforts were made to make the internet a safer place. Primarily the sandboxing and disabling of third party plugins in browsers.
But this doesn't really matter. Yes, there are other issues like phishing and those are being addressed with other techniques. There are issues like sql injection and those are also being addressed. That doesn't mean that memory safety isn't an issue.
The snark is really offputting. As a user of software trying to protect my personal information in an increasingly threatening world, I would like memory safety in more places. From the outside looking in it feels like there are a lot of C and C++ programmers trying to deflect from how poorly their attempts at memory safety have gone and just snarking at the people trying to fix it.
I will say that the point about FFI boundaries needing more care is a valid one I had not considered.
Is there a name for people who don't work in C++ and never, ever hear "rewrite it in Rust" except from programmers who seem like they're a bit hurt that their language has a competitor?