muh io bound

🤣

If the DB is IO-bound, and "slow languages" don't matter because "IO bound", then show me the DB you're using implemented in a slow language.

It's hilarious how op is being this stupidly unaware, even within his stupid false argument which is provided as a supposed given.

How are people seriously engaging with this blog fart full of false premises and contradictions?

Optimising too early is the root of all evil or something like that

I find it funny you're hating on python right after praising vibe coded slop :D

Or maybe that was just sarcasm

Putting everything behind a VPN is useless if i give people who routinely click phishing links (then ask me for help when/if they realize their mistake, that's how I know) access to said VPN

99 times out of 100 a well used open source program written in any language is going to be more secure than something vibe coded in rust. Sure you wont get memory bugs (probably, if you're just vibing it how do you know its not using unsafe rust?), but it is vastly more likely to just contain regular logic bugs.

There are NP problems and you should know how to assess them.

What if the language has a bad design?

Looks like someone already did.

The article is incorrect on minimum specs. There were three subsequent releases of SimCity that did have higher specs, but I got this game for Christmas and it ran on my XT clone running at 4.77Mhz or 8Mhz in "turbo" mode. With a Hercules monochrome graphics card, which the game was targeting among others - in fact, SimCity got praise for targeting that card.

So they've gotten confused with the SimCity Enhanced CD-ROM, or SimCity Classic for Windows, which had higher minimum specs.

All programming is a trade-off between what's easy for the developer and what's fast for the machine.

Sure, you could theoretically write everything in Assembly and it'd be blazingly fast; but unless you're a particularly elite developer, that process would take forever for any program more complicated than a calculator, the result would be super buggy, and those bugs would be very hard to fix.

On the other end of the spectrum, you might imagine a natural language machine learning compiler which translated directly from human prose to binary. It would be dead simple to "program" anything in; but such an application would probably be unbelievably slow, and again, have a staggering number of difficult-to-fix bugs.

Somewhere in the middle are modern programming languages that abstract away all of the stuff that's necessary but hard for humans to wrap their minds around (memory management, API interaction, network stack, etc) and let the human write clear and unambitious code to handle all of the business logic and displaying it to the user. The result won't run as blisteringly fast as writing directly in Assembly, and it won't be as quick to market as Vibes-to-ASM, but the application will be developed in a reasonable amount of time and be reasonably easy to maintain.

Can ypu add to the github issue asking to review it?

Interesting! I hadn't heard of Lean or Roc. But I do find theorem provers / dependent types a fascinating area of correct-by-construction methodology

Sure. People who do that are going to be reimplementing lots of stuff on their own and creating libraries, so they might as well leverage the work of the community.

People need to vendor their 3rd-party libraries and audit them regularly.

Lua is directly comparable to Python, as it's incredible at quasi-interactive scripting. Python actually fits better when startup time doesn't matter, while a Lua script can start and finish a dozen times before a Python process just turns on.

Filesize doesn’t matter, if the functionality is missing.

Lua is meant to be embedded into other applications, not meant to be used on its own.

Wrong. Lua is meant to be used on its own, because it's so freaking good. It provides everything one needs to begin, while allowing for a wide array of libraries to be made. But I know you haven't made any serious number of scripts in either language, simply because you claim 'filesize doesn't matter', while Lua is so fast partly because of its size.

This is a design choice, because Lua isn’t meant to be used by its own.

Wrong again. Lua is amazing on its own, but third-party libraries make it even better.

Nah just vibe code the stuff you host in Rust. These are all memory safety bugs.

My exception is Home Assistant which is unfortunately Python 🤢 but it's not exposed to the internet.

Well guess what, that’s a huge benefit for Lua because its entire total size is around 500 KB.

Filesize doesn't matter, if the functionality is missing. Lua is just not a direct comparison and replacement for Python. Penlight isn't standard library. In example if I want to write a commandline script, I better off doing it in Python. The language is much better to me, has better features, has a standard library builtin and is even installed in all Linux distributions.

Lua is meant to be embedded into other applications, not meant to be used on its own.

Lua’s problems with the absence of popular libraries aren’t because of any language issues (even the lack of null can be dealt with), but solely due to its non-adoption in the masses.

Wrong. This is a design choice, because Lua isn't meant to be used by its own. The embedded environment is meant to provide the functionality. In example in Neovim they provide their own functionality embedded within the editor. I can't use that script on a different environment.

The use case for Lua is very different from Python. It's not directly comparable, as Lua is barebones.

Yeah we used hs-opentelemetry at my last paid position. The company was an MS shop, tho so we were using ODBC to connect to MS SQL Server which doesn't have great in-process profiling. But, at least we could figure out what quer(y/ies) were running long and then we could use the MS tools to look at the plan and fiddle with that. It was also a small org, so it's not like there was a lot of internal services in one flow -- basically everything either stayed in the Web Yesod app or in the IVR app. All our profiling could have been instrumented process profiling instead of having to use otel at all.

So, I haven't seen how easy/difficult it is to actually use otel across multiple internal service calls to satisfy one external request.

Oh really? Well guess what, that's a huge benefit for Lua because its entire total size is around 500 KB. It's loaded into memory and executed start to finish faster than you blink. If you need a ‘standard library’, just use Penlight. As I already mentioned, vast majority of libraries for Lua are written in... Lua itself, because it's so goddamn fast. I'm using Fennel, the Lua Lisp that's transcribed on-the-fly, and it's still faster than Python. Lua is great for interactive tasks like desktop automation, e.g. with Alfred, Hammerspoon (which latter uses Lua throughout), or for scripting in Termux on the phone where Python would kill the memory immediately.

Lua's problems with the absence of popular libraries aren't because of any language issues (even the lack of null can be dealt with), but solely due to its non-adoption in the masses. It is very popular as an embedded language in gaming, though, and that's not a coincidence, because it fits that niche precisely because of its small size and extraordinary speed.

If you didn’t use a profiler, then how can you be sure that the issue was Python and not something else?

It was a relatively simple program and I am good at programming.

The point is, I put the same amount of effort into writing the same program in Python and Rust, and Rust was 50x faster. With AI, I don't see any reason to use Python these days anyway. I never bought the productivity arguments before (Rust is easily as productive as Python), but with AI Rust is definitely more productive than Python because of the much stronger static checks.

It is, yes. But I also commented on Lua vs Python, and if you even try to time them, Lua scripts will be finished before Python starts up. Lua is so fast that people mostly don't bother making libs for it in C, the fucking interpreter is quick enough for folks to skip any kind of compiling and just write libraries in the interpreted language. Oh, didn't I mention? The startup thing is with the interpreter, without any kind of bytescript, JIT and such.

In the same vein, the K and Q languages and the KDB+ database by Arthur Whitney are so goddamn fast at array processing that they're used in banking for decades despite their extremely inscrutable syntax that would shear any Python programmer's head clean off. They just stay in the cache at most times. And they are also interpreted, not compiled at any time.

Python suffers from the same shit as Java, it has to initialize hundreds of objects before the main program even starts, and then it creates hundreds more. Neither Lua nor JavaScript do that. PHP does to some extent, but the fucker is so fast that it can recreate the entire runtime context on every single request and then drop all of it afterwards, and it's still quicker than Python.

VPN enrollment is scanning a qr code nowadays. Or site2site, with a "plug this box into your network' really shouldn't be an obstacle in the year of the lord 2026