OpenBSD Seeing Initial Work Land On Enabling 64-bit POWER

[rene]

It is not a compromise. It is still the only valid choice.

Java cannot exist without a VM written in C.
Rust is rendered useless when interfacing with actual raw memory and hardware which is unsafe by its very nature.

Oddly enough C is safer to write than Rust unsafe sections because it is designed for it from the ground up. Rust's unsafe tags are a compromise.

Plus you had better hope OpenBSD developers write secure code. Most of the world depends on OpenSSH.

a VM, complier, etc can be written in a lot of languages beside C. Basically anything Turing complete. Oddly enough the only thing safe in C is that nothing is safe.
The world depends on OpenSSH? Well not quite, but in case of OpenSSL that is quite some security disaster for years, ... :-/

[kpedersen]

let mut blah = unsafe { from_raw_parts(...) };

And if the memory pointed to by blah later gets stripped out from under you? Rust doesn't control that data. The environment does. Its like in C++ you could have some std::shared_ptr<T> to an OpenGL wrapped texture. If the whole of OpenGL gets shut down (ie the SDL Window context is deleted), then you have a valid reference count, but to garbage (deleted) data (a no longer valid GLuint texture ID).

All the rest can be and often is safe code. Check out Redox OS. The comparison with LUA is ridiculous, code compiled in Rust is native code that requires no interpreter, can be used even to implement interrupt handlers and generally is usable everywhere C is usable.

I could have used any "safe" language. Lua (or other) and Rust have the same issues that their safety is not guaranteed due to ultimately requiring "unsafe" parts further down the stack. Lua has a garbage collector making double deletes impossible, likewise Rust has Ref counting... but neither can deal with the fact that the underlying memory can still be wiped as an (often erronious) side effect. When you write system code (i.e an OS) rather than just application code; you *need* to take this into consideration.

Whatever you "feel" is obviously absurd. There is no relation in any shape or form between a module system and pulling in dependencies.

Of course it does. It usually means a weaker standard library so users depend on i.e NPM to do the most simple of tasks. It is the reason why web development is seen as a chaotic mess. You could argue that C and C++ have small standard libraries but because dragging in a dependency to just split a line is not quite as easy, you see much less of that kind of "dependency based" behavior.

What I "feel" has actually done me well. It helps me simply refuse to take on contracts where I might have to deal with these kinds of developers. It also allows me to predict when projects are going to fail quicker than less experienced developers so that I can avoid them.

The Firefox source code, for example, has currently over 2 million lines of Rust, is that large enough for you?

