Yeah, but many of the Rust features are present in the branch of Algol derived languages, namely Mesa, Modula-2, Modula-3, Oberon derivatives, Ada, Pascal dialects....

Yet it was required decades of security exploits for developers start grasping the major flaw it was to adopt C.

Can we please stop with the C bashing already? Each time there's a story about a buffer overflow, the top comment says how that would be impossible in Go, Rust, JavaScript or the next shiny thing.

First of all, hindsight is always perfect. I'm sure adopting C made sense at the time. We didn't use to stroll down the street with a supercomputer in our pockets you know.

And second, the constant stream of news about trivial SQL injections, cross-site scripting vulnerabilities and other such things should make it plenty obvious that you can write unsecure code in any language.

Except Algol, PL/I, PL/M and many others already existed and pre-dated the computers used to develop C on.

"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously,they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

- C.A.R Hoare at his 1980 ACM Turing Award Lecture

Algol was created in 1960 and run in computers much more humble that the PDP-11.

> And second, the constant stream of news about trivial SQL injections, cross-site scripting vulnerabilities and other such things should make it plenty obvious that you can write unsecure code in any language.

Those don't suffer from memory corruption issues. So there is a whole class of security exploits one doesn't need to worry about.

True... and I bet the performance was significally slower. Also I think the portability in those languages was also limited.

Obvious, since those systems pre-dated PDP-11 hardware.

> Also I think the portability in those languages was also limited.

Have you ever coded C before ANSI C was approved?

It was only portable to UNIX itself, just like those other OSes and their systems programming languages.

Each C compiler outside UNIX implemented its own subset and semantics, hence why ANSI C had to adopt so much UB to avoid breaking too much code.

Well, I was actually referring to the equivalent running on PDP-11 (like Algol68)

> Have you ever coded C before ANSI C was approved?

>It was only portable to UNIX itself, just like those other OSes and their systems programming languages.

I meant machine portability. Before C, to have a lower level like performance you needed to use machine-specific assembly.

On workstations and mainframes there was hardly any difference to other heigher level system programming languages. In fact C prevented many compiler optimizations due to its aliasing and decay of arrays into pointers.

C gives you all those SQL injections, XSS, shellshock, etc. in addition to all memory unsafe exploits - it's a superset of vulnerabilities (actually, I'd not be surprised if C makes it worse, as the code is far, far more verbose and focused on minutia and hence higher-level logic failures are more difficult to notice.). And, going from widespread commercial software, the other issues seem to account for much less of the critical security bugs.

Even so, if they had some amazing backcompat reason to stick with C, they should have been sandboxing and otherwise limiting the impact of the apparently-inevitable, trivial memory corruption issues they're sure to have created.

The top comment made by the same person.

Though the comment seems to get reasonably upvoted, you're right that perhaps it's not a very high signal. Sorry.

Find me an unintended trivial SQL injection or cross-site scripting vulnerability in Rust. Or Elm or Ur/Web, if you prefer more web-oriented languages.

All you have done is demonstrate that there are languages other than C that one should not write in, either. But of course there are. You have not demonstrated that all languages have these problems to the same extent.

It is rather like arguing that since you can get concussions in football, and you can also get concussions in ice hockey, it doesn't really matter what sport you play. While it is technically true that you can get concussions from golf or cross-country running, it takes quite a bit of skill and (un)luck to make it happen.

Well, if there's no web support in rust, that's going to be kind of hard. There's no SQL injection "in C" either. For that matter, there aren't any buffer overflows in the C language.

Now, if you meant "in some rando web forum written in rust", I think you'll need to wait a bit. Let's wait until there's a forum with more than a dozen users, then I'll tell you how the developers fucked up.

e.g. crates.io does no such tracking, but it also just punts the problem completely to our postgres bindings and making sure to build queries separately from their args (and the postgres arg injection does escaping, presumably). But this is no static or novel guarantee. It's just Alex being a great developer and reviewing all the patches.

I wouldn't be floored if crates.io was exploitable.

