You seem to have the idea that there are “people who want RT” and they’ll overcome any inconvenience to get it, therefore making RT more convenient to use won’t increase use of it.

Clearly nonsense, and I think the GPS analogy is a good one. My mum isn’t “a person who wants GPS” and she would never have bought a GPS device in the 00s, but she uses one now because it’s conveniently already available in her phone.

Only a Linux user’s answer to “how do I install software that’s not packaged for my distro” would be “don’t”.

I don’t think so. At this point Linux isn’t really held back by software availability - 90% of things are web based now and games apparently work pretty well (certainly better than on Mac).

The main issue is hardware support and driver quality. Especially on laptops, if you install Linux you’re really rolling the dice on whether or not you’ll get something that works.

Someone always replies to comments like these with “it works for me!” which is not really relevant when it has to work for everyone.

For a while at work I was in the Linux slack channel even when I was using a Mac, just to follow the amusing problems people had (and they had a lot!).

Then I moved jobs and have a Linux laptop… I get to experience it first hand. Hard reboot when it runs out of RAM, or 20% or the time when you undock it. Doesn’t work at 60Hz/4K on some work monitors but only if you are using HDMI. The exact same laptop model & OS works for other people. Battery life is hilarious. I don’t think I’ve ever got over 2 hours.

In VSCode the best answer by far is Pylance, which uses Pyright under the hood for type analysis.

Unfortunately while Pyright is open source, Pylance isn’t (part of Microsoft’s strategy to maintain control over VSCode), so you can’t use it in Emacs.

Still, I would give the Pyright LSP server a try. I haven’t used it but I would guess it will give you type error squiggles but maybe not code completion / go-to-definition.

Ruff is really a different thing - it is a linter like Pylint, so it only gives you some hints and fixits. You can maybe install it in addition to Pyright if you can be bothered.

Btw Pyright is far superior to Mypy - even with --strict. I would ditch Mypy asap.

Ah yeah I misread your comment. 100% agree.

It’s because

1. They’re old and they don’t want to have to spend time learning something new.
2. They spent a lot of time learning C and getting moderately good at it. They don’t want that knowledge to become obsolete.
3. They currently don’t know Rust, and don’t want to feel like the thing they do know is no longer the best option.
4. They aren’t the ones with the idea to use Rust, and they don’t want to lose face by accepting that someone other than them had a good idea. Especially not some young upstarts.
5. Supporting Rust is extra work for them and they don’t care about memory safety or strong types etc.

In order to avoid losing face they’ll come up with endless plausible technical reasons why you can’t use Rust in order to hide the real reasons. They may not even realise they’re doing it.

Some of the reasons might even be genuinely good reasons, but they’ll come up with them as an “aha! So that’s why it’s impossible” rather than a “hmm that’s an issue we’ll have to solve”.

It’s not just Rust Vs C. This naysaying happens wherever there’s a new thing that’s better than the established old thing. It’s a basic human tendancy.

Fortunately not everyone is like that. Linus seems in favour of Rust which is a very good sign.

From what I could tell it’s just because he cared about things a lot, and maybe is a little on the spectrum. He definitely wasn’t wrong, and maybe other people would have just given up and gone on with their lives but I don’t think that’s necessarily a trait to encourage.

To put it another way, sometimes when people kick up a fuss it’s because they are obstinate naysayers, and sometimes it’s because they’re doggedly holding decision makers to account. This seemed more like the latter from what I read.

Well, in fairness imagine if Guido did become a racist sexist arsehole. I don’t think he should be immune.

But clearly this situation is not right.

valid criticism of his own defense

To be clear that post makes a valid point (don’t defend people just because they seem nice or dedicated or whatever), but it isn’t a valid criticism of Chris’s post because he didn’t do that.

He did say Tim is nice and dedicated etc. etc. but he also went through the specific crimes that Tim was supposed to have committed and refuted them.

I read a load of Tim’s comments and this was definitely a case of the CoC people getting annoyed with someone who disagreed with them and wouldn’t give up. There wasn’t anything remotely ban-worthy.

