* Posts by Phil Lord

159 publicly visible posts • joined 22 Jul 2011


Rust rustles up fix for 10/10 critical command injection bug on Windows in std lib

Phil Lord

Re: Ha! Rust Is The Answer To All Our C Programming Security Issues?

I see more people who seem unreasonably triggered by the mention of Rust making this claim, just so that they can proof that it is untrue.

IPv4 address rentals to mint millions of dollars for AWS

Phil Lord

I wish they provided a nice simple and easy mechanism that you can just add IPv6 addressing to your resources.

Am I being naive to think that it should all just work these days?

New cars bought in the UK must be zero emission by 2035 – it's the law

Phil Lord

Re: Think of the Grid!

The National Grid have published an article on this. Short answer is that electric cars are not necessarily a problem.

The key points are: a) not everyone charges at the same time, including development of infrastructure to ensure this: b) oil takes a lot of energy to refine, so we should recover 4.5kWh for every gallon of petrol not used and c) electricity consumption is falling from it's peak in 2002 by about 16%, while the grid has remained the same, so we can add 16% of energy use back without problems, of which about 2/3 would be enough for electric car needs.

And, of course, all of this is happening over time. It's not a single point in time. The grid is being rebuilt anyway -- consider recent interconnect with Denmark, new sea routes Scotland to England. If the Tory moratorium on onshore wind was removed that alone might be enough to increase capacity in a way that was (reasonably) distributed across the country.


Always on the Horizon, UK must wait for megabucks EU science deal

Phil Lord

Re: And the haemorrhaging continues

Cambridge got about half a billion from Horizon and similar amounts from it's predecessors, so I don't know where you get the idea that they avoid Horizon.

Yes, indeed, Horizon and EU management is fairly hard work and they do tend to want plans and milestones and all the rest. That doesn't fit brilliantly with science always, but then this is the way of large organisations, into which category the EU fits. A large part of this stems from difficulties in early versions of Horizon with some reasonably dodgy auditing.

The work packages are not prescriptive from the EU; the scientists who write the proposals write the work packages. After which, indeed, the EU want their deliverables.

You are correct that a lot of the training grants do require mobility, and cross-country mobility. I have my doubts about that. But the EU is hardly alone in this. Quite a few people in research believe that you need to move around to be exposed to the best ideas and for cross-fertilization. I can see the argument but at the same time, while some people value travelling and living in different parts of the world, it also makes life hard. It is difficult to buy a house and raise a family when there is a strong expectation that you move every three years. Still, hardly a surprise that money comes with strings attached and that it's expenditure is expected to achieve more than just "good science".

And, indeed, there are companies who specialize in bidding for EU money; just in the same way that there are IT companies that specialize in government contracts. Bidding processes are big and complex, as is the management afterwards. So you get specialists.

So, I agree with some of what you say. But that is quite a different from what you said which is that Horizon does not produce good science. It does.

Phil Lord

Re: And the haemorrhaging continues

What are your metrics for "producing good science", because you seem to have picked a single example, then said "well in the recent past that didn't get any Horizon funding". How far back in the history of mRNA vaccines have you looked? You will not have to look far with any discovery to find that publicly funded science is part of that chain sometime in the recent past.

It's 2023 and memory overwrite bugs are not just a thing, they're still number one

Phil Lord

Re: Rust isn't the panacea

Access to shared memory across threads is controlled in Rust through it's ownership logic, and encourages the use of channels as an alternative to shared memory access.

Phil Lord

Re: Rust isn't the panacea

Even in low-level code, the number of places that you need to do unsafe operations is limited. Rust still helps by specifically indicating where those regions are with unsafe blocks. And outside of this, there are lots of operations in Rust that are not unsafe, compared to C where they would effectively be.

Of course, Rust is not a panacea. What it might be is a little bit better than C which will help somewhat with avoiding problems. That's not a bad thing.

Phil Lord

Re: > Cough, cough, use Rust.

Well, use a memory safe language. Rust is, Golang is. They just have different mechanisms for achieving it. Golang is GCd. Rust mostly uses memory recovery at compile time and GC when it can't do runtime.

So, I think golang and rust exist for pretty much the same reason.

Fed up with Python setup and packaging? Try a shot of Rye

Phil Lord

Re: No mention of pip and venv?

