Comment by pcwalton | Hacker News Reader

Comment by pcwalton | Hacker News Reader

Parent Full thread

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

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

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.

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

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

Reply on news.ycombinator.com