Should what be handled? Security vulnerabilities? Here’s how you should handle security bugs differently to other bugs:

1. Report them separately and clearly. Don’t hide by omission the fact that they are security bugs (common practice in Linux apparently). Coordinate with major vendors how to push fixes.

2. They are generally more important than other bugs so you should put more effort into detecting and preventing them. E.g. using fuzzing, sandboxing, formal methods, safer languages, safety annotations, etc.

3. They have high value on the grey market and people actively try to create them, so you need to design your system under that assumption. An obvious thing to do is software isolation so a bug in - to pick a random example xz - can’t bring down ssh. Software isolation, microkernels, sandboxing etc. help with this.

There’s no way you can say “they’re just bugs”. Maybe in the 80s. It’s not the 80s.

security vulnerabilities are simply bugs

I don’t know how he can still maintain this clearly insane stance. Pride?

Torvalds expressed disappointment in the slow adoption of Rust due to factors like resistance from older kernel developers and instability in Rust infrastructure.

This is a good sign at least!

potential for AI tools to assist in code review and bug detection

Definitely agree here. One thing I really liked that I saw a while ago is colour coding code based on how “surprising” each token was to the LLM, the idea being bugs would be more surprising. Neat idea. It didn’t seem to actually work very well but maybe it could be improved.

Biggest issue I have is that no company I’ve worked for is ever going to be ok with sending our code to some AI company’s servers, and the options for local models are super limited. So I can’t actually use any of this stuff except for hobbies.

I dunno maybe once a week or so? We don’t actually have a system that detects if your pip install is out of sync with pyproject.toml yet so I run it occasionally just to make sure.

And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want.

Oo hello. Didn’t know that’s what you were doing these days! Hope it goes well, though I’d be nervous about a realistic business plan.

Anyway, yeah bit too late for Python.

they wouldn’t have made a different tool altogether if it was really a 1:1 replacement

Why not? It’s 10x faster.

I think it might have some other new features but you don’t need to use those.

i doubt one person on the team could be using uv while everyone else sticks to pip

This is exactly what we do at work. There’s no way I could convince everyone to switch to uv so I just switch between them based on an environment variable.

It even supports random stuff like pip install --config-settings editable_mode=compat --editable foo which is required for static tooling to work (e.g. Pyright).

you generally use a SAT solver for dependency resolution (unless you don’t care for correctness)

Actually Go’s dependency system is specifically designed to avoid the need for global constraint solvers. Go has the most modern and elegant dependency versioning system that I’m aware of. Python was designed before people realised that it’s dependency style was a mistake.

https://research.swtch.com/vgo-principles

uv is a drop-in replacement for pip. There’s no extra standard. It’s pareto better. Honestly the Python community would do the world a favour if the deprecated pip and adopted uv as the official tool, but you can guess how likely that is…

uv is fantastic. I would highly recommend it. I’ve used it in a quite complex environment, with no issues (quite an achievement!) and it’s about 10x faster than pip.

I mean… I guess it’s not surprising given uv is written in Rust and pip is written in Python, but even so given pip is surely IO bound I was expecting something like 4x improvement. 10x is impressive.

Yes. For the project I work on pip install takes about 60 seconds and replacing it with uv reduces that to about 7 seconds. That’s a very significant improvement. Much less annoying interactively and in CI we do this multiple times so it saves a significant chunk of time.

The only good free option for that is SolveSpace. Don’t bother with FreeCAD. It still isn’t usable. SolveSpace is remarkably good for an open source CAD program.

It does have some notable missing features though, e.g. no bevels, fillets, drafts, etc. and last time I used it it had accuracy issues with small holes. But for your use case it’s probably fine.

I never did a CS degree but recently I’ve been doing some things that make me wish I had. But it isn’t any of this stuff which seems mostly programming things that you can easily learn outside academia.

The stuff I would like to understand which I haven’t yet been able to learn on my own is the hard computer sciency stuff: lambda calculus, type inference (how do you read that weird judgement syntax?), how SAT/SMT solvers work, dependent typing systems… Does anyone have any good resources for those sorts of things?