They work but only provide the basics in terms of convenience. For example, if you create a venv you still have to remember to activate it, either through an IDE, or on the command line (for which I use direnv. The functionality of pip depends on whether you have: `pip install numpy` will do different things depending. And, pip is not a project tool. If you copy my git repo, you need to create a venv and then run pip on requirements.txt. And, because there is no lock file, what you get might still be different from what I get. And if I have run `pip install numpy` previously, my repo might not work for you because I forgot to add it to requirements.txt.

And so on. pip and venv are potentially part of the solution, providing installation, dependency management and sandboxing. But they fall wall short in providing all of the solution. Python packaging is a mess.

Memory safety is the new black, fashionable and fit for any occasion

Phil Lord

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.

Phil Lord

It does indeed wave it's hands in the air. That is to say, it will error cleanly and exit. There are many worse things that you can do in response to unsanitized input data.

Phil Lord

Re: Safety?

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....

Linux kernel 6.1: Rusty release could be a game-changer

Phil Lord

Re: As I've written before ...

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.

Is it time to retire C and C++ for Rust in new programs?

Phil Lord

Re: Funky new ecosystems == bleeping annoying to use in an existing environment

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.

Linux luminaries discuss efforts to bring Rust to the kernel

Phil Lord

Re: Rust? Why? Amateur hour stuff...kiddie time

"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.

Phil Lord

Re: Rust? Why? Amateur hour stuff.

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.

Phil Lord

Re: Why make things slightly more complex ?

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.

Phil Lord

Re: Requiring Rust in the kernel will keep newer Linuces from running on older-arch HW

As the article says, a Rust front-end for GCC is being produced (two actually). So, yes, someone is bothered to create a Rust compiler for all the architectures that GCC supports.

Phil Lord

Re: Rust is desirable simply because of its memory safety

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.

Scientists pull hydrogen from thin air in promising clean energy move

Phil Lord

Re: The cruel realities of conservation of energy.

"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.

Amazon internal chat app that censored talk of unions and ethics may 'never launch at all'

Phil Lord

Re: Why would employees use an internal chat app?

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 Rust Foundation gets ready to Rumbul (we're sure new CEO has never, ever heard that joke before)

Phil Lord

Re: Garbage Collection

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.

Phil Lord

Re: "Reference Counted"

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.

Phil Lord

Re: Garbage Collection

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.

Phil Lord

Re: Garbage Collection

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.

Phil Lord

Re: Someone have to say it

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.

Phil Lord

Re: about that steeper learning curve...

"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.

Phil Lord

Re: about that steeper learning curve...

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.

Phil Lord

Re: Congrats

Also, alas, high competent programmers write unreliable programs.

Looking for better tools to write code with has been happening since the beginning of computer time. Why would it stop now?

Keep calm and learn Rust: We'll be seeing a lot more of the language in Linux very soon

Phil Lord

Re: I tried to love it but...

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.

Linux PC shop System76 is building a new desktop environment in Rust

Phil Lord

Re: Build back better?

You can use store the truck load of crap where ever you want. Being able to install it in user space is fantastic for getting things done is an environment where you are not otherwise allowed to install anything!

Phil Lord

Re: Build back better?

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?

Latest patches show Rust for Linux project making great strides towards the kernel

Phil Lord

Re: Next to learn

"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.

Phil Lord

Re: dis-un-de-throne C in the Linux kernel?!

"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.

Phil Lord

Re: Another dimension of complexity

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.

Facebook, it's cool to see you using Rust and joining the foundation, but please don't Zuck it up for all of us

Phil Lord

Re: Rust [ ... ] as a C/C++-like programming language

The compile time is a bit slow, but the forums are not full of people complaining that it's slow. I mean, the forums where people using Rust are.

You are correct, though, it's not very C like.

Phil Lord

Re: Rust - the language for coders who can't.

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.

University duo thought it would be cool to sneak bad code into Linux as an experiment. Of course, it absolutely backfired

Phil Lord

Re: A punitive sanction against the Uni for approving it

> "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.

FSF doubles down on Richard Stallman's return: Sure, he is 'troubling for some' but we need him, says org

Phil Lord

Re: too young, (s)he knew what (s)he was doing

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.

Google putting its trust in Rust to weed out memory bugs in Android development

Phil Lord

Re: Too bad

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.

Phil Lord

Re: Too bad

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?

Happy birthday, Python, you're 30 years old this week: Easy to learn, and the right tool at the right time

Phil Lord

Re: pip is part of all python distributions now

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.

Phil Lord

Re: At last! Reasonable reasons!

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.

Phil Lord

Re: Why do some people not like python's indentation=code block container

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.

Phil Lord

Re: pip is part of all python distributions now

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.

Popular open-source library SDL moving development to GitHub despite 'calamitous design choices' in git

Phil Lord

The UI sucks. Compare

git worktree remove fred

git branch -d fred


git branch add

which adds a branch called "add". It's all just so weird.

In Rust we trust: Shoring up Apache, ISRG ditches C, turns to wunderkind lang for new TLS crypto module

Phil Lord

Re: Can't disagree

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.

Phil Lord

Re: Valgrind says 'hi'

> 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.

Phil Lord

Re: Valgrind says 'hi'

> 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.

Phil Lord

Re: Valgrind says 'hi'

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?