Actually I know it is; [I've exploited it](https://github.com/rust-lang/crates.io/issues/176).

Rust solves many interesting problems, but it is no panacea for program correctness!

Suggesting that throwing thousands of lines worth of virtual machine behind a piece of code will solve security problems is shortsighted.

None of these have memory safety without GC (while supporting dynamic allocation and deallocation).

Mesa => RC with local GC for collecting cycles.

Modula-2 => True, does manually memory management, but avoids all other C memory corruption errors.

Modula-3 => Uses GC only for types allocated via NEW. Library contains generic RC pointers. Untraced pointers can only be used in unsafe code.

Oberon derivates => Uses GC only for types allocated via NEW. Active Oberon added support for untraced pointers only in unsafe code.

Ada => No GC. All memory allocation is controlled. Deallocation is only possible via regions or explicitly in unsafe code. There are generic RC libraries as well.

Pascal dialects => No GC. Suffer from manual memory management, but none of the other typical exploits regarding out of bounds or pointer misuse.

Yes, they may lack affine types, but had they succeed in the industry instead of C, the need of something like Rust would be greatly reduced.

As such now we have to place our hopes in something like Rust, because the new generations never heard of those languages and think C was the very first systems programming language.

However every time I look at Rust sample code I would like to see the same amount of _unsafe_ being used like in the those languages.

Instead, many Rust users seem to sprinkle it everywhere.

I'm not criticizing those languages. I think they're valid points in the design space. I'm simply saying that they didn't do what Rust does: memory safety with no GC (and dynamic allocation/deallocation).

My point is that we would be less in need of Rust, if those systems programming languages have had taken C's place.

So given that they failed to gain mindshare, except for Ada in a niche domain, we now need new alternatives.

Still be prepared for an uphill battle with C++17, as language is only part of the equation, as I learned from being in the Wirth languages side for a few years.

That's just it. Rust looks enough like C++ to catch on. This was not an accident though I can't say I'm jazzed about it.

Rust brings a lot to the table with its type system too. I would rather be using Rust tomorrow than having had the benefits of say Pascal derivatives for the past 45 years. I'm not saying this just for effect: after the obvious ML influence, the parts of Rust I like most are the nuances.

> Instead, many Rust users seem to sprinkle it everywhere.

Is that true? You will necessarily see it in bindings, or to implement certain essential features that can't be implemented otherwise. Beyond that there is the motivation to use unsafe code for speed, hopefully this is mostly restricted to modules.

Are you complaining that people are using when they could reasonably avoid it or that it is too often necessary?

They are abusing it, specially as workarounds for constraints that cannot be expressed in the type system.

While in the languages I mentioned, unsafe constructs are related any operation that might lead to memory corruption, some Rust devs are using it for anything they assume isn't logical safe.

So you then get talks like the Session Types one at ICFP, that uses unsafe to control functions being called outside the protocol Traits that are being defined.

Which lead to discussions like this one:

https://github.com/rust-lang/rfcs/pull/1236#issuecomment-136...

That doesn't sound like abuse to me, as long as the exposed interface remains safe.

> some Rust devs are using it for anything they assume isn't logical safe.

That sounds like an objection to the scope of what Rust defines as safe. Unless you mean to imply there are reasonable, Rust-safe ways to rewrite the transgressions. In the former case I have to disagree. It would be nice if we could prove more. But you can't prove everything.

I haven't seen the ICFP talk but I might watch it later if you can link to a video. I've skimmed that discussion before but you will need to point out your objections—IMO it is great that Rust devs are having that discussion.

For everything else something like contracts should be used, from my point of view.

As for voicing my objections to the Rust community, being a language geek is one of my hobbies, but it doesn't mean I will ever use those languages at work.

So I would only contribute noise to the discussions, which why I eventually moved away from Go and D forum discussions as well.

My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on.

Either you think this way because of a sense of orthodoxy or because you think memory safety is important in a way the other kinds of safety aren't. I disagree, especially since "memory safety" may or may not imply protection against aliasing of mutable data. Those nuances I like about Rust probably wouldn't exist without the broader scope of safety concerns.

> As for voicing my objections to the Rust community,

About the discussion you linked? I meant to me, in the service of explaining your objections.

> My time is already quite filled following the JVM, .NET and C++ eco-systems, the ones I get payed to be an expert on.

Well, that was important information. Thanks for making the time to share!

Memory safety is more fundamental than most other sorts of correctness: it is a necessary (but not sufficient) condition for them. If you can't assume memory safety, you have no assurances about any other invariants, because any piece of data can be modified/outdated/invalidated at any time in the program's execution. (This is especially bad if the compiler will itself assume that memory safety can never happen, and use this undefined behaviour to optimise the program in unintended ways.)

I'm fairly sure that some definitions of memory safety that works for Rust are "there are no use-after-frees" or "the language is type-safe"; all 'other' problems with memory safety (iterator invalidation, data races, etc.) can be used to violate those and hence need to be outlawed. I'm not sure there's that much wiggle room for what memory safety means, at least in broad terms. In any case, aliasing of mutable data can definitely lead to memory unsafety, and is hence covered/controlled by Rust's guarantees. In some ways, it is really the fundamental cause of memory unsafety: remove/control either "aliasing" (e.g. Rust, many GC'd languages) or "mutable" (e.g. Haskell) and you've got memory safety.

Also, Rust definitely doesn't only try to help the programmer with memory safety, it's just memory safety (and hence type safety) is the form that has hard guarantees. Other forms are generally handled by "lints"/warnings or by building libraries on top of the type system.

Eventually, effects would be nice to mark other kinds of "here be dragons" as well, but for now, unsafe == possible memory unsafety.

I was trying hard to have a conversation while avoiding arguing about semantics, so thanks for that.

Some of those students tried their way into the recent workstation market using what they knew from their university. Sun was such case.

Back in those days we payed for development tools, so everyone used to stick with what the OS vendors had, why shell out money for another language that implied the extra effort of writing bindings.

So like the mobile and browser space nowadays, C as the UNIX language was the way to go.

Meanwhile, those university students and professional coders with access to UNIX at the university and work, wanted to be able to take work home.

So C dialects that where able to be used in the tiny home computers started to be developed and distributed over code listing in magazines, books and BBS.

When UNIX eventually took over the mainframes market, C got into the same spot like JavaScript in the browser.

The other languages, just like any systems programming language had their OSes, but they failed against UNIX. And as I mentioned before back then you needed a very good reason to convince someone to pay extra for compilers that weren't part of the OS SDK.

What more secure languages besides C are easy to call from C/C++ codebases? afaik ocaml isn't, at least in the sense that I don't think you can produce a c lib without sucking in the ocaml allocator and other stuff [1].

[1] http://www.mega-nerd.com/erikd/Blog/CodeHacking/Ocaml/callin...

If you're writing security code, put down the damn C.

(I mean, my personal opinion is just flat-out put down the damn C anyhow; even non-"security code" has a way of turning into security-sensitive code when you're not looking. But certainly if you're writing security code.)

Though Kapersky would have been better off even using C++/CLI and "It Just Works" to hook into code written in, say, C#. The IJW stuff is cute, as it seamlessly brings the CLR in-process and lets you transition from native to managed without noticing. (And MSVC's C++->CLI targeting is good enough to compile MS Office except producing MSIL instead of native code, fwiw.)

One of the big problems with C++ is that few people actually do this. It basically requires putting a linter into your build process, to check for C-isms and unsafe C++ behavior. Otherwise, people will use these things because they are easier.

My favorite thing about Rust is that it's carefully designed to make the safe things easier. It's much better if you need to go out of your way to do something dangerous than the outher way around.

Which is one reason, why although I like C++, I am happy to only use it in side project, and mostly settle with JVM/.NET stuff for work nowadays.

Most of the enterprise code bases I have seen on my career, are mostly C with Classes style and most companies don't use analyzers. I was quite happy when Clang introduction started to change the mentality in regard to analyzers.

Java had a basic arithmetic bug until what 2005? Bash shell had a serious bug until last year?

The people developing these software are all 10x smarter than you.

We have powerful computers these days. Software is eating the world. Let it eat the process of writing correct software, too.