Definitely a high usefulness-to-complexity ratio. But IMO the core advantage of Make is that most people already know it and have it installed (except on Windows).

By the time you need something complex enough that Make can't handle it (e.g. if you get into recursive Make) then you're better off using something like Bazel or Buck2 which also solves a bunch of other builds system problems (missing dependencies, early cut-off, remote builds, etc.).

However this does sound very useful for wrangling lots of other broken build systems - I can totally see why Buildroot are looking at it.

I recently tried to create a basic Linux system from scratch (OpenSBI + Linux + Busybox + ...) which is basically what Buildroot does, and it's a right pain because there are dependencies between different build systems, some of them don't actually rebuild properly when dependencies change (cough OpenSBI)... This feels like it could cajole them into something that actually works.

Yeah I agree. It's often easier to start from something that's wrong than a blank page.

Sure, but there are a gazillion forum websites already. I'd just use an existing one. The one D uses is the best I've ever used. I think it's actually written in D, which is a very niche language but way nicer than Ruby.

Wow, that activated some seriously ancient neurons... I just looked up some of the models it supports and surprisingly they were made within the last decade. For some reason there's still a market for cheap dedicated MP3 players.

I guess they cost basically nothing to manufacture and some people might need them...

It's not because people are sensitive, it's because Rust gets a lot of dumb criticism and people are tired of it.

But don’t you loose polymorphism?

No. You'll have to be more specific about what kind of polymorphism you mean (it's an overloaded term), but you can have type unions, like int | str.

Your points 1-3 are handled by running the code and reading the error messages, if any

Not unless you have ridiculously exhaustive tests, which you definitely don't. And running tests is still slower than your editor telling you of your mistake immediately.

I probably didn't explain 4-6 well enough if you haven't actually ever used static types.

They make it easier to navigate because your IDE now understands your code and you can do things like "find all references", and "go to definition". With static types you can e.g. ctrl-click on mystruct.myfield and it will go straight to the definition of myfield.

They make the code easier to understand because knowing the types of variables tells you a lot of information about what they are and how to use them. You'll often see in untyped code people add comments saying what type things are anyway.

Refactoring is easier because your IDE understands your code, so you can do things like renaming variables and moving code and it will update all the things it needs to correctly. Refactoring is also one of those areas where it tends to catch a lot of mistakes. E.g. if you change the type of something or the parameters of a function, it's very easily to miss one place where it was used.

I don't think "you need to learn it" really counts as slowing down development. It's not that hard anyway.

I can understand the appeal for enterprise code but that kind of project seems doomed to go against the Zen of Python anyways, so it’s probably not the best language for that.

It's probably best not to use Python for anything, but here we are.

I will grant that data science is probably one of the very few areas where you may not want to bother, since I would imagine most of your code is run exactly once. So that might explain why you don't see it as worthwhile. For code that is long-lived it is very very obviously worth it.

How powerful do you want it? Python's type system is actually pretty good already and relatively sound when checked with Pyright (not Mypy though).

It's not Typescript-level, but it's better than e.g. Java or C++.

The main problem is Python developers writing code that can't be statically type checked. E.g. using magically generate method names via __dict__ or whatever (I think lxml does that).

Yeah I just took a look at it. First thing I did was click on the "source" tab on a repo. That actually makes the source tab disappear? Clearly not designed by anyone who has any experience designing sane UI.

I think Gitlab and Forgejo are better options, and not run by a creep. Forgejo is similarly fast and actually has a sane UI. The tabs don't disappear!

Yes that is a good rule but the problem is he doesn't just respectfully criticise behaviour, he rudely attacks it. "This code doesn't meet the standards we require" is ok. "Your code is garbage. Again!" is absolutely not.

Imagine if you said that at work. That's a trip to HR anywhere I've worked.

If you use VSCode, open both files and then ctrl-shift-P "Compare active file with ..."

You're welcome.

I just looked up Deno and it’s part of an NPM stack.

It's not. It supports NPM modules for backwards compatibility, but the whole point is that it doesn't inherit the NPM tooling mess. You can go from a new Linux install to a running Fresh project in 3 commands.

You're right of course. I think the issue is that Linux doesn't care about the UI. As far as it is concerned GUI is just another program. That's the same reason you don't have things like ctrl-alt-del on Linux.