Finally, Linux partially wakes up from its 90’s deep sleep.
That should’ve happened 2015, when the first stable version of Rust was released…
2 Likes
But rust is not stable, even today. My tiny experience with rust suggested it has no intention of ever being a static, rock solid compiler that one could base any major project on.
You cant build on shifting sand
This tiny experience is misleading, then. My experience with C compilers is, that there is so much to go wrong, there’s always something you will do wrong, like e.g. picking the wrong option or mode. Now, millions of people on earth would disagree with that, as C is so old, that they think it’s perfectly solid.
There are plenty of rock solid Rust projects out there proving that Rust is rock solid. One just has to know how it works. Same with goldboot. The maintainer was in the process of implementing changes, which broke the compilation process. Rust itself however, works perfectly fine, without notable issues.
P.S.:
When a maintainer aims to have a proper C build or anything, they usually must include like a hundred CLI options passed to the compiler, not counting in all the environment variables you have to account for. Modern languages’ compilers usually work by default pretty well and don’t need so many options to tell the compiler what to do.
Speaking of C/++ being broken…
cd vcpkg/buildtrees/libvpx/src cd * ./configure sed -i 's/CFLAGS+=-I/CFLAGS+=-fPIC -I/g' Makefile sed -i 's/CXXFLAGS+=-I/CXXFLAGS+=-fPIC -I/g' Makefile make cp libvpx.a $HOME/vcpkg/installed/x64-linux/lib/ cd
I was thinking more of Fortran than C. On a mainframe the Fortran compiler was the one thing you could depend on to be unchanging and reliable. The OS’s were terrible on mainframes but it did not matter because the compiler was dependable. Fortran has agreed language definitions which only change about every 15 years. C is nearly as stable in that sense. Rustc is continually changing like a rolling release.
You have been saying to me that one needs to fix the rustc release for the duration of a project. How can that work with Linux? Will they need to compile the kernel,with some old version of rust? What if I compile a kernel? I will,have to be careful of rustc versions there.
With C, at least the compiler version does not often matter. Sure , if one is writing C, there are mantraps everywhere. Not so in Fortran. In that sense rust is better than C. They just need to finish evolving the language definition and have a freeze for a while, so oldies like me can keep up. I cant see a rolling release compile being practicable.
Julia has the same problem, compounded by there being noone in the development who can write documentation.
I appreciate that using rust in Linux is progress. It could be a lot better if the rust development was properly managed.
This explanation makes much more sense. I pretty mich agree with all of it, though I wouldn’t call rustc a “rolling release”. I would say, there is still so much to add, improve, etc. that it changes a lot, though most of the time these aren’t breaking changes, per sé.
As I don’t use Rust as much and on the other hand use Nim a lot, I will take Nim as an example, because I see lots of similarites with how the Rust compiler behaves.
So, we have a stable Nim compiler version. Despite that, there are soooooo many plans for improvement, additions, new features, some breaking changes, etc. When you visit the Nim forum and the Nim blog you see tons of discussions about new features, like new garbage collectors, Rust & C++ styled features remade for Nim, etc.
However, most of these things are optional from the point of view of an every day programmer. For example, I barely am up to date about Nim’s newest features, etc. yet all my Nim programs still work and I rarely had an older program break, before Nim had its 1.0 release. Now, after the 1.0 release, I did not experience any real breaking change. Some additions and warnings about future breaking changes, but all in all, all my old programs still compile the same way, several versions later.
It’s just that, there are so many Nim enthusiasts who try out the newest bleeding edge features and therefore naturally encounter more bugs and issues.
I have seen the same with Rust projects. Rust enthusiasts tend to use a lot of brand new bleeding edge features, which naturally requires nightly versions of the Rust compiler.
Though, if you would start writing Rust and would strictly hold on to what is already stable in Rust, I am very sure, you wouldn’t encounter a single problem with the compiler itself. Everything would work as expected, in a rock solid way.
Therefore, the Rust compiler is safe & stable for production use. It’s just that a lot of projects use bleeding edge features, which are not necessary, but improve the code even more.
This is, I think, especially the case with Rust, because Rust is a C replacement. C is all about speed & optimisation. One of Rust’s main goals is to keep exactly this aspect. So, it’s just natural, that Rust programmers will squeeze every single bit of performance out of the compiler, even if that means, they need to use a bleeding edge, yet unstable, feature from the nightly version of the Rust compiler.
If you wouldn’t care too much about speed & optimisation or low level programming, you perhaps wouldn’t use Rust in the first place, but another language, which has different qualities.
No. Just use strictly stable Rust features, instead of bleeding edge ones and you are perfectly fine. Just as stable as it gets.
In Nim for example, you have to explicitly enable experimental features by using the experimental pragma. So, this is like an implicit agreement that your program is using bleeding edge features and you have to expect them to be removed or broken in a future release of the compiler.
I expect Rust to have a similar way of making the user agree to those issues.
If we are also speaking about compatibility in general and not only the compiler itself, then C is super easy to break. Oh, how many times did I break the entire Linux operating system, because of mismatching libc versions. Just ONE version apart and it will break your entire Linux. You have to restore the entire system from a backup.
So, even if your assumption about C compilers is correct, there are tons of ways to break “stable” C programs. Just change the libc version and boom, your entire Linux installation stops working!
The definition is done, but improvements and additions will be added for ever, I think. Just look at C++. Okay, that’s an extreme example, but still. So many decades later and they still “improve”, change and add stuff.
I hope they don’t do that to Rust, but I would expect them to add more stuff for the next couple of years.
Documentation is a general issue in the IT world. Programmers and engineers usually don’t want to “waste their time” with that. 
It’s all up to the Rust programmer. Just use strictly stable features and all will be fine. No issues.
What would really help woild be if they did it like Fortran … ie every 10 or so years, write a standard… like FortranII, FortranIV, Fortran66, Fortran77, Fortran90,… Then everone would know what was in the interim standard and could be expeceted to be stable.
I know what a fortran77,program is, because there is a book that tells me exactly what the language definition contains. I dont know what a rust19,.0.1 program is.
So when/if I write a program in rust, what do I consult to know what the stable core language is? I would have the same problem with C++ or Julia. , or any language that I have not used in depth.
How do I learn how to program in the stable core bit, and leave the bleeding edge additions alone?
And even if I master that , is there a guarantee of backwards compatability. I have a FortranII program that still runs with some minor adjustments in Fortran90. If I write in Nim1.0, will it still compile when they get to Nim9.0
There are the sort of things that bug programmers, and would be an issue to linux Kernel,development. I am sure Linus will make wise decisions about languages, but it would help,him if language developers could be just a little more systematic.
That’s what C and C++ are doing as well and it’s one way to do it, however when I see how terrible C/++ is working, I doubt making such definitions helps a lot; at least it obviously did not help much with C/++.
Then, there are always discussions and opinions about different standards for different reasons. So, the conceptualisation part of development gets even more bloated, because there are always pros and cons for using one standard over the other.
Additionally, as it’s usually the case with C-like fanatics, they usually think “old is good” & “new is bad” or something along those lines. Way too often I have seen pretty new projects using a C/++ standard from 2 or 3 decades ago, just because it’s more popular or something. If people decide on a standard because of popularity, then why have standards at all? I have so far only seen very few projects using the most recent C++ standard, I think it was version 21. Many others use way older versions, because of, in my opinion, bad reasons.
Therefore, it seems like standardisation, as it is the case with C/++, is another excuse for old timers to use some old stuff from decades ago. I think, developers should be pushed into using the newest and best version of the particular technology they are using. If the language they are using is good in principle and its goals are well defined and agreed upon by the developers, then anything new coming to the language would probably we welcomed anyway, as it’s improving the language. So, why have a standard from two decades ago? Do we want people to stay with technology from decades ago, have all these discussions and problems coming along with the many standards, just for the sake of having a bit more felt stability & integrity?
I would guess, such standards were born because of the inherent flaws coming from those C-like languages. C and whatever alternative is related to this language, is so inherently broken & unsafe, that they probably had at the time no choice but to create such standards. Though, wouldn’t it be better to just use a language, that is inherently safe or at least as safe as possible?
If we followed that we would all use Fortran or Pascal or one of the other classic languages. They are watertight because they dont go near the machine-dependent issues.
Things changed with C . It was the first language that opened the possibility of writing an OS in anything other than assembler. But there was a price… lots of dangerous constructs, like memory management. C++ made it worse, without, in my opinion, adding anything useful.
If rust can somehow overcome C’s error prone constructs, but retain the ability to deal with hardware issues, then it is obviously the way of the future. What it doesnt have is the thing that really made C… a developer with writing talent. The Kernigan and Ritchie book is both a language definition and a solid readable introduction to programming. So is Jensen and Wirth for Pascal. Where are those books for rust or nim or julia?
And a word about R (and Splus before it) . R implemented object oriented programming , but in a much cleaner way the C++. It also implemented vectorization. R is usable , and even friendly. C++ is abstract and obscure. It is possible to implement new concepts without making a mess by adding them onto an existing language.
I just used the Windows API today and nothing is watertight about how C++ works. Nothing. It’s all gibberish and you never know what you get.
I think the easiest way to discover how watertight something is, is to measure how far away it is from C and the like. The farther away the language is from C, the better and safer.
I never used Fortran before, though I would guess it’s very similar to C.
No, it is much more rigid than C. Static types, no dynamic memory management, a much more restricted range of operators. It handles arrays really well and it has subroutines and functions. Its I/O is shocking.
Modern fortran has gone down the C++ path, adding things that make a mess. I dont like it for programming today, but I have lots of old code that I still use. A lot of R is calls to Fortran routines, because most of the important numerical algorithms are implemented originally in Fortran, and noone has bothered to translate them.
True, but it depends how you write it.
I can write good clean code in C, or I can write tricky abstract stuff.
I can use C in an object oriented way, without having to go to C++.
I can write a C routine that uses only the features that you would find in Fortran, and that would be watertight, but would be considered a stupid way to program in C.
The programmer is part of the problem . The language can only be blamed for opening the door.
That shows you know your stuff. C is so horrible, you have to have decades of experience to write any good C code to begin with. If you are just starting out or are even an intermediate programmer, forget about C. It just makes you and almost forces you to write inefficient and faulty code.
Now, that is very funny. Abstraction is precisely the thing which makes things easier. C offers almost no abstraction whatsoever, which makes things so much more difficult and error prone, most of the time for little reason.
Maybe rudimentarily so, if at all.
I think, everything that is stupid according to C, should be considered learnt, simply motivated by the fact, that pretty much everything C does is the opposite of what should be happening.
The programmer is part of the problem, but the language is the biggest issue.
Just look at Kotlin.
One of the key selling points of it, compared to Java, is that it forces you to deal with null values and variables.
You have no way around it. No C-ing around and breaking everything, as it’s the case with C.
You have to handle the null situation. You are made to handle it. By the language.
This is how language design makes programmers better, for free. If the programmer is forced to do it, there is no extra effort involved. You just handle it, that’s it.
With C, it’s the opposite. You can do what you want and 99% of what you can do in C is shit. The 1% can only be created by decadedly experienced, sometimes elitist, C veterans, who have experienced the first versions of C. Otherwise, it’s highly likely one’s C code is shit. Because C makes you do nothing. It literally makes you break things. C is broken. Inherently broken.
Writing in C is basically like throwing shit at a fan and hoping that shit forms a beautiful painting on the wall, by accident. This is how C works. You never know anything, you can’t know shit. You just have null pointers everywhere and create unmaintainable monsters with huge security vulnerabilities. Just look at Linux. So many maintainers and some critical vulnerabilities were there for decades, because C is too stupid to know anything. It knows nothing.
Wrong word. I was thinking of tricky #define things.
Yes you can do anything in C, it is up to the programmer. I dont object to a language that lets you cut your throat, but I think you are correct. A language that protects you, like Kotlin, is better for normal use.
Have you ever written assembler.? There you can do even worse things than in C… like writing code that modifies itself as it runs. Yes you can write on top of the machine code at runtime. People used to do amazing things with that, like changing the content of loops so each time it goes thru the loop it dies something different, depending on the data. There are better ways.
Nim compiles to C code by default and then gets compiled further, as your everyday C code.
If C would only would be used in this way, just like Assembly, then I would stop hating C, because it wouldn’t be a problem anymore. The big thing why I hate C is that it’s so terrible and yet so popular. This also answers the question, one might ask, like e.g., why do I not hate COBOL or other obsolete languages? Simply, because their impact on the IT world is pretty low. They have their specific domains and are treated how they should be treated: obsolete and just maintained because of economic reasons.
However, when it comes to C, suddenly tons of developers talk about this language, as if it were not outdated and not shit. This is the huge problem. If everyone would treat C the way it deserves, for example, as an intermediate language, one never uses as a human, but only as part of the machine made compilation process, then C would be no problem anymore.
Therefore, Assembly is not a problem. People only use Assembly in very rare case and only a bit here and there or for educational purposes. That’s it. Nobody goes around writing a Linux kernel or entire software stacks in Assembly. So, Assembly is not a problem. It’s fine.
Back then, there were little ways with the weak & expensive hardware available. Now, we have better ways indeed and therefore should stop using C/++ altogether, except in the way outlined above.
Yes, it is the way it is used that constitutes the problem in the IT world.
Cutthroat languages like C and Assembler are fine in themselves.
The scientific computing world is much more relaxed about such things. They will use anything that gets the calculations done.
1 Like