Hacker News Reader

> I’d love to see a survey talking about what bugs get actually solved by using one of these modern languages like Rust or Swift, since i personally never once in my career had a bug that wouldn’t have happened if i used const, let alone any of the many other annoying Rust features.

A quick analysis I did showed that half of the critical security vulnerabilities in Gecko would have been prevented by writing content and layout code in Rust. The other half were mostly JS issues, often having to do with built-in APIs that would also be safe if appropriately written in Rust (or self-hosted).

> For a “systems programming language”, Rust doesn’t let you do anything i’d expect, like let you specify whether a signed integer is 2s compliment, and how it behaves when it wraps.

Well, this definition of a systems programming language excludes C.

> Instead the programmer is at the whim of the compiler writer, same as in C, and its “undefined behaviour” which is a source of real, hard to track bugs.

Nope. Rust defines signed overflow. http://huonw.github.io/blog/2016/04/myths-and-legends-about-...

> Rust doesn’t even have support for modern features like wide registers

What is a "wide register"? Do you mean SIMD? If so, it sure does [1].

> or any features that help you deal with raw memory, it just marks it as “unsafe”.

Sure it does. Rust helps you deal with raw memory by freeing you from the need to deal with raw memory in the vast majority of occasions. For example, in C you have to mess around with char pointers to operate on strings. In Rust you don't.

> There aren’t even any basic meta programming features like struct introspection.

That's what custom derive is for.

[1]: https://huonw.github.io/simd/simd/

Alright, thanks for clearing that up. I missed those in the documentation, since it doesn’t specify any of this directly.

Though, still wide registers aren’t a language feature. I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”. It doesn’t. The types of problems you solve by introducing built-in string types and vectors aren’t problems in the first place. The problem is writing custom allocators for the data you have, and needing some basic bounds checking. Problem is working with structures of arrays instead of arrays of structures, because that can get messy and introduce basic typing bugs. I’d love to see any modern programming language at least make an attempt at making working with raw memory easier.

Clearly you haven't done even basic research into Rust. That's OK, but I don't think you should be spouting off in HN comments about how useless it is.

Rust is all about memory safety. The borrow checker gives you compile-time memory safety guarantees (sans unsafe blocks). The address of the struct you passed to some function which then took the address of an inner field and populated a value in a returned object? Yeah... Rust knows whether that's safe or you've set yourself up for a dangling pointer. Bounds-checking is child's play to Rust.

The bulk (if not the majority) of high-impact security vulnerabilities are related to memory safety in some form. Rust eliminates those as an entire class of problem.

I went through all the Rust features. It doesn’t eliminate memory safety issues at all.

What's a specific memory safety issue Rust has outside `unsafe` code?

The memory safety issues happen inside of “unsafe” code, thus it doesn’t eliminate memory safety issues.

I don't think this is a useful point, because by the same logic:

- Haskell doesn't eliminate memory safety issues, they happen when using unsafePerformIO (or Foreign.*Ptr, or inside the runtime, your choice),

- Python doesn't eliminate memory safety issues, they happen when using ctypes,

- JavaScript doesn't eliminate memory safety issues, they happen when calling into the C++ code of the browser,

- Java doesn't eliminate memory safety issues, they happen when using JNI.

All languages have some sort of escape hatch that can be used to drop to a lower level, in order to actually interface with the operating system (etc.), Rust is slightly unique in that it makes this escape hatch fairly explicit/prominent at the language level and also provides the power needed do that interfacing/implementation itself (additionally, one gets all the normal benefits of Rust inside `unsafe`, the feature just lets one do more, not change the semantics of existing code).

I never said i expect Rust to fix any of these problems, i would however expect it to at least try and introduce helpful constructs, instead of the ultimatum approach that every other language takes where you either program as expected or face the consequences.

It does provide a pile of helpful constructs (references, slices, generics, privacy), which, if they don't work 100%, are still brilliant building blocks for creating abstractions that expose safe interfaces, allowing the areas where "program as expected" is required to be concentrated into controlled areas/libraries. (And, all those features still work in the unsafe code, helping the programmer get it correct.)

It works really well in practice, even if it isn't bulletproof... there's nothing to stop a programmer typing 'unsafe' to side-step the safe interfaces in random places, but one quickly learns this is usually just heaping unnecessary debugger work on oneself, to track down little mistakes that the compiler would normally point to directly.

Some people say "half a hole is still a hole". To which I reply "but it's a much smaller hole".

> I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”.

I do. Am I a bad programmer?

> The types of problems you solve by introducing built-in string types and vectors aren’t problems in the first place.

Buffer overflows aren't problems?

I’m not saying you’re bad. I’m saying there’s always a point where you want to go down to managing your own memory when performance is an issue, and no amount of language features is going to change that.

