Posts by Phil Lord 150 publicly visible posts • joined 22 Jul 2011
I said that there are worse things you can do in. There are better things as well, and this is no doubt why they are or have fixed it.
In the end, Rust as a language is designed to protect against a number of things, including memory safety. Jumping and saying "look, here is a bug that is not about memory safety, it's all a waste of time" is hardly a strong riposte.
I think that your analogy is wrong. If you compare C to Python, you are being asked to trade your sleek racing bike in for a sturdy commuter. The latter is easier. simpler to use, safer but not as fast. Comparing Rust to C, I would say you are asking to trade your sleek road bike for another sleek road bike but with electronic gear shifts.
Of course, my analogy is a bit biased. Electronic gear shifts are getting pretty embedded now and will probably take over. Rust is rather less so. It's still in that stage where everyone is looking and thinking, cool, but will it work in competition use.
If you are a bike mechanic, getting the skills for all of these is probably wise. People will still be commuting. Club riders will be using a mix of electronic and manual for some time to come.
Damn it, I was supposed to be talking about programming languages....
The Rust community are completely fine with compilers written in C and C++ I think. After all, the main Rust compiler architecture is built on LLVM which is written in C++. There are several GCC/Rust projects, including a backend.
It will take a while I am sure, but then so will the process of adding rust infrastructure to the kernel as well as getting further acceptance.
There is no problem with calling the compiler directly. Rustc is available, documented and usable.
If you have a small amount of Rust and a complex existing build system, there is nothing to stop you going that route.
"There are no novel, original or unique features in Rust"
No. I would, indeed, not expect them to use features which were completely novel, not in a language which is intended for end usage. The combination is novel, of course, although that's true for most languages.
"Because that will quickly tell me if the authors have a clue what they are doing and where the likely points of failure are."
Okay, that's good, but you haven't said anything about these really.
You are indeed correct, I don't write compilers or commercial software; I write software to support scientific research and that is my expertize. That makes me experimental by nature. But people are using it to ship software, in real environments and it is currently gaining traction. Of course, Rust might disappear. Or it might grow in size and usage. That's why you try things. Or, at least why I try things.
This really rather reads like you are saying "they didn't do it right, because they did not do it the same as they did another language". You might be right, but the process of language design might be expected to evolve even as language design does.
The question of the spec comes up now and again. It's important to some, less to others. In the days of Common Lisp and, to a less extent, Java then a spec was important because it allowed alternative implementations, and avoided a control by a single vendor. Rust does not have this, however, there is an implementation, which is free to use, which will continue to be free to use, which is backed by a foundation, which will is dedicated to this end. So, a single implementation is not so much of an issue, nor is a "main" implementation with others tracking that. It works for python and many other languages.
A spec is required for some things, though. And so people who care about that are writing one. It will track behind the language and not lead it. Again, different from CL and C. But it means that the language can evolve and new things can be tried extensively before they become part of the spec.
You say that you have found several paths to subvert memory safety. That's fine. Rust is trying to provide a memory safe subset of the language, with minimized undefined behaviour. If you can find a way to subvert memory safety that is not marked as unsafe, then you have found a bug. If it is marked as unsafe, then the misunderstanding is yours.
Rust's stated aims are fairly clear and rather far from "implementing some personal pet features". You may not value these aims; you may not think it will achieve them, fair enough, but claiming there is not justification suggests that your "quick look" may have been too quick.
I don't think porting code from C to Rust is going to happen in that many cases. At the moment, it is giving the option for new drivers to be written in Rust. Whether, Linux ends up moving toward Rust more generally remains to be seen. But I doubt that much of it will be re-written -- it's just too big a task.
Of course not, but Rust has never given that guarantee.
What it does offer is that in a subset of Rust (the safe subset) if certain classes of memory issues do occur in a piece of code, then they are due to a bug in Rust, not a bug in the code. In C, you can introduce many forms of memory error in trivial code which, in practice, means you can introduce it in any code, without it being considered a bug in C.
In terms of the underlying optimisation and compilation, that is just an implementation detail. It's changes where the bug might need to be fixed, not that it is a bug. In practice, if this kind of issue occurs at the clang/gcc level, then it's likely to affect quite a few more languages than Rust.
Is that a big thing? Maybe, maybe not. What it does do is allow a separation of concerns. Some aspects of memory safety become the job of the Rust developers rather than the end developer. It's similar to the other things you described -- the end programmer does not has to worry about loop inlining or any of the many optimisations that are being performed at clang level. It is one trick that we don't have to use any more because it's done somewhere else.
"So there'll be a bit of a consumables cost."
With the current technology that would be but, who knows, if the sponge is either expensive or replacing it is expensive, they might find an alternative.
"Well, it kinda does given how sulphuric acid is produced. And that also kinda needs fossil fuels,"
Fossil fuels are deeply embedded in our industry, so pretty much everything needs fossil fuels. Solar panels and wind turbines use fossil fuels in their production. In this case, the sulphuric acid is a component of the system, not an input, even if it needs replacing occasionally. The system will use less fossil fuels as our society does.
"sulphuric acid is a popular drying agent that just loves water, but obviously that dilutes it, so it'll need a process to re-process the water,"
Or you could just electrolyse the water in the acid. You need an acid for the electrolysis anyway, and the electrolysis will drive of the water either way. It's quite clever actually. You use a natural property of the electrolyte to attract the water. So it should come with little extra cost.
It's a lot easier to organise inside the workplace than it is outside. That's one of the reasons that it has been a protected act for many decades.
Clearly there is a risk with a company like Amazon. At the same time, this kind of action exemplifies exactly the need for a union in the first place.
The number of variables can be determined at compile time. The number of values cannot. It's references that are one of the mechanisms for achieving this.
The value "5" is a different kettle of fish. Integers are fixed in size and usually take up the same amount of space as a reference. So most languages store these directly on the stack, rather than using a reference to the heap. You are wrong if you think that there is only one value 5 in a program; there could be any number and the compiler cannot determine how many 5s there are at compile time.
It can determine how many literal 5s there are, or expressions that always evaluate to 5 (i.e. constant folding). Again, there would still be multiple copies of "5" in the program, because there is no point interning an integer. Unlike, say, a string which might very well use an interned reference.
Of course, there are circumstances when it makes sense for "5" as a value to be referenced rather than stored directly, which is when you want to add some extra behaviour to it. Atomicity, is one example. Another is when 5 is not an bounded and fixed-size integer but a number you want to be grow to any arbitrary size or precision.
As for your last comment: c.f. previous argument about civility. It is a shame that you lack it.
Rust by default does not use reference counting at runtime. Rather it determines statically at compile time when the value associated with a variable can be deallocated and does this automatically for the programmer. There is no runtime cost associated with this.
This is not always possible, of course, for example if you intern strings created across a program to save memory. For those cases, Rust has support in the standard library for a reference counted pointer. Actually two. One for single threaded use and one for threaded use. Using the wrong one (i.e. using the single threaded one across threads) is a compile time error.
So, you pay the costs for what you need and pay no cost for what you do not need.
I don't know what a reference counting variable is either. References counting is done at the level of the value. The whole point is for where you cannot determine whether multiple variables point to the same value.
To bring it to the question of Rust, it does not reference count. The language uses a system of lifetime analysis to ensure that only one variable owns a value and that value outlives all references to that value. Mostly this is done statically. For the situation where it's too complex, Rust also provides library support for reference counting values. There are also libraries which do mark-and-sweep GC. I don't know how widely used they are.
Most people who use terms like "fanboi" and accuse others of being "clueless" do not actually have "inquiring minds", they just lack civility.
GO uses "critical sections" to address the realtime problem. I'm not sure that I would distinguish between reference counting and GC. Reference counting is a form of GC as far as I can see.
Rust doesn't GC by default, but it does provide a reference counting system -- so some of the values in a program are effectively GC'd and some not.
The semi-colon in Rust has some semantic beyond the end of the line actually. Or more the lack of one. Without a semi the line becomes a function return expression.
Feels a bit ugly when you start, but works out nicely once you are used to it. Having learned it, though, I find my python code keeps breaking, when I forget to put a return statement in a one line function.
"C [...] is still a bit faster according to the article".
Yeah, the article is probably wrong there. It's very hard to compare across languages, of course, but where it has been done Rust and C come out about as fast as it is possible to come out, and much the same. GO is also very fast, even with GC.
The article is also wrong about concurrency. Rust had this well before version 1.39, it just didn't have async/await as keywords. That should be obvious really. Who would design a single-threaded programming language in the 21st century?
I think most of the articles conclusions (lone programmers vs big groups) are equally suspect. Still, the title is fun.
There are more C/C++ programmers out there than Rust, so obviously, there are more people who can teach it also.
Having said that, Rust has produced quite a large quantity of fairly good documentation, freely available, as well as a number of books that you can buy. They have also a very good and supportive community. All of which is available world wide via the magic of the web. It's how I learned Rust.
Decreasing the learning curve, indeed, is a good thing. Some of that comes from your background. Javascript programmers will probably have an easier time than C programmers, because Rust is fairly functional. And some will come from the many "quality of life" improvements that Rust has made particularly to lifetime handling. I think it is easier now than it was four years ago when I learned it, although that's hard to measure.
You aren't the only one. Quite a few people have found GO easier to learn than Rust. Although Rust has a somewhat richer semantics, some of which GO will gain over time (like generics!), which will make GO more complex.
Rust has also got easier over time. The most difficult bit is almost certainly lifetimes, and "fighting with the borrow checker" must be the most common point at which people give up. But this stage is significantly easier than in the past because the language has changed.
It does have it's own package management system. It's rather better integrated with python than pip is which feels (and is!) a bolt on.
In terms of "3rd party" packages that it is a more complex question. Rust has gone the route of a small core, with add on packages for non-core functionality. That means it can offer somewhat different stability guarantees between the core/standard library and more extended functionality. How well this works we will see in time, but it should avoid the python/java standard library of cruft issue.
The hard bit of "3rd party" is, of course, that Rust is not a product of an standard organisation. The core/std library is produced by "3rd parties" in the sense that the code is not written by the company (or foundation) that owns Rust. So some "3rd party libraries" are effectively part of Rusts extended library support. Consider clap, for example, which does command line parsing. It isn't part of the standard library, but is used by rust-lang.org in their command line documentation. Would bringing it into the standard library magically make it more secure? Or just mean that it's release cycle would be tied to Rusts?
"Which means, in my bombastic opinion, that it has the potential of following the same path as ADA"
It could do. My feeling with Rust is that the learning curve is actually getting less over time. It's easier now to learn Rust than it was in the past, mostly because the compiler handing of the hardest bit (the lifetime and borrowing rules) has got a lot cleverer.
Of course, it's hard to be sure from personal experience; I learned Rust a while back and that it feels easier to me could just be that I am better at it, but I have heard similar anecdotes from others.
"C++/Rust/OOP further that sacrifice by the concept of a v_table (jump, jump)."
Rust isn't OOP though, and doesn't use a v_table. Most calls are statically determined at compile time. Polymorphism is achieved through the use of generics and the code is monomorphised to allow this.
There are exceptions because a dynamic dispatch allows you to do things that are hard otherwise. One of the changes with the Rust 2018 edition is the introduction of an optional keyword to mark usage; that will become a hard requirement for Rust 2021.
Well, C was a modern language once, so clearly you think that it lived to it's hype.
In the end, while there will always been some guess work, the real solution is to try things out, slowly and cautiously, see if they work and make an judgement at the end of it, rather than just assuming that "C is the safest bet" based on your prejudices.
Rust is designed to fill a hole and address a variety of problems that C does have. There is no serious doubt that C has its problems and allows a wide variety of bugs which occur with regularity. Rust is designed to address these; whether it will do in the context of the linux kernel or not is what we do not know yet. This is an attempt to answer that question.
I struggle to see how this makes sense. Good coders will use the tools that are available to them.
Rust is one of those tools, and having the code compile does indeed detect lots of errors that you might need to test for in other languages. More time fighting the compiler in its sometimes baroque ways; less time writing tests. That's an engineering compromise like any other.
I've stopped worrying about lift doors shutting one me also, and don't use a cloth when taking an light bulb out any more, so perhaps I am becoming sloppy and have too much blind faith.
> "The university's apparent belief that research can only be unethical if it involves human subjects is just plain wrong. "
I think it's the apparent belief that is wrong. The University will know that things other than human subject research can be unethical. In fact, in this case, the problem is likely that they hadn't worked out that it was effectively human subject research. My guess is they read "tool and method for discovering security flaws".
If they have read, "we will see if people can detect our attempt to deceive them", then the panel would have said no.
Ah, but which law is that?
In this case, the woman in question was 17. So capable of making an informed decision? Well, not in the territory that these events are said to have happened where the age of consent was (and maybe still is) 18.
It was foolish to have such a nuanced argument on an email list; it was likely to be misunderstood there as it is here, but that was the argument.
Rust is a little unusual in it's loops. But as `loop` and `break` generalize both `while` and `do while`.
The syntax is occasionally overly complex -- like most C syntax languages the paren matching can get a bit much; but it's okay to my mind. Then I like lisp, so perhaps I am odd here.
I can see that you have some problems with Rust, but it's a shame that you don't say what they are, rather than alluding to other languages. What part of the Steelman requirements is it that you think Rust needs?
And the idea that Rust has a weak type system similar to Python sits poorly with me. Rust's type system is really nothing like Python. What is the weakness in Rust's type system that you dislike? Rather than just referring to Python?
No, that's not true. If you run "venv/bin/python file.py" it will run in the virtual env, if the virtual env has been created. And if you have used venv as the file name, which you don't have to. And, of course, when anyone else runs python as god intends using "python file.py", they will get a different experience. Unless you have set up "#!/usr/bin/env python3" in your magic cookie. Although, if are on a shared computer and in the meantime someone has come along and updated your python, you might get a different version of python from the last time.
And so on, and so on.
Almost all of the functionality is there, but it's not bundled and packaged (pun!) nicely. And TMTOWTDI, which is not right. This is python not perl. There should be one way. That one way should be simply and easy. It might help
I have hope. There is pyproject.toml and associated PEPs. But python is way behind the curve here.
It's really nothing to do with the IDE. It's a fundamental problem that the ending of a block is implicit. No editor can ever no with certainly while moving text, where the end of the block is, nor where you as the user intend the end of the block to be.
Curiously you see the same problem in Word. If you have a piece of text in Italics and you cut and paste this, or paste any text to it, you cannot tell Word whether you have intend to be inside the end of the italic block or past the end of the italic block. Now in the case of Word, there really is an end of Italic thing in the data model, but it makes no difference at all, because you, the user, cannot see it. You cannot tell Word whether to include it or not and Word cannot tell you whether it has included it or not.
Practical upshot, sometimes when you cut and paste, suddenly a pile of text will appear in Italics when it shouldn't or vice versa. It's an inconsistent user experience and that inconsistency is irritating.
I don't use a modern IDE. I write code in Emacs or Vim, both of which are forty years old.
I'd agree whitespace doesn't cause bugs. But it makes the editor experience more clunky, because the editor has to infer when a block ends.
Imagine you are copying a piece of text into a function, behind a for loop. Your editor doesn't know whether you are pasting at the level of the function or the for loop. If it gets it wrong, you have to manually re-indent the code. That's fine is the pasted cost is all at one level, but if it includes indented blocks itself, that can break as well but not indenting correct. Still at least it is not all bad. You used to be able to mix tabs and spaces; I used to do this in an exercise with my students -- the code only ran if it looked badly indented. Python3 has killed this off, I believe.
With other languages there is an explicit start and and explicit end. Of course, there are famous bugs where white space indentation and blocks were mismatched. Python's approach sought to avoid all of those which it does. But that was 30 years ago. No one indents their code nowadays.The IDE does it. And, in languages with good tools, you run the code auto-formatting tool and lint check in your git hooks/CI.
It's not a biggie, it's a not a disaster for python and it's now not worth fixing. But, while it was an interesting design feature of the original language, 30 years on, it is clear that it was a mistake.
pip is nowhere near as good as tools used elsewhere.
Take for example, cargo and rust. I download a project, type "cargo build", "test" or "run", and it will do precisely that.
With python no. First, the project may or may not be using requirements.txt because there are several different options. pip, of course, will try to do a system wide install, unless you tell it do a user install. Although that will break if there are already dependencies with a different version number. Unless you use a venv. Which you can set up, of course. Although, if you type "python file.py" in that directory, it won't use the venv. Unless you have activated it if you shell. Or in your IDE, if you are launching from the IDE. But, that's okay. You can use pipenv which does all of this for you. Except for using requirements.txt. And it was a bit broken, although then poetry came along which is nicer, although for some reason still ignored the python version requirements, and now pipenv is better and maintained again, but perhaps poetry is still the way to go.
It works in python. But only just. You need to pick a workflow and then you need to set up your environment and then you need to follow the rules quickly and be able to debug when it goes wrong. I can get it working. But I also teach this stuff to 300 students who never done dependency management before. It's really, really not easy.
This is true. Rust has gone the approach of having a small standard library and then a dependency mechanism. This avoids the issue that Python has with a big standard library a lot of which is covered in rust (sorry, bad pun). And, so while the core of Rust is relatively stable (not compared to C) and has strong promises about forward compatibility, it's hard to get far using just Rust the language and standard library.
There needs to be an additional layer of metadata in the dependency ("crate") infrastructure that lets you know which crates are stable enough and which going to provide future stability promises. This would allow you to get some idea of how long the software that you are building on is likely to be supported for.
At the same token, Rust version moves are generally pretty easy to manage, and were fairly well tooled. They haven't got to the Python2/3 (or Perl 6!) situation so far.
> What is in some respect surprising is that 50 years on we are (in general) still developing code (whether it be ASM, C, Rust etc.) in exactly the same way as we were back then...
Perhaps that is not so surprising. All the massive changes in technology that we have both seen over the years, and here were are, writing short notes to each other in English. Not that different from a bulletin board in the late 70's.
But the languages have changed, and so have the idioms and standard practices. I routinely hack on one piece of software that has been in continuous development for 40 years. You can see the change and flow of the decades, sometimes in pieces of code that sit next to each other in the same source file. How much of this is a fashion cycle? When I see people getting excited about functional programming, like it's new, I wonder at times.
> No what was being advocated was to adopt a disciplined aka Software Engineering approach, where you will have worked out the logic and associated data structures before even opening the code development toolset.
Yes, if that helps you. But how do you do that? Keep it all in your head? Or do you use some design tool to record those data structures before you open up your code development toolset? Some clicky, pointy, UML type tool?
Personally, I've never particularly liked those. I'm just not much of a figure person; I don't draw flow charts when writing documents either. I'd rather write a set of outline notes, with some comments, which I gradually expand in to a long document. With code, I do the same thing, just using comments in a code, with some rough outline of the data structures, in code. I can't see the point of using a tool that at some point you have to say "now we stop and write these things in Rust".
The OP was advocating the same thing. Writing comments first. So straight into a code development environment.
Advocating for use of valgrind and static analysis is just suggested that people use better tools, to help them avoid problems. That makes sense. Choice of language is, likewise, just another tool.
In terms of comment driven design, rust has an integrated documentation format, which allows inline, examples that compile down to tests. This is in addition to its unit testing features. And it's support for "examples" -- longer free form source files that again are compiled and run as tests. All doable in C, all standard in Rust.
With respect to logic errors, indeed, no language can stop you from just coding the wrong thing. Although, it can stop you forgetting to handle specific cases, it can stop you from forgetting to handle return values, it can stop you from dead code, all of which are common sources of logic error.
In the end, I think, contrary to your statement are acknowledging their development process is faulty. One solution is to switch parts of the code away from C.
Not sure where you get the bit about Rust and casting. Do you have an example?
Rust does neither. You can access arrays either safely (with bounds checking) or unsafely (without). The unsafe portions are marked syntactically and semantically and clearly identifiable as such.
In actual use it favours richly functional iterators. This fulfil 95% of the use cases where C would use array access. This high level functionality is bounds safe. The underlying low level code uses non bounds checked array access, and so is unsafe, as a result of which has been heavily checked and audited.
Result: Most rust code cannot array out of bounds, and this is achieved without runtime bounds checking. It's a key example of a Rust high-level, zero cost abstraction.
Rust compiles to an intermediate representation which is then compiled down to assembly with LLVM. It also has good support for using the C ABI, or compiling down to the C ABI.
So, yes, it works with valgrind, mostly useful for when working with C built libraries. Yes, it works with profilers. I don't know about the ease of auditing generated assembly, but as it is LLVM which does this and is not rust specific, I would guess that it should be similar.
In my use of these tools, I have found them less slick than using over C, but functional, mostly either because they are harder to launch or because you had to do some name munging. This was last year, though; Rust is quite a fast moving target in this way.
Go I don't know about, as I've not used it other than playing.
These projects were done in C because there are lots of C programmers, it's fast, and when these projects were started, it was the obvious choice. Some of these are still key points: there still lots of C programmers; others are not so: C is fast, but no faster than Rust or Go. If Rust and Go continue their climb in usage, the availability of knowledge will probably change.
Is it worth moving? A whole sale re-write, almost certainly not. Whether it could be done incrementally, and whether that would be useful, I don't know. It would certainly require a substantial investment and that is perhaps the bigger issue. I am not and would not advocate wholesale porting to Rust of anything.
Could it make better use of tools? Maybe, but I doubt that the developers have not thought of using these tools. It maybe that the code is old enough that the tools work poorly, either missing problems or more likely giving a high false positive rate. For a piece of software as old and critical as GPG, changing code to avoid these kind of false positives would not strike me as good practice either. Perhaps you could try them on GPG?
In the end, though, C is just a tool. It is and will remain a useful tool, but it's not the only one and it has serious flaws. Ignoring this and blaming people for their lack of skill is and remains not sensible.
To me, this doesn't sound arrogant, but someone who is bit pissed off that after years of maintaining a piece of software, they only get any attention when they get something wrong. Then loads of people jump up and tell them how they could do it better; but no one actually helps them to make it better.
"You still need to take care in your work and be professional, only in software is that considered a burden."
At the end of the day, the programmers that introduced this bug have been maintaining a complex piece of software that has been a cornerstone of internet and software distribution, allowing signing and identification, as well as encryption. It's fair to say that the are careful and professional in this work in almost every sense, except for the "getting well paid" bit.
And, yet, these bugs happen. And have happened again and again. "They should have taken more care" is not a sensible response.
> I'm also convinced its too steep a learning curve for many C# / Java developers.
This is always hard to tell of course, but I did find Rust pretty hard to learn when I started working with it. Mostly because of the borrow checker; the actual concept is not too bad, but the consequences of lifetimes I found hard to deal with. Nowadays, it is much less of a problem. I seem to use explicit lifetimes rarely, normally just one at a time, and they just slow in there and away you go.
There are two possible reasons for this. One is that I am just a better rust programmer than I was and what used to be hard has become second nature. But, the other is that Rusts borrow checker has become noticeably more forgiving than in the past, which, of course, it has. It's quite possible that the learning curve is not what it was when you learned it.
I also think that he documentation is partly at fault; the Rust book spends too much time talking about lifetimes and leaves you feeling that Rc and the like are for desperate times. In actuality, they are there to use, effectively adding GC for when you need it.
That and the difficulty inherent in the copyright assignment process which many (but not all) GNU projects require. It's an ongoing discussion that raises itself every few years, and I suspect will eventually happen. Savannah is an a fork of sourceforge I think, and given that everyone has abandoned that is indicative.
Locking the PR involves the impact of having to delete all the daft comments of the form that we have sen here. If it is a feel-good crusade, well, that's fine. It has made something a little bit better if people are feeling good.
A PR stunt to self-promote? They just made a change. Lots of other people are doing all the self-promotion for them.
I think that would be a good argument if we didn't continually the words we use because we are industry where fashionable buzzwords are part of our meat and drink.
I mean this happens all the time, so really changing "slave" to "dependent" is really going to get lost in the noise.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
