61–70 of 76 posts
Earlier quoted context omitted.
His point is probably UNIX didn't won -- Linux did.
Linux is non-certified copy of UNIX, without POSIX it wouldn't matter in the marketplace, ergo UNIX won.
Earlier quoted context omitted.
Linux is non-certified copy of UNIX, without POSIX it wouldn't matter in the marketplace, ergo UNIX won.
As you can see in the wild, nobody really cares about UNIX certification. Ergo, UNIX didn't win.
Of course we can play semantic games about the use of UNIX word, and GNU/Linux not sharing any code from either BSD or AT&T linage, it doesn't make it any less UNIX.
Had Linux not copied UNIX, and provided a playground for UNIX vendors kind of outsource their development costs, it would have turned out to yet another hobby OS.
Earlier quoted context omitted.
It's probably not quite equivalent but I believe Frederico & al found & fixed a number of issues when they converted librsvg to rust. You may want to check the archives on their blogs (IIRC it's split between Frederico's own and the librsvg one) for more, or specifics. But "safe" rust at least intrinsically protects from use-after-free, double free, dangling pointers, null-pointer dereferences, out-of-bounds accesses…
While I do believe that rust will prevent many memory safety issues. I think you would probably catch a bunch of safety issues rewriting any code.
As well as introduce new ones.
Earlier quoted context omitted.
It's probably not quite equivalent but I believe Frederico & al found & fixed a number of issues when they converted librsvg to rust. You may want to check the archives on their blogs (IIRC it's split between Frederico's own and the librsvg one) for more, or specifics. But "safe" rust at least intrinsically protects from use-after-free, double free, dangling pointers, null-pointer dereferences, out-of-bounds accesses…
All of the pointer issues you mentioned have already been solved in C++ by unique_ptr.
- std::move out of a unique_ptr x and "*x" is a null pointer dereference,
- take a reference into a unique_ptr, and it becomes dangling if it is held after the pointer is deallocated,
- an T[N] array doesn't get bounds-checked whether or not it is stored in a std::unique_ptr (it is nice that it reduces the number of raw pointers flying around, which likely does reduce the number of out-of-bounds accesses, but it doesn't solve them)
Earlier quoted context omitted.
While I do believe that rust will prevent many memory safety issues. I think you would probably catch a bunch of safety issues rewriting any code.
I think you would probably catch a bunch of safety issues rewriting any code. As well as introduce new ones.
Even though I am a believer I would love to see some solid evidence of Rust making code safer.
Earlier quoted context omitted.
As you can see in the wild, nobody really cares about UNIX certification. Ergo, UNIX didn't win.
The fact is that the Linux kernel without the APIs copied from POSIX/UNIX and the userspace copied from UNIX is useless on the server space. Of course we can play semantic games about the use of UNIX word, and GNU/Linux not sharing any code from either BSD or AT&T linage, it doesn't make it any less UNIX. Had Linux not copied UNIX, and provided a playground for UNIX vendors kind of outsource their development costs,…
What Linux (and NT POSIX to certain degree) allowed, was to move the existing investment in software from hodge-podge of mutually incompatible, but expensive UNIX systems, to somewhere else.
Earlier quoted context omitted.
>Bugs don't magically "shift". It depends... You can’t have dangling pointers in Java - instead, you can “leak” memory by holding onto your objects even when they’re not needed anymore.
I don't think you are using "instead" correctly in that sentence. You are implying that not being able to have dangling pointers in Java (and thus eliminating an entire category of bugs) inevitably leads to the new category of bugs of leaking memory by holding on to references. But that is the case in any language that allows dynamic memory allocation. You can leak memory in Rust, C++ and VB if you don't dealloc.
The switch reduces bugs some, and definitely reduces the severity, but I would largely put the bugs in the same category and say it hasn't been eliminated.
Earlier quoted context omitted.
All of the pointer issues you mentioned have already been solved in C++ by unique_ptr.
Good, now try to enforce developers to actually use it on their code and all third party libraries they link to. Ah, and not passing it around by address or reference, instead of actually moving ownership. C++17 is a great improvement, but for it to work out in this context, developers need to actually write C++ instead of "C with C++ compiler".
Earlier quoted context omitted.
All of the pointer issues you mentioned have already been solved in C++ by unique_ptr.
Pretty much only use-after-free and double-free of that list is truly solved by unique_ptr, which is great, but nothing like what you say: - std::move out of a unique_ptr x and "*x" is a null pointer dereference, - take a reference into a unique_ptr, and it becomes dangling if it is held after the pointer is deallocated, - an T[N] array doesn't get bounds-checked whether or not it is stored in a std::unique_ptr (it i…
If you want to pay the cost of runtime array checking every time, an impl in operator[] is just a few lines long. Thankfully it is becoming more common to run programs under ASAN in dev mode.
Earlier quoted context omitted.
Good, now try to enforce developers to actually use it on their code and all third party libraries they link to. Ah, and not passing it around by address or reference, instead of actually moving ownership. C++17 is a great improvement, but for it to work out in this context, developers need to actually write C++ instead of "C with C++ compiler".
This is a silly argument. When evaluating whether to use a tool, you should consider how /you/ would use the tool, not how someone else does.