The Latest Progress On Rust For The Linux Kernel

[ultimA]

See, this is where I don't agree. You fail to allocate 100kb, but you assume that allocating 10kb could work. It might, but then it might not: it's by definition unpredictable. In this example, it can mean that your app could potentially crash later for example in the middle of saving the document, leaving you with a corrupt file. Rust's philosophy can be summarised in one sentence: no undefined behaviour under any circumstances. It's the same as the discussion about RefCell. If it lets things just go on, sometimes it may work, but there is no way to ensuring that bad things won't happen. In other words, crash explicitly, crash early, crash in a controlled way.

By the way Rust's panic!() is not really the same as abort() in C. Depending on the compiler options, it can either abort outright, or it can propagate and be caught using panic::catch_unwind, which gives you basically the same thing as RuntimeException in Java. So if you really want that kind of behaviour, Rust supports that use case too.

Yes, we don't agree. Just because I wasn't able to allocate a larger block, I shouldn't be allowed to even try allocating some smaller one because it *might* not succeed? This is crazy and bogus. Then why should I be allowed to allocate anything at all? There is always a chance a larger allocation might have failed. In fact, any allocation, even if it is the first one, might fail. And what about not being able to allocate 100MB for an image? Then there is a very high likelyhood I could still allocate 100 bytes for displaying an error message. This has nothing to do with undefined behavior, as long as the allocation function always returns a well-defined result (even in the case of failure), all is well. I could argue a forced termination is less defined than an error-result, because the result of a program- or thread-termination could be undefined at the application level (undefined hardware-state, loss of unsaved work, corruption of calculation result etc...), while the app developer would have been able to properly handle the failed allocation (just not continue).

On the other topic: Yes, I know about unwindable panics, and that the global allocator is used by default in most if not all crates. I wrote about this in an earlier post here in this thread, and I can only say the same: The problem is this facility is unstable/experimental/not yet released/call it whatever you want, and progress on it has been very slow over the years. And even when it gets officially stable, another part of the same Rust proposal is the introduction of fallible APIs, and those are the ones which won't get automatically used by crates, and will have to trickle down to them over a long period of time.

[cl333r]

You say that. No one else does and since you are nobody in the Rust community, your prattle has as much weight as your possible (and apparently likely) claim that 2+2=5.

I never claimed 2+2 = 5, so eat shit again and keep lying.

[oiaohm]

Congratulations, you discovered that the standard library is not part of the language definition. Both are changed by the RFC process, however, the language itself works fine without the standard library. That is why there is no proper overlay, as you described.

The only intelligible part of your post that I can understand is that, shock and surprise, Rust is steered by RFCs and that the standard library is not part of the compiler. You want a trophy now?

Except this is problem.

https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attributes.html

Lets take a close look at C compilers. " format (archetype, string-index, first-to-check)" read that bit.

Yes C works without the standard library as well. This does not get C compilers out of in fact checking that the standard library is used correctly.

mdedetrich and oleid the idea that compiler and the standard library do not overlap. This is wrong. The compiler should overlap with the standard library in its checks. The fact the current rustc complier does not means rustc buggy compiler not checking everything the language standard says it could. The problem here is it will let people make a program that at build time could have raised a warning/error that crashes on the end user in use.

The reality here this stupid split between compiler and standard library we did see in the history of C compilers as well. This is a case rust developers are not learning history and are repeating a history mistake.

Same applies in the rust unsafe mode areas. Where the rust compiler is not doing all the checks it could in the unsafe areas. Providing warnings instead of failure to build(in safe) in unsafe areas is highly advisable just in case programmer has done something they are not quite expecting.

Like it or not a proper overlay should exist between the standard library and the compiler of a language. Yes function attributes done in gcc and llvm C is a really good starting point for how the overlay should be done.

[jacob]

It works both ways my little funky piglet, so just drop it. You have proven to be a clueless moron who knows nothing about Rust, concurrency or software safety and you are full of shit on each of these topics. mdedetrich was mistaken about RefCell but s/he is not hell bent on crass ignorance combined with unwarranted condescension. Unlike you.

You've learnt copy & paste. I must say I'm impressed, I wouldn't have expected such advanced knowledge from you.

[jacob]

Saying it doesn't make it so. The borrow checker is at the core of Rust development, it's Rust way to enforce the borrowing rules at compile and runtime.

You say that. No one else does and since you are nobody in the Rust community, your prattle has as much weight as your possible (and apparently likely) claim that 2+2=5.

[jacob]

And what do you do about crates that don't use your allocator? Also, unless you absolutely really need a custom memory management for performance, rolling your own allocator is not what devs are interested in or usually do. With the "roll-your-own argument" you could also roll your own arithmetic or array-access functions in C that are safe. Sounds silly, right? It is. Just as silly as rolling your own allocator and modifying all your dependencies with it just to avoid unnecessary crashes that would have been easily avoidable otherwise. It's not about what you can do, it's about reasonable defaults and ease of coding. And I criticize that Rust's defaults for handling memory allocation are not good.

You don't have to worry about other crates. Unless they expressly use their own allocator (hint: only very low-level or niche-case libs do that), they will use "the" allocator, which is either the default alloc_system/alloc_jemalloc pair, or whichever one you use instead. As for rolling your own safe array access function in C, there is nothing silly about it since every single C program ever written does exactly that:

[b]if (i < array_len)[/b] {
  do_stuff(array[i]);
}
else {
  bad_index();
}