You miss my point (or I didn't explain it well). By "all in one" approach I mean that it doesn't load all into memory and build (the reason why forward declares are needed as an example). Rust loads much more of the binary into memory in order to be able to compile.

Your example is good though; 2 million lines of Rust doesn't compile on 32-bit (not enough memory). It does with the approach C takes however. I think this is summarized well here from Theo himself:

Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.

https://marc.info/?l=openbsd-misc&m=151233345723889&w=2

Sure, you can say "but 32-bit is old" and that is fine. Not everyone needs to be "efficient"

[JustinTurdeau]

RustBots should be banned on sight for mentioning Rust in an unrelated thread.

[aht0]

Overall typical Phoronix. Usual crowd of Linux die-hards bashing.

The fact it's just another open-source OS is meaningless for the bunch. Rather fueling the hate posts. Sad shit.

[kpedersen]

a VM, complier, etc can be written in a lot of languages beside C. Basically anything Turing complete.

Well that's the fun part. What other language? Python? VB.NET? Both of those would require an interpreter or some other VM which *would* then need to be written in a native language (again, usually C). We have extremely few of those and even fewer of them are "safe". Rust would need to use a large amount of unsafe tags for the JIT interpreter part and that is possibly the closest to a "safe" native language we have.

(Don't get me wrong, I have high hopes for Rust but it is certainly not going to solve all our problems. It is potentially a good replacement for C++ but possibly not C).

The world depends on OpenSSH? Well not quite, but in case of OpenSSL that is quite some security disaster for years, ... :-/

I know. I really wish the OpenBSD guys had written OpenSSL. Then it might have stood a chance at being well implemented and reliable. As it stands their fork (LibreSSL) or the much smaller BearSSL are good alternatives.

[jacob]

Overall typical Phoronix. Usual crowd of Linux die-hards bashing.

The fact it's just another open-source OS is meaningless for the bunch. Rather fueling the hate posts. Sad shit.

Exactly. It's like LLVM/GCC or GNOME/KDE. It always amazes me that those people believe that the world would be better if we had one great free operating system instead of two.

[jacob]

And if the memory pointed to by blah later gets stripped out from under you? Rust doesn't control that data. The environment does.

If a pointer gets stripped out from under you then you are no worse off than in C/C++. But if you know WHEN the pointer is going to become invalid, and sometimes you do (typically by invoking a certain operation that flushes buffers, etc), then you can ensure that your pointers are consumed or that they don't outlive the data and the compiler will take care of the rest.

Its like in C++ you could have some std::shared_ptr<T> to an OpenGL wrapped texture. If the whole of OpenGL gets shut down (ie the SDL Window context is deleted), then you have a valid reference count, but to garbage (deleted) data (a no longer valid GLuint texture ID).

shared_ptr<T> in C++ is the equivalent of Rust's Rc<T>, not Rust references. Rc pointers are rarely used in Rust, among other reasons because in C++ you really need to use some form of smart pointers to make the code (a little) less likely to crash, in Rust it's not necessary.

I could have used any "safe" language. Lua (or other) and Rust have the same issues that their safety is not guaranteed due to ultimately requiring "unsafe" parts further down the stack. Lua has a garbage collector making double deletes impossible, likewise Rust has Ref counting... but neither can deal with the fact that the underlying memory can still be wiped as an (often erronious) side effect. When you write system code (i.e an OS) rather than just application code; you *need* to take this into consideration.

You just proved what I suspected, that you know next to nothing about Rust. I won't comment on Lua because I've never written any code in it, but Rust's memory safety model has nothing to do with ref counting. Ref counting does exist in Rust (Rc<T>, see above), but it's rarely used and often frowned upon. What Rust actually relies on is static lifetime analysis. The type system is extended with "lifetime" annotations and each variable, function parameter, object, object field etc. has a lifetime, implicit or explicit, that states where it is created and where it is destroyed. Knowing that sometimes invalidates a pointer, for example, means that Rust can enforce (at compile time) that that pointer or any of its aliases can't be accessed afterwards.

Of course it does. It usually means a weaker standard library so users depend on i.e NPM to do the most simple of tasks. It is the reason why web development is seen as a chaotic mess. You could argue that C and C++ have small standard libraries but because dragging in a dependency to just split a line is not quite as easy, you see much less of that kind of "dependency based" behavior.

What I "feel" has actually done me well. It helps me simply refuse to take on contracts where I might have to deal with these kinds of developers. It also allows me to predict when projects are going to fail quicker than less experienced developers so that I can avoid them.

You are confusing modules and third-party packages. Modules simply mean encapsulation, interface definition and visibility rules. Just like classes in C++, except at a coarser scale. C's include files are a poor man's imitation of proper module support. Third party libraries like those managed by NPM, or Cargo in Rust, can be implemented using modules if the language supports them, but the relationship ends there. By the way package managers are great tools, whether they are used properly or wrongly is up to those who use them.

You miss my point (or I didn't explain it well). By "all in one" approach I mean that it doesn't load all into memory and build (the reason why forward declares are needed as an example). Rust loads much more of the binary into memory in order to be able to compile.

Your example is good though; 2 million lines of Rust doesn't compile on 32-bit (not enough memory). It does with the approach C takes however. I think this is summarized well here from Theo himself:

https://marc.info/?l=openbsd-misc&m=151233345723889&w=2

Sure, you can say "but 32-bit is old" and that is fine. Not everyone needs to be "efficient"

I didn't miss your point, I pointed out that it's bogus. Of course Rust doesn't load and compile 2 million lines at once just like you wouldn't have a single giant C source file of 2 million lines. C compiles one file at a time, Rust compiles one crate at a time, where a crate can be one or (usually) several files. A C project would be split into multiple files (with include headers) and compiled separately. The Rust project would be split into multiple crates and compiled separately - no include files needed here because it has module support.

[JustinTurdeau]

Overall typical Phoronix. Usual crowd of Linux die-hards bashing.

The fact it's just another open-source OS is meaningless for the bunch. Rather fueling the hate posts. Sad shit.

Which posts are you even referring to? Or did you just feel like having a random spergout...?

[JustinTurdeau]

start_ptr<T> in C++ is the equivalent of Rust's Rc<T>, not Rust references. Rc pointers are rarely used in Rust, among other reasons because in C++ you really need to use some form of smart pointers to make the code (a little) less likely to crash, in Rust it's not necessary.

Rust, Rust, Rust, bla bla bla.....

Why do you cringeworthy RustBots try to turn every thread into a Rust thread? Rust is a dying research language with no future.

[jacob]

Sure, you can say "but 32-bit is old" and that is fine. Not everyone needs to be "efficient"

PS: If compilation efficiency is what you worry about, then include files are the absolutely worst approach in existence. You are reparsing and recompiling the same code again and again and again, for each file that includes your header. With something like the STL, that means that huge amounts of nontrivial code get recompiled every time a header is included because the language/build system combo is dumb in that regard and doesn't know how to handle interfaces and inter-module dependencies. This is one of the main reasons why compilation speed in C++ is so slow (and even in C, when requiring many large headers like in modern GUI toolkits, for example).