Hacker News new | ask | show | jobs
by wiseowise 89 days ago
> but in the end it was deemed a waste of time when the whole project was terminated.

The main lesson of the story. Just pick Python and move fast, kids. It doesn’t matter how fast your software is if nobody uses it.

7 comments

This is it. Getting something on the table for stakeholders to look at trumps anything else.
It would have taken the same time, if not less, given the extra time for mitigations, trying different optimization techniques, runtimes, etc.

One of the reasons the project was killed was that we couldn't port it to our line of low powered devices without a full rewrite in C.

Please note this was more than a decade ago, way before Rust was the language it was today. I wouldn't chose anything else besides Rust today since it gives the best of both worlds: a truly high level language with low level resource controls.

I would agree except for the python part. Sure, you gotta move fast, but if you survive a year you still gotta move fast, and I’ve never seen a python code base that was still coherent after a year. Expert pythonistas will claim, truthfully, that they have such a code base but the same can be said of expert rustaceans. I would stick to typescript or even Java. It will still be a shitshow after a year but not quite as fucked as python.
https://github.com/polarsource/polar/tree/main/server

If you're writing FastAPI (and you should be if you're doing a greenfield REST API project in Python in 2026), just s/copy/steal/ what those guys are doing and you'll be fine.

You can use Go and get the best of both worlds.
One of the slowest, most ineficient code bases I've ever worked on was in Go.

The mentality was "the language is fast, so as long as it compiles we're good"... Yeah that worked out about as well as you'd expect.

But that has nothing to do with the language.
Absolutely, and it's a good language when used properly. This was more of a problem with the hype surrounding it.
> Just pick Python and move fast, kids. It doesn’t matter how fast your software is if nobody uses it.

The reason nobody uses your software could be that it is too slow. As an example, if you write a video encoder or decoder, using pure Python might work for postage-stamp sized video because today’s hardware is insanely fast, but even, it likely will be easier to get the same speed in a language that’s better suited to the task.

Learning that it’s too slow takes users.
They were the users and it was too slow for them so they switched to python. Not C++ of course, what they meant was "the libraries we wrote in C++ were too buggy and slow that using them was slower than if we just used Python."
In some cases, common sense of developers can do that, too.
And this is why pretty much all commercial software is terrible and runs slower than the equivalent 20 years ago despite incredible advance in hardware.
For lots of software there wasn't an equivalent 20 years ago because there wasn't a language that would let developers explore semi-specified domains fast enough to create something useful. Unless it was visual basic, but we can't use that, because what would all the UX people be for?
Python itself is 30 years old. What are you talking about?

Almost every mainstream languages (except Go, Swift, Kotlin and Rust) are more than 30 years old, by the way.

if input() == "dynamic scope?": defined = "happyhappy" print(defined)

I'd rather not use python. The ick gets me every time.

It killed ny formatting

    if input() == "dynamic scope?":
        defined = "happyhappy"
    print(defined)
Terrible advice. Really.

Most the the business I do is rewriting old working python prototypes to C++. Python sucks, is slow and leaks. The new C++ code does not leak, meets our performance requirements, processes items instead of 36 hour in 8 hours, and such.

We are also rewriting all the old python UI in typescript. That went not so easy yet.

And when there are still old simple python helpers, I rewrite them into perl, because this will continue to run in the next years, unlike python.