Posts by jsmith84 10 publicly visible posts • joined 11 Mar 2019
> "I spent the first decade of my career writing code, first assembly language, then C and C++"
I spend the first decade of my career *coding* in various assembly languages on various targets, but also *programming* in C and C++.
I am a snob: ASM = coding, the rest in any language = programming.
Using AI to generate code = is not programming.
I read the thread "Another day, another attempt to force this on us"...
Just by title, it seems that some people are offended by the fact the machinery of sudo was rewritten in Rust.
When buying a Xbox series S, nobody cares that the internal might have changed between the version of July 2024 and January 2025. People are still buying a console with the same power and same features, and do not realise manufacturers constantly optimise what is under the hood.
Here, you just have to use sudo exactly like you use it before, so why do you care what the source language was for this version? (If Ubuntu never told anyone, nobody would have realised)
I have been programming in C and C++ for over 30 years now, and have been programming in Rust too. There are lots of things I really dislike in Rust, among which the borrow checker being way to pedantic compared to what would be strictly necessary (it's a long discussion I am not going to have here) and some of the library throwing exception because it does not like cycling graph detected only in certain condition (std::Rc) which make me chuckle as the safety aspect (and yes, don't get me started which the stupidity of integer overflow checked in Debug only as default behaviour... shared variables in different threads).
However, Rust is good for idiots for sure, but I must admit it will enforce a lot of safety by design (to the expense of speed for people like me) and has features making your life easier (and some making your life harder for sure).
One has to choose your fight and also decide if moving to Rust enable some fixes you could not have by simply fixing an existing behaviour (value benefit analysis). Sometimes, using Rust is based on dogma, and yes, it can give the feeling of "another attempt to force this on" some people.
Static analysis can catch some non obvious errors.
Good practice would be to use multiple compilers with non-naive options (different compilers detect different things), multiple static analysers (different static analyser detect different things) and use tools like valgrind (or instrumented build, e.g., a properly setup in the olden days, setting up correctly STLport options for "debug" builds, could catch a lot of issue, such as dangling pointers).
I have mixed view on standards (and trademarks).
1985: First version of C++
1990: First version of Python
1992: First version of C++ STL
1995: First version of Java
1998: First standardized version of C++ (inc STL)
1999: Boost library first version
2008: First version of Python 3 (breaking backward compatibility)
2013: First version of Rust
Python is widely used, and does not have a standard.
So why Rust needs a standard?
And why C++ has one?
Having a C++ standard helped setting expectation for the variety of compilers on the market (and I guess that's the key difference between C++ and others).
Having the boost libraries really help having "widely known libraries", which was lacking compare to Java. Without it, imho, it's likely C++ would have disappeared and be replaced by Java.
IMHO, Oracle being Sun and therefore Java, because of trademarks issues, killed the language (slowly but surely), and helped new alternatives (Kotlin, Scala).
Considering there is one, and only one Rust compiler (maybe I am mistaken), having a standard does not really matter, as long as the core team does not make a mess of it (to a lesser extent of "mess", the move from Python 2 to Python 3 has been an issue in the corporate world).
In the corporate world, stability does matter, clarity on licensing does matter, and that's what you get with ISO specs, "open source" software (or licensed to a similar effects).
The way I see it (and many will disagree)
* C++: standard, lots of people working on it, lots of libraries -> ok (at least ok now, I went through the version 2 to version 3 move in a large corporation :D)
* Python: not standard, but very well defined and mature, lots of people working on it -> ok
* Java: standard well published, language sounds a bit at standstill -> ok licensing can be considered as an issue
* Go: standard well published, super simple, lots of libraries
...
* Rust: motivated community (+), has been moving a lot (-), complex learning curve (-), lots (too many) libraries, documentation (~) could be better.
My point is it is hard to make a call on starting to use Rust for new projects, or "transform an organisation to Rust". In the corporate world, people like safety... not memory safety, but a high probability for projects to be delivered and minimize negative impact of bugs (as opposed to guarantee eradication). It's all about value for money.
Sure, there will be some projects when Rust is seen as a good bet, e.g. in crypto trading, many firm use it, because "it has c++ performance", "guarantee memory safety" (mostly because people are "not old school" and don't understand what memory pointer is <-- waiting for thumb down!), and more importantly, has some library (like networking) that make life easy (because don't even know about the websocket libraries in boost).
Point being that everybody will find good things in any language, and bad things in any other.
You are really missing my point and are burying yourself in small details.
const simply indicates: 1. that the compiler must check the value does not change, and 2. that the compiler can assume the value does not change (as opposed to a const volatile).
In most cases, const brings nothing, because the compiler should be smart enough to see this is a const (please note the "should"), or infer it is a constexpr (which would be more suitable than your suggestion of using const), etc.
The same applies with int. Here, we know the literal is 1, therefore an int by default, unless I set it explicitly to be different, e.g. "1." or "1.f".
We also know I am declaring a variable called x, it's kind of obvious, so why having "let".
My view is that whole thing could be written a "x = 1;" and nothing more, like in Python (we still have the ";" though).
Fixing the mutability does not add much to the code in that case, because if it was "immutable", and decided to make it mutable, we would simply removed the const... so, let's not have it in the first place (for some reason, I believe (some) very old C compiler were accepting i = 1, and assume the type was int if it was not declared).
Now, about Rust...
The language is so verbose, that many people unwrap like crazy anyway.
Panicking on integer overflow in debug mode is overkill because integer arithmetic is well know from the beginning of time for a i8, 255+1=0 (by the way, I like i8, s8, ... f32, f64, as I used to with those in C and C++).
If you really want to do check overflow, or have "clamped types" (255+1=255, 0-1=0), it would be better off adding new types with a specific arithmetic and a specifically defined behaviour, rather than changing what the excepted "machine" behaviour, and avoid inconsistency between debug and release.
Another stuff that annoyed/annoys me was [from memory] std::Rc allowing some construct and later on throwing an exception because there was a circular reference. Talk about safety to build a program, testing it, and having, maybe, at runtime, an exception because the data were visited differently (note: I can't remember what displease Rust, but I found a way to avoid it, and was not impressed by the panic which had not rationale).
My view on Rust is that it has nice things, such as macros, a good amount a libraries, however, I find Rust too verbose to be productive, and the "absolute safety promise" is not true (it's better though).
I would rather have a language which superb type inference or other bits I can't think of at the top of my head right now.
I don't think having a native Linux module (for default of a better word) is going to be key selling point, or seen as a massive achievement, by most of the people outside the hardcore Rust backers.
I can read (and write in) Rust thank you.
My point is that the type can easily be inferred, and the constanness can be inferred too from how the code is used.
If you are writing code where a variable is changed, you need to go "back up", and add a mut, the same way in the "old C++ style" code, you need to change the declared type. Nowadays, a lot of C++ code is using auto, and let the compiler infer the type (my point is auto is also pointless).
I looked at the linked provided, and could not help noticing the rustification of C++, i.e. the usage of new "box" and "arc" library element.
I must admit I did not read everything, but it seems that new C++ "variables" are constant by default (like Rust), and modifications must be prefixed by mut (while in Rust, mut is part of the declaration only).
To me, it seems redundant, because if I declare "vector<string_view> views { };", unless a non const function is called on views, or views is used as (mutable) reference, there is not need to place "mut" in front of it, e.g. in "mut views.push_back("From a string literal");".
I know, and the compiler would know that at the point of entry of push_back, views is mutated (and the warning remains valid).
In 2024, surely, we can do better in term of type inference, and constantness verification.
x = 1; (why would I put auto or let on the left side of x? and why would I point the type? 1 is an int and if x is not modified anywhere, surely, it should be const, or better constexpr)
x += 1; I know at this stage x was a variable
I do not see the point of Rust's full declaration "let mut x: int = 1;".
My 2 cents... using an over simplistic view of the world.
There is a technical tradition (as opposed to technical debt) that sees Linux linked to the C language, which was the best choice available at the time for reasons that don't matter (my argument is valid for any OS and any language).
To put in simplistic words, there is a 1:1 between the way Linux/Unix and C see the world. One could say C is the only recognised/supported language in Linux.
Adding another language (Rust, Go, Kotlin, etc) means you move from a 1:1 mapping to a 1:n mapping, where a single change anywhere means n other changes (or n-1 if one argues OS and C are the same thing, when you set C lib apart).
Adding a single new language means a lot more work, especially, if the new language (or its libraries) keep changing its specifications all the time.
I believe this is what is stated by the person who said "Here's the thing, you're not going to force all of us to learn Rust". It is first about learning Rust obviously, but is also unrealistic in term of maintenance cost.
In a Client/Server architecture, it is the Server that (should) decide about the protocol to communicate with the Server, not the clients.
Here, we have this relationship "OS <-- Programming language[i] <-- libraries[i,j]", and and update on libraries[i,j] is (perceived to be) forcing updates on OS, and all libraries[k != i,j].
I did not watch the entire video, or followed all the Rust vs/with Linux videos available, however, it seems to me that
1. the Linux community has already lots of work to do without Rust.
2. a chunk of the Rust community *seems to* want to link forever Rust and Linux (arguments made above)
3. a chunk of the Rust community *seems to* be determined to have some OS component(s) written in Rust as the ultimate validation of their language.
4. a chunk of the Rust community does some cool stuff with the language itself, to convince help existing *users*.
If some of the Rust community think 2 and 3 are the best way, I would respectfully suggest spending more time on 4, and a few additional points:
4. I do not see much trying to onboard new users, and make the language simpler because it's getting worse than C++ on a daily basis (same comment with some of the std libraries).
5. Write RustOS! Problem solved! Why trying fixing something that cannot be fixed, while you can write your a perfect OS? Many would prefer that. (There is big market with less tech debt, look at what Android accomplished)
Apple was fined for “misleading commercial practise”.
The fine of €25m is in line with the sentencing guideline of 10% of the average turnaround (over the last 3 years) of Apple France, which was about €200m in 2018.
The amount has nothing to do with global turnaround (because French law stop at the French border!) and any kind of totally made up number made by a legal system making up stuff as they go (like the British legal system).
Apple clearly accepted the fine.
At least France is applying the law, and nothing but the law.
I’d love see something similar in the UK (having migrated here long ago).
Links below, in French.
https://www.economie.gouv.fr/dgccrf/Publication/Vie-pratique/Fiches-pratiques/Pratiques-commerciales-trompeuses?fbclid=IwAR3aKIrhzq_wO9UFfZhuEp6mSzdy2J95gxgCpeiUUbKah6xPGCu_9BotEkA
https://www.societe.com/societe/apple-france-322120916.html
A long time ago, I was supposed to take a flight to one of our office at investment-bank-of-far-west.
The flight was booked long ahead the trip, and for once, nice-airline was cheaper, with the extra benefit of free chauffeur transport in and out of the airport, both legs of the trip (so 4 trip in and out of airport, maybe worth about £200-300 at the time).
One week before the trip, the flight was changed to crappy-airline, because their flight was £50 cheaper (no transport included), and it was company policy to take the cheapest flight (without any consideration of the other transports).
I told our team assistant the taxi alone would be far more in excess of the £50 difference and she did her best to try to convince the expense department... with no success.
[names have been changed to protect the guilty]
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
