On Learning Rust and Go: Migrating Away from Python

This is because what you call "systems" is not the "systems" that the lack of GC would benefit from. For all intents and purposes Kubernetes could be written in Python or any other general purpose programming language (and for example OpenStack is in fact written in Python).

On the other hand, systems like "writing an operating system kernel" or "running on a microcontroller" are things where GC might indeed be problematic and/or impractical.

It's possible to start using type hints without migrating to Python 3, and it's possible to migrate to Python 3 without using type hints. They're almost orthogonal.

It's weird to bring it up like this - do you have any experience migrating code to Python 3?

You were recently warned by a moderator to stop making sarcastic and unsubstantive comments[0], so I don't think it's me who has trouble reading your tone.

> I believe it’s important to refute the very frequent, baseless claims that are often made on Hacker News that claim that functional programming or static typing can make any difference on the reliability or rate of defects in software: they cannot and do not.

Any comments I have made regarding the benefits of FP and static typing are anecdotal, and are therefore not baseless.

There's also anecdata like this[1], which further refutes the point you're repeatedly trying to make.

> and we all admit that there is no difference in terms of safety, robustness, performance, reliability, readability, etc.

That doesn't match my experience. My experience has been that it is cheaper for me to run my businesses on Haskell and Elm, as opposed to Ruby and [plain] JavaScript. I've tried both approaches, and I perceive a difference.

> As long as everyone is essentially willing to accept a No Free Lunch theorem about programming languages, then I don’t care what language people like to use or happen to prefer for personal reasons.

I'll accept there's no free lunch — my technology choices aren't a panacea. They do make a difference to my business however, and as a business owner I am perfectly within my rights to make that judgement call.

> I’m not attacking any such preferences.

You certainly seem to be.

[0]: https://news.ycombinator.com/item?id=19241069 [1]: https://twitter.com/rtfeldman/status/961051166783213570?lang...

Steve, this is a cop out. There's nothing in Rust that can't be implemented in C or any other Turing complete language, including stack unwinding, invoke, or anything else. It may be inconvenient for Rust to use or not-use some feature of LLVM, but that's not the same thing.

Being able to implement something does not mean that by implementing it a different way, it will certainly be faster. And that's what we're talking about here, compilation speed, not computational equivalence.

We find tons of bugs in LLVM due to using certain features (like noalias) that are used a lot by Rust and very, very little by current C or C++ codebases. That shouldn't be particularly surprising. Nor should it be surprising that LLVM is mostly optimized for making C and C++ compilation times fast, and not necessarily other languages.

Again, as I said, it's a complex, multi-faceted problem. You can't just say "well, Zig compiles to LLVM, and it compiles fast, checkmate." That's not how engineering works.

(And, note that FastISel is "This is a fast-path instruction selection class that generates poor code and doesn't support illegal types or non-trivial lowering, but runs quickly." So, the thing I'm talking about is a thing that would help debug build times, but not production build times. I'm not claiming that this one specific thing is the root cause of poor compile times, in fact, I'm claiming the opposite: there are a number of different things that all come together to lead to compile times being not as fast as we'd like.)