SoylentNews is people
SoylentNews
Linus Torvalds' Initial Comment On Rust Code Prospects Within The Linux Kernel
Kernel developers appear to be eager to debate the merits of potentially allowing Rust code within the Linux kernel. Linus Torvalds himself has made some initial remarks on the topic ahead of the Linux Plumbers 2020 conference where the matter will be discussed at length.
[...] Linus Torvalds chimed in though with his own opinion on the matter. Linus commented that he would like it to be effectively enabled by default to ensure there is widespread testing and not any isolated usage where developers then may do "crazy" things. He isn't calling for Rust to be a requirement for the kernel but rather if the Rust compiler is detected on the system, Kconfig would enable the Rust support and go ahead in building any hypothetical Rust kernel code in order to see it's properly built at least.
Linus Torvalds Wishes Intel's AVX-512 A Painful Death
According to a mailing list post spotted by Phoronix, Linux creator Linus Torvalds has shared his strong views on the AVX-512 instruction set. The discussion arose as a result of recent news that Intel's upcoming Alder Lake processors reportedly lack support for AVX-512.
Torvalds' advice to Intel is to focus on things that matter instead of wasting resources on new instruction sets, like AVX-512, that he feels aren't beneficial outside the HPC market.
Related: Rust 1.0 Finally Released!
Results of Rust Survey 2016
AVX-512: A "Hidden Gem"?
Linus Torvalds Rejects "Beyond Stupid" Intel Security Patch From Amazon Web Services
(Score: 5, Interesting) by turgid on Monday July 13 2020, @09:38PM (15 children)
I'm leaning towards D because it's much cleaner than either and designed by a guy (Walter Bright) with years of experience writing C and C++ compilers. When Go came out, I was underwhelmed by it. Rust seems to be designed by people who haven't heard of Test Driven Development and it suffers from some of the same problems as C++.
If I had another 20-30 IQ points then perhaps I would have some to spare on difficult languages like C++ and Rust, but I just want to get things done with what I have. I have no interest in being "clever" and a language lawyer. I prefer not to put bugs in my code by keeping it simple and quick to compile, running the tests every time I change a line of code.
Why is there a fashion for compilers (and languages) to become ever more complex, slow and potentially flaky?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by DannyB on Monday July 13 2020, @10:11PM (2 children)
Why do we have dishwashers when we can do dishes by hand?
Why the noise and complexity of a backhoe when you can quietly dig a long ditch with a shovel.
Because: human productivity.
Compilers and languages have gotten more complex for the last sixty years. For that reason. To make humans more productive.
In the last three decades we reached a point where human programming cost exceeds the cost of computers. Thus runtime inefficiency is a net dollars and cents gain if you can program the machine faster.
Ask anyone (end users, customers, managers, etc), would you rather have your XYZ software delivered six months sooner, or have it be more efficient at runtime? Guess which one they will pick?
There is also a consideration of languages protecting programmers from themselves. This is a Good Thing. As long as you can deliberately get around it when necessary by telling the compiler "I know what I'm doing". Fact: humans make mistakes.
Now I'm going to mention Java as an extreme example, which is completely inappropriate when talking about the Linux kernel. But the economic reality is why Java has been the #1 or #2 language for the last 15 years in a row. [youtube.com] Java must be doing something right. GC must be a net economic win. (argument: the threads that service a customer request incur zero cpu cycles of memory management. GC threads on other cores incur that cost -- but not inline with servicing the customer request. The customer request naturally has to make enough money to pay the freight of the GC -- and it does.)
There are different levels of abstraction, and protecting programmers, for different types of programming work. Writing kernels and microcontroller code is certainly different than business software. But some of these arguments apply about human productivity, economics, eliminating entire classes of bugs automatically if possible, using the compiler as your first line of unit testing. If the code won't even compile, then it fails the first unit test. :-) Letting those errors slide until runtime is simply a lazy approach and means that they might not be found in your unit testing, but will be found by your ultimate customer. I remember in the early 1980s reading about a rocket that was lost due to a type error that would have been a compile error in Pascal. Yes, early 1980s story.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 4, Insightful) by turgid on Monday July 13 2020, @10:40PM (1 child)
My point is that, in my humble opinion, some have got so complex that they have the opposite effect. I have yet to see any "good" C++ code in a commercial setting. There are whole books written on what you shouldn't do when writing C++, for example.
I agree that there are some languages that facilitate this. They tend to be clean, simple, elegant and high-level with a great deal of abstraction. Unfortunately, they tend not to get used much because they're not in fashion like e.g. Java, C++, C# and maybe now Rust.
There is often a lot of hubris involved when someone decides, "I know what I'm doing, and I'm going to ignore what the compiler is trying to tell me." It often ends in tears. If you are having to resort to such bodges, (1) check your understanding of the problem, (2) check your understanding of the language and (3) redesign your solution or (4) choose a better language.
It allows mediocre programmers to get simple programs working in a nice cross-platform sandbox. I use Java every day. It's too wordy. The standard class libraries aren't vert good.
Agreed, but compilers and static analysis can't catch all those bugs. The code has to be executed and made to fail. Branches must be checked. Use cases must be exercised. C++ and Rust and the intel itanics of programming languages. They are enormous, baroque and make magical promises which can never be fulfilled because code must be run.
For this reason, there has to be a good balance between compile-time safety (good), static analysis (good), unit testing (good) and regression testing (good).
If the language is so difficult and complex that it's slow to get something through the compiler, people will hack around it. Then you lose 1 and 2. You also don't get around to 3 and 4 until much later, if at all.
Bugs are expensive the later they are discovered. It's best not to put them in in the first place.
If your language is big and difficult, and your compiler is big and slow steps 3 and 4 get put off until much later than they should. Some people are so confident in their fancy languages and compilers that they think they don't have to write unit tests!
There needs to be a healthy balance. Making languages more complex is not the answer. It doesn't work.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by DannyB on Tuesday July 14 2020, @01:57PM
Both C and C++ are the kind of languages that I am arguing against not for.
It is unfortunate that some good languages never take hold and get the recognition they deserve. I've seen talk about that for a long time and no good solution. Betting on a programming language for a big project is a huge bet. A gigantic risk. It is amusing that the only modern languages to gain any traction are mostly created by corporations. Java, Swift, Rust, C#, Go, Dart.
That can be true. I think back to languages like Pascal and Modula 3. It is important for small bits of code that might manipulate the hardware to turn off some features. In Pascal, I remember an example like:
* Declare a constant, named "memory" that is a pointer to a byte array, and initialized to zero.
Talk about instant PEEK / POKE. Anywhere you could do: memory^[16384] = 227;
That is just an example, where if you were writing code to manipulate the hardware of an IBM PC's video display, being able to say "I know what I'm doing" is quite useful and not hubris. Since it's a constant, it doesn't use up a global stack slot as a variable. Once it is initialized, it is "safe" to use anywhere. But you might limit its visibility to a specific "unit" (pascal term) where you are providing an abstraction over some hardware diddling.
I use Java every day too. So far as I am able to determine, I have not yet been involuntarily committed to any mental institution. (But even if so, I can't tell, because I wake up every day and program Java.)
Java has its warts. As do most languages. The things that it does well vastly outweigh the warts. Otherwise nobody would use it.
The success of Java is an economic argument. And this is what most programmers miss. Programmers think too much in purely technical terms without other considerations. Completely unable to see what drove Java to success. Or why it is so widely used. Especially by huge financial institutions, banks, or other corporate enterprise software. So much so that Microsoft needed to try to steal it.
The previous paragraph especially applies to garbage collection. People who hate GC don't understand the economic argument. But there are also technical arguments for it. I'm not saying GC should be used everywhere. But for higher level languages used to write applications, I'll let the evolution of languages speak for itself. How many modern high level languages have GC? Python. JavaScript. Go. Visual Basic. Visual FoxPro. Java. C#. Lisp and its variants. Haskell et all. Prolog style languages. Theorem provers. Computer Algebra System languages. I would add any language that runs on the JVM (Kotlin, Scala, Groovy, etc, etc)
While people argue about languages that manipulate bits and bytes and teeny bits of technical efficiency, and lack of high level abstractions, the high level language users can get things done, much more quickly, and laugh all the way to the bank.
Compilers CAN and DO catch certain types of errors 100%.
Compilers can NEVER catch certain types of errors, that is 0%.
A compiler is never going to know that a check should be subtracted, and a receipt should be added to a total. But a compiler can catch an error where you're trying to assign a String to an HtmlString or to an SqlString without going through an "escape" function, because those two string types are incompatible.
It is important and beneficial that languages and compilers now catch more types of errors than long ago. Entire classes of bugs have been eliminated by language design. I would just point out that GC eliminated three different types of memory bugs that are the scourge of all software that has ever been written in C or C++, and the source of many security problems.
You're preaching to the choir.
Languages need to be small. Comprehensible. Never put something into a language that could go into a "standard library". Follow the "scheme" philosophy more than the "common lisp" philosophy.
Compilers need to be FAST. At least for development. The speed of the Edit-Compile-Debug cycle is extremely important.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2, Troll) by The Mighty Buzzard on Monday July 13 2020, @10:50PM (9 children)
Veto.
If you can't write a single line of code without needing to check that you're not fucking it up, I don't want to work with you. Not ever. I write the entirety of whatever project or feature I'm working on in one go unless it goes over a couple thousand lines. And rarely have to fix more than a dozen piddly little things (mostly punctuation or enclosure matching because I code entirely in vanilla vim). I'm not saying everyone should hold themselves to that level but they should at least be able to write a twenty-five line function in one go without having to ask the compiler if they know what they're doing.
Also, if your shit is so monolithic that it compiles slow as hell in Rust, it's going to compile slow in anything else. If you're using modular code for a large project and only change one file, you only rebuild the one file and relink, even in Rust. And it doesn't even need to compile to tell you when you fucked something up at the language level. Your algorithms are of course on you.
My rights don't end where your fear begins.
(Score: 4, Insightful) by turgid on Monday July 13 2020, @11:17PM (6 children)
I'd you never make mistakes then you either don't know you've made any because you don'tknow where to look or you are regurgitating a boiler-plate solution from memory (in which case you should be reusing not reinventing). If it's the former, you are passing on debugging to your users and technical debt to your colleagues. If it's the latter, you can be scripted.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 1, Offtopic) by The Mighty Buzzard on Tuesday July 14 2020, @12:06AM (5 children)
To begin, I'd +1 Funny you for the typos but I'm out of points.
As to the assertion itself? Compilers can only catch you out making stupid mistakes that can be corrected easily all at once when you're done. They will not tell you if your shiny, happy algorithm (that had damned well better take more than one line) is doing something slightly different than what you meant it to. That's what unit tests, fuzzing, and martybs are for.
To be clear, I wasn't insulting you. You expressed an extreme lack of confidence in your ability to write something correctly the first time. I took you at your word that you can't. I can though. Yes, I may have to recompile half a dozen times when I'm done to fix the few errors I inevitably code in but I will not have to recompile a couple thousand times like you would have.
My rights don't end where your fear begins.
(Score: 2) by turgid on Tuesday July 14 2020, @10:07AM (4 children)
Typos? It was past midnight and I was on my Android phone. I'd spent the evening doing battle with a micro SD card in an Android tablet. I accidentally formatted it as internal storage and it moved 7.5 GB of data. I had to figure out how to undo it. I learned all about MTD and failed to backup all the data to my laptop. Eventually I found the right pictures to point at on the Android device. Then I took the card out to reformat on my laptop. For the first time in my life I made a typo writing the exfat file system and hosed my laptops's EFI boot partition by mistake, so I had to fix that too.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by The Mighty Buzzard on Wednesday July 15 2020, @10:10AM (3 children)
Erm, when did we go from coding in a compiled language to system administration? But, yeah, anyone who's spent any significant sysadmin time has an "ARGH!" story or two.
My rights don't end where your fear begins.
(Score: 2) by turgid on Wednesday July 15 2020, @12:17PM (2 children)
You asked about the typos and I obliged.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by The Mighty Buzzard on Wednesday July 15 2020, @02:33PM (1 child)
Oh, I meant the ones in the post. If it was intentional, it was funny. If it wasn't, it was even more funny.
My rights don't end where your fear begins.
(Score: 2) by turgid on Wednesday July 15 2020, @03:17PM
That's why I made typos in the post: I had a stressful late evening culminating in the erasing of my boot partition due to a typo, just to be absolutely clear. Typos everywhere.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 1, Informative) by Anonymous Coward on Tuesday July 14 2020, @07:39AM (1 child)
not that I disagree with the 25 line function statement, but please note that in C++ with templates and abstract classes on top a small change can lead to a long recompilation time even if your code is technically modular.
(Score: 2) by The Mighty Buzzard on Wednesday July 15 2020, @10:08AM
Fair nuff, and that's a small part of why I despise most templates and macros.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Tuesday July 14 2020, @08:16AM (1 child)
Last I checked, D uses a tracing collector, which is completely unacceptable in any kind of space, time, or latency constrained system.
(Score: 3, Informative) by turgid on Tuesday July 14 2020, @10:00AM
No one is forcing you to use the garbage collector though, or array bounds checking either for that matter. That's one of the many good things about D.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].