Rust Infrastructure Pull Request Submitted For Linux 6.1!

[marios]

Now GCC Rust effort needs to be taken more seriously, depending only in LLVM is a no go.

Well, LTO for the kernel, which is actually very important, is restricted to llvm for some reason. Rust will only be the second llvm exclusive...

[karolherbst]

I disagree. The standard library should not even be considered as a part of a language. It is just an (important) extra. Only the syntax/keywords are part of the language and I think everything else (including standard libraries) should be standardised separately.

that's the reason why C sucks.

[marios]

that's the reason why C sucks.

If it is enough reason for a language to suck, every language sucks. Unless there is a language that defines only syntax in it's standard. And I am only talking about languages that have a standard. Those that don't have a standard at all suck even more.

[jacob]

You have restrict in C so no.

But who gives a shit about the standard library? Nobody forces you to use it. You can use length-prefixed strings in C just fine.

Or you can even use a better designed language in the first place

[darkonix]

Now GCC Rust effort needs to be taken more seriously, depending only in LLVM is a no go.

Not for Lnux and Linus Torvalds evidently. It is clearly going to be merged.

[karolherbst]

If it is enough reason for a language to suck, every language sucks. Unless there is a language that defines only syntax in it's standard. And I am only talking about languages that have a standard. Those that don't have a standard at all suck even more.

I am not arguing with trolls who don't actually code themselves, but only have "theoretical pointless discussions" around programming languages...

Everybody doing it for a living will tell you that it's a no brainer to have proper tooling around a language, which includes a good and competent compiler and a competent standard library. We don't want to have to think for 5 hours which of the 100 implementations I have to use to get peak performance. We want to use the language. And e.g. Rusts _huge_ benefit is, that it actually made the package managing part of the language and that third party libs which make sense, get pulled into the stdlib after a controlled process.

Having a standard would make all of that much harder and would actually sabotage it.

If you don't believe me, ask other full time programmers, they'll probably tell you something similar.

[Weasel]

I am not arguing with trolls who don't actually code themselves, but only have "theoretical pointless discussions" around programming languages...

Everybody doing it for a living will tell you that it's a no brainer to have proper tooling around a language, which includes a good and competent compiler and a competent standard library. We don't want to have to think for 5 hours which of the 100 implementations I have to use to get peak performance. We want to use the language. And e.g. Rusts _huge_ benefit is, that it actually made the package managing part of the language and that third party libs which make sense, get pulled into the stdlib after a controlled process.

Having a standard would make all of that much harder and would actually sabotage it.

If you don't believe me, ask other full time programmers, they'll probably tell you something similar.

What a load of crap.

In fact, standard libraries are almost always worse than the native APIs for the target platform. GNU/Linux is an exception when it comes to C, because most of the interfaces there are from C, so it's basically 1:1 mapping for many cases. But this isn't the case with, for example, Windows. Standard libraries will always be bloated, because they're an abstraction and lowest common denominator for all the target platforms that it supports.

Do you know why "Hello World" programs are so big in HLLs? Yep, standard libraries and all the junk they pull in. I know that it's not that significant on big projects, but it's not about the size, it's about the extra junk that gets executed before it reaches the target platform's code. Everytime you do a call, it gets wrapped around the actual APIs underneath.

When you could, you know, use the target platform's APIs directly. Skip all this fat completely. Standard libraries are like using OpenGL when Vulkan exists: just extra bloated overhead.

I also don't really give 2 shits about the "other full time programmers" considering the web is filled with basic JavaScript coded in extremely bloated frameworks, because yes, they pull that shit in EVERYWHERE since it's the only thing they're "used to". Those aren't programmers, those are a cancer to both computers, PC users (who have to deal with the bloated JS slowness) and the planet (massive energy waste).

Proving the point.

[karolherbst]

What a load of crap.

In fact, standard libraries are almost always worse than the native APIs for the target platform. GNU/Linux is an exception when it comes to C, because most of the interfaces there are from C, so it's basically 1:1 mapping for many cases. But this isn't the case with, for example, Windows. Standard libraries will always be bloated, because they're an abstraction and lowest common denominator for all the target platforms that it supports.

Do you know why "Hello World" programs are so big in HLLs? Yep, standard libraries and all the junk they pull in. I know that it's not that significant on big projects, but it's not about the size, it's about the extra junk that gets executed before it reaches the target platform's code. Everytime you do a call, it gets wrapped around the actual APIs underneath.

When you could, you know, use the target platform's APIs directly. Skip all this fat completely. Standard libraries are like using OpenGL when Vulkan exists: just extra bloated overhead.

I also don't really give 2 shits about the "other full time programmers" considering the web is filled with basic JavaScript coded in extremely bloated frameworks, because yes, they pull that shit in EVERYWHERE since it's the only thing they're "used to". Those aren't programmers, those are a cancer to both computers, PC users (who have to deal with the bloated JS slowness) and the planet (massive energy waste).

Proving the point.

literally nobody wanting to get shit done cares about any of that... you can live in your perfect world where everything is perfect, but that doesn't change the fact, that reality is completely different.

If you know how it's have to be done, then proof the world you are right (spoiler: you won't).

troll somewhere else

[bug77]

Ah, the old fallacy. Languages don't have an intrinsic speed(*), so it's nonsense to say "X is faster/as fast as/slower than Y". It's all a property of implementations. You can have a shit C compiler/runtime (hi MSVC), and you can have a shit Rust compiler/runtime.

(*) Of course esoteric programming languages will do whatever. Specifications of common general-purposes programming languages however generally don't say "this has to execute in 17 nanoseconds". At best, they'll mention the scaling characteristic of certain APIs (e.g. C++'s std::map should be logarithmic with #elements -> \infinity).

You are correct that languages don't have an intrinsic speed. However, in this case, we're looking at both of them being compiled through LLVM, that's what makes the "which one is faster" question moot. Of course, C can be compiled using gcc, but LLVM and gcc have been benchmarked to produce code of similar speeds these days (give or take).

[anarki2]

It's kinda ironic that this is exciting news mostly thanks to Apple M1 work being done by Lina.