What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it. Writing my own growable data type using malloc and free is something i can do once, and i just have it, it’s not something that i have to worry about for more than 5 minutes at the beginning of a project.

> What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it

You have that.

For example, if you have contiguous memory, the various forms of the [T] slice type can be used, they don't impose any allocation expectations. (And, once the standard library allows pluggable allocators, you'll likely be able to use Vec directly, for a growable vector type.)

If you don't have contiguous memory, then it's a bit more work, but one can still use features like generics and privacy to spend a few lines building abstractions that bounds check in the right places. It's not like using a proof language to extract a program that is guaranteed to have no out of bounds accesses, or a compiler that some how deduces what the bounds of your data structure is, but the former has its own complexity downsides, and the latter seems infeasible, in general.

None of the things you mentioned, other than the slice type, which i don’t see how it would work on raw memory, are a language feature.

As I said, a slice can point to any memory, it doesn't matter where it came from: i.e. your allocator/things using it can expose slices instead of just plain pointers.

Generics and privacy are definitely language features, and they're core to the ease with which one can create abstractions. Rust is a systems language, it tries to give programmers the power to create their own safe abstractions as needed.

I wasn't talking about that. What i meant was, if i have to implement it myself, that's not a point in favor of Rust. Though the slice does help with rudimentary bounds checking, so that's a start, though i don't see how that differs from a generic accessor method or an overloaded operator.

A programming language can't anticipate every possible thing someone might want to do (or else every program would be one line: doMyThing()), the best it can do is provide tools for building the final product. Rust is pushing hard on making it easy for people to build safe, zero-cost abstractions that are reusable, via generics and especially cargo, so you often don't have to implement things yourself (or: don't have to implement things yourself twice), even if it isn't literally in the language.

> though i don't see how that differs from a generic accessor method or an overloaded operator

Err, it does all the bounds checking automatically? I thought you wanted these features without having to implement them yourself, but apparently writing accessor methods or an overloaded operator is OK too?!?

Why would it be safer to implement Vec as a "language feature" as opposed to implementing it in the library?

We actually used to implement Vec as a language feature, and it was a lot of work to write things like growth in raw LLVM IR (which is a miserable programming language) instead of just using a real programming language—Rust—to do it.

Never said any of this.

Not everyone has the privilege to be a single C coder owning the code without anyone else from different skill levels coding in it and without any additional use of third party libraries.

You've never hit a NPE or null pointer? Data races or use after free?

Const is nothing like references, not even close. I would suggest you spend a bit more time with the language to better understand exactly what Rust brings to the table.

The number of cases where i have to use a generic memory allocator like malloc in a typical project are extremely rare, so no.

I never said that const is like anything, i just used it as an example.

One can get all of the problems mentioned with allocators other than malloc, up to and including using only the stack.

Also, sure the implementation of another allocator might use a smattering of `unsafe`, but I'm guess that it will be less than you probably expect: one of Rust's biggest is strengths is the ability to build safe interfaces for things without performance cost. One can see an example for this in http://os.phil-opp.com/ where the author is slowly describing creating an operating system, all while concentrating on how to exploit Rust features to let the compiler help the programmer, such as http://os.phil-opp.com/modifying-page-tables.html .

What does malloc have to do with anything? Returning a pointer to the stack is just as likely to break everything if done improperly. Moving or copying a struct that points at itself is also going to break.

In fact, "how to to either of these things" is such a common question for new rust programmers trying to solve their borrow checker complaints that it constitutes pretty good evidence people are doing these things all the time with little understanding of why they are problematic.

And even if you _do_ know better, circumventing the borrow checker is fairly trivial.

>Returning a pointer to the stack is just as likely to break everything if done improperly.

How's returning a pointer to stack ever safe?

I published a regex library for Rust a few years ago. Since then, it's been downloaded a million times and used in over 300 published crates. I've had 0 reports of seg faults or buffer overflows.

Can regex libraries written in C say the same? I don't think so.[1]

[1] - https://www.cvedetails.com/vulnerability-list/vendor_id-3265...

I'm sorry, I have plenty of gripes about the Rust team touting safety as much as they do but your comment just misses the mark, in my opinion.

To begin with, "safety" isn't solved by just using const. It simply isn't feasible to write safe code in C without restricted feature usage to the point of being crippled. It's much easier in C++, but requires an incredible level of focus and "cruft constructs" like ' 'const &' and such. Arguably until move semantics were standardized with C++11 it was a challenge to write safe code.

I will agree that Rust's developers have perhaps come down too far on the side of "YOU ARE DOING SOMETHING DANGEROUS BY USING A POINTER." But I think you're exaggerating a bit about how hard it is.

Supposedly Swift 4 is introducing an optional borrow-checker. Types can opt-in and you get the same kind of lifetime guarantees and semantics as Rust. If you don't opt-in you get copying for value types and reference counts for reference types.

I'm curious how either approach will work out in the long run. I understand why Rust made the decisions it did wrt ditching built-in GC/non-GC support but it will definitely hamper its adoption for writing GUI applications. If Swift manages to thread the needle in supporting systems-level / kernel programming with borrow-checked types while not imposing that mental and maintenance cost on GUI apps it will be an amazing thing.

In any case it is exciting to see high-level languages with memory safety proving you can have something much better than C without going full-on virtual machine, runtime, and JIT.

> In any case it is exciting to see high-level languages with memory safety proving you can have something much better than C without going full-on virtual machine, runtime, and JIT.

Check Modula-2, Oberon, Component Pascal, Modula-3, Eiffel, Ada, Delphi...

It was a mistake to have Java and .NET go JIT only on their first days, instead of AOT/JIT from day one.

They are finally steering the boat in the right direction, but it will take a couple of years, assuming they don't loose focus.

My point was that i haven’t come across a Rust feature i felt would save me from creating a bug.

Rust isn't a panacea, nor does it claim to be. It doesn't prevent bugs. It prevents memory safety bugs.

> nor does it claim to be.

"It" doesn't do anything. But some of its fans conflate "prevents memory safety bugs" with "panacea", at least by implication, as I perceive it.

Besides, right now a lot of the "memory safety" of Rust has much more to do with selection bias (it is used primarily by people who are explicitly interested in using its safety features). When one uses exclusively (or almost exclusively) the "memory safe" features of the language, of course things implemented in it will be free of "memory safety" bugs. Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things.

Here's how I see Rust: it's far and away already superior than C++ for a certain class of systems application programming (e.g. performant desktop/native application code that sits at the systems boundary). Rust code that seriously competes with C or C++ for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs. If it gains traction "in the wild," my prediction is we'll start seeing plenty of "memory safety" bugs in that area. The question then is how easily they're spotted and rectified.

> But some of its fans conflate "prevents memory safety bugs" with "panacea", at least by implication, as I perceive it.

While you may be right, I have never seen this happening (and I participate a lot in online discussions about Rust); people seem to be very careful about saying that Rust prevents memory safety bugs, not bugs in general. People do say that the type system _helps_ prevent general bugs, but that's only to the extent that any similar or more powerful type system (Haskell, xML, etc) can.

> Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things.

I mean, yeah. No language can (unless it avoids FFI entirely). See https://news.ycombinator.com/item?id=12877136

Rust gives you the tools to prevent yourself from doing unsafe things (and still be able to write software).

You can get a lot of stuff done in safe Rust. When you need to drop down to unsafe Rust, you can design safe abstractions around the unsafe code, and manually verify the safety of the abstraction. This has a human component, so it's not perfect, but it's pretty close :)