But if you have some predictable and reliable way to "easily avoid" (as you claim) race conditions or out-of-memory errors in a general-purpose language, in the general case and without runtime checks, then please don't wait and publish it You will probably rank alongside Alan Turing in the history of computer science.

[jacob]

Your points only apply if the system memory is filled to the brim. Which is rare. As I said, "just because you failed to allocate 100Kb of memory doesn't mean you won't be able to allocate another KB or so". In my experience, most times even when an allocation fails, you can still do other allocations as long as they are smaller. Saving a document to disk doesn't necessarily have to be memory-intensive, since often you can just stream bytes to the disk. Even stuff associated with saving such as compression is usually done in chunks so you don't need to allocate enough space for a whole copy. Similarly, displaying a UI element about the error is no problem as it is not usually a memory-hungry operation (especially if you already have some other UI on screen). Same thing with std::bad_alloc. Yes it allocates memory, but it only requires a couple of bytes, which is almost never a problem in practice. BTW, C++ also has a standard non-throwing new, though people rarely use it, exactly because the allocation of a bad_alloc is actually a non-issue (when people choose to use new(nothrow), that is usually about a requirement to avoid exceptions altogether rather than saving memory).

See, this is where I don't agree. You fail to allocate 100kb, but you assume that allocating 10kb could work. It might, but then it might not: it's by definition unpredictable. In this example, it can mean that your app could potentially crash later for example in the middle of saving the document, leaving you with a corrupt file. Rust's philosophy can be summarised in one sentence: no undefined behaviour under any circumstances. It's the same as the discussion about RefCell. If it lets things just go on, sometimes it may work, but there is no way to ensuring that bad things won't happen. In other words, crash explicitly, crash early, crash in a controlled way.

By the way Rust's panic!() is not really the same as abort() in C. Depending on the compiler options, it can either abort outright, or it can propagate and be caught using panic::catch_unwind, which gives you basically the same thing as RuntimeException in Java. So if you really want that kind of behaviour, Rust supports that use case too.

[mdedetrich]

RefCell.

https://rust-lang.github.io/rfcs/1660-try-borrow.html

oleid RefCell is written into the RFC as part of the borrow checking system.

mdedetrich the reality here the borrow checker part of the rust compiler has not caught up with what is written in the rust RFC that define the language. The borrow checker in the compiler should be checking the RefCell and other parts of runtime borrow checking as well for stupid errors. Ok down graded to warnings not failure to build.

The compiler is not the language define. RFC and the book written by a proper author basing what he is writting of RFC state clearly you have runtime borrow checking.

The reality is the rust compiler has a weakness that does need to be fixed. And its a weakness that means rustc compiler does not properly conform to what is written in the RFC of the language. Of course mdedetrich that flawed code of the compiler you have been trying to use to argue your point with me.

Like it or not the rust RFC that defines the language defines that you have runtime borrow checking and build time borrow checking. Big problem these don't properly overlap in the compiler. The build time borrow checker should be checking the runtime borrow checking as much as possible to catch programmer errors. Currently rustc is not attempting to check the rust runtime borrow checking this is a compiler flaw not a language flaw.

Dude why the hell are you still responding, at this point you are just arguing with yourself. Every post you are making is going further and further down some rabbit whole that you concocted in your mind which no one else understands out of what seems to be desperation to show that you are "right" (for whatever your definition of "right" is).

The only intelligible part of your post that I can understand is that, shock and surprise, Rust is steered by RFCs and that the standard library is not part of the compiler. You want a trophy now?

[oleid]

RefCell.

https://rust-lang.github.io/rfcs/1660-try-borrow.html

oleid RefCell is written into the RFC as part of the borrow checking system.

[...]

Like it or not the rust RFC that defines the language defines that you have runtime borrow checking and build time borrow checking. Big problem these don't properly overlap in the compiler.

Congratulations, you discovered that the standard library is not part of the language definition. Both are changed by the RFC process, however, the language itself works fine without the standard library. That is why there is no proper overlay, as you described.

[oiaohm]

And the documentation for the compiler said the borrow checker is a compile time phase in the compiler. The documentation for RefCell says that it can satisfy borrow semantics at runtime (along with other things that has nothing to do with a borrow checker, as said previously its also a reference counter)

Wrong, rust is defined by its RFC process and the RFC repository. And certainly for parts which don't have an RFC by the source code.
Some of the links presented in this thread link to the "official book". That is written by third party and was donated to the community.

RefCell.

https://rust-lang.github.io/rfcs/1660-try-borrow.html

oleid RefCell is written into the RFC as part of the borrow checking system.

mdedetrich the reality here the borrow checker part of the rust compiler has not caught up with what is written in the rust RFC that define the language. The borrow checker in the compiler should be checking the RefCell and other parts of runtime borrow checking as well for stupid errors. Ok down graded to warnings not failure to build.

The compiler is not the language define. RFC and the book written by a proper author basing what he is writting of RFC state clearly you have runtime borrow checking.

The reality is the rust compiler has a weakness that does need to be fixed. And its a weakness that means rustc compiler does not properly conform to what is written in the RFC of the language. Of course mdedetrich that flawed code of the compiler you have been trying to use to argue your point with me.

Like it or not the rust RFC that defines the language defines that you have runtime borrow checking and build time borrow checking. Big problem these don't properly overlap in the compiler. The build time borrow checker should be checking the runtime borrow checking as much as possible to catch programmer errors. Currently rustc is not attempting to check the rust runtime borrow checking this is a compiler flaw not a language flaw.