The unsafe feature isn't just there for explicitness, it is designed to provide the ability to do this -- the ability to design safe abstractions.

> for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs.

Designing an operating system low level enough? There are a bunch of initiatives to write an OS (both serious and as a learning project) in Rust. As far as I've seen, all of them avoid unsafe code like the plague and design safe abstractions around everything so that they only need a smattering of unsafe code. os.phil-opp.com has a bunch of blog posts on OS design in Rust, some of which explicitly demonstrate this pattern (e.g. the page table one).

When you say "When one uses exclusively (or almost exclusively) the "memory safe" features of the language", you're talking about basically the entire target audience of Rust, and this includes low level users. Rust isn't supposed to be used with lots of unsafe everywhere; and folks have tried hard to make it so that this isn't necessary even for low level applications (the Zinc project, while no longer maintained, is an example of this for embedded software). Of course there are areas where you'll be using more unsafe code than others, but you're still supposed to be "almost exclusively" using safe Rust code. If you need unsafe everywhere for your low level application then that's something you should bring up with the Rust community. (To be clear, the Rust ecosystem and language right now has some issues that crop up in low level development, but these are being worked on)

In fact, there is only one place where I've seen unsafe code being sprinkled around liberally, and that's when binding to a C/++ library. Currently my job involves a lot of this, and I'm trying to make it safer (largely succeeding!), but it's still has a higher density of unsafe code than, say, Phil's Rust OS (or I think Redox, but I haven't looked at that in a while). In this case, though, you're already talking to C/++ and there's inherent unsafety there (plus an impedance mismatch), so you can't always blame Rust for it :)

------

I guess you're right that "Rust prevents memory safety issues" isn't 100% accurate because `unsafe` exists. "Rust gives you the tools to prevent memory safety issues" might be more accurate, but still misses nuance. I think for a soundbyte on Rust it's accurate enough to say (because it prevents these issues more or less as much as possible without being useless for writing software), but it's a caveat that we should probably mention more.

I haven't, either. I've come across plenty that would save me from having painful gdb sessions to fix code inexperienced (or lazy) developers write.