Christ. Imagine if bridges, skyscrapers, dams, cars, airplanes were designed and built like that.
I vibeslopped thousands of pages of blueprints, nobody reviewed them, but another team of digital monkeys with the intellect of an ant have already built the bridge, and it seems to not have collapsed yet, so we're already directing traffic there.
I can't imagine actual engineers feeling anything but deepest contempt for this industry.
"Actual engineers" don't really care about software engineering, much less a strong emotion at all like the "deepest contempt" and many of them already vibe code today for their work anyway.
Oh no, we do, because the software world has been abusing what engineering means for decades, in order to inflate job titles. Most people are programmers, not software engineers, and that's OK.
What we do is absolutely engineering, there’s just a lot less credentialing upfront and rigor before something is released, because usually people’s lives do not depend on it and it’s easy to release updates.
The credentials and rigor are what Professional Engineering is supposed to include. The credentials help give bite to Ethics Boards and other tools used to keep the entire profession honest and safe. The rigor is supposed to include things like making sure that you are solving the right problems.
Many people's lives do depend on software today. Insurance software dictates who gets treatment and who doesn't; that's real lives at stake. Finance software controls access to things like food and shelter; that's real lives at stake. Firmware in prosthetics and diabetic injectors and so on and so forth. Software runs the world, we pat ourselves on the back saying, but forget the world is full of real lives.
Sure, I think many of us are doing the best engineering work that we can given the industry situation. I've also seen so many of my peers, some of our brightest minds, waste their careers on stuff that a proper Ethics Board might stop or at least ameliorate. I can work to be the best engineer I can be and still wish we were an industry that actually respected engineering, not just used the title like a party favor that has no inherent meaning.
Maybe you're an outlier seeing as you're even on this forum. Most other non software engineers I know do not give a single thought about "title inflation," it does not even register in their minds as a topic to think about.
My resume includes a bunch of time at a primarily Civil Engineering firm and one of the things I took away from that was also some respect for this "title inflation" issue. That company would not allow any "Engineer" in a title that didn't involve someone without up-to-date PE credentials. Technically my title the whole time there was "Senior Software Developer". I still feel guilty switching my resume back to "Senior Software Engineer" to not have to explain that "gap" to software interviewer who somehow think "Developer" is a less important title than "Engineer" and don't understand title inflation in our industry.
(At one point I even debated the value of getting PE credentials at my age for extra leverage in that company.)
> already built the bridge, and it seems to not have collapsed yet, so we're already directing traffic there.
“Actual” engineering went through a phase where bridges and other structures did collapse due to structural flaws - it’s not like they magically figured out ahead of time how to avoid that.
Now, they can build structures that are some specified tolerance away from collapsing, but that’s only the case because the edges of what was possible were explored.
It's better than any of them for random bullshit you've found somewhere on the internet since it provides a far stronger security boundary than any standalone pdf reader. For trusted documents, I agree.
SQLite definitely seems like a poor choice for dealing with many concurrent requests.
Maybe it's improved since I last used it, but to my knowledge SQLite essentially forces all writes to be serialised, at risk of data corruption otherwise.
There are tricks for improving the performance such as WALs, but that is merely a performance boost rather than genuine concurrency with things like row-level locks that you might find in other databases.
I guess if the whole thing is architected with a write-through cache that handles concurrent writes and deals with serialising all the writes, then it can be a single writer streaming changes through to the database, but then you still have a point of serialisation, it just will manifest itself slightly differently.
And SQLite is something that will give you constraints you will always have to consider.
Whereas running mariadb or postgres on the same machine would deliver similar benefits without a risky migration.
If your DB is small enough to run as a SQLite database, then it probably ought to have never been on a different machine in the first place.
There is a very happy medium between SQLite and a database on a different machine, one I am continually surprised to see people ignore.
> SQLite definitely seems like a poor choice for dealing with many concurrent requests
Can you qualify "many"? SQLite easily handles 100k+ writes per second and it's not hard to have app layer code serialize and batch writes to take advantage of that speed. Concurrent writes require a ton of overhead and your system and code can be quite a lot faster and simpler if you just skip the idea of them altogether.
Can't you do infinity read replicas? I don't think the write load on lobster.rs is severe - maybe 1 comment/sec, with an acceptable replication delay of 60 sec?
If you can do that, you can have infinity instances.
With WAL, you don't need read replicas, you can have lots of readers and they don't get blocked by writers.
As an aside, on replication, eventual consistency is not a panacea:
If I make this comment, it's absolutely fine if you don't see it for a minute.
If I make this comment, it's absolutely broken if I then don't see it on my subsequent requests. I'll think the site has broken, and try to resubmit my comment.
You can relatively easily work around that one by pinning people to instances, but that's still yet another thing to consider, and those kinds of considerations add up when you're dealing with distributed systems.
However, this a single instance, it's way too early to talk about replication.
Given that just hitting their front-page is taking 6+ seconds, they've got a performance problem that needs fixing, and my hunch is that they have some kind of "last accessed" database entry, which turns every request into a write.
They could have one SQLite instance per user and then have a single sweeper that goes through all last writes and then replicates it to the main instance - eventual consistency fanned out across files
So now you're introducing even more processes, even more latency and complexity, and for what benefit?
Eventual consistency on users would make it difficult to do things like "WHERE !user.is_banned" when getting the stories, so you need to keep your users database tightly synchronised. Sure, you could pro-actively delete or mark comments when deleting users, but now you're risking having the ban itself fail, and have also now added a much longer write operation, as you have to mark all those comments deleted. And long running writes is the one thing you desperately need to avoid in SQLite.
And why go to all that effort when you could avoid all that effort by running a database which allows concurrent writes on the machine local to the web application?
All the benefits of machine-local latency, and all the benefits of concurrent writers and transaction isolation.
I wouldn't expect that problem to be solved at the database layer, that's what http caches are for, then application level in-memory caches, then finally if neither of those hit, go to the database.
For example, one of the biggest optimisations that Hacker news does is that it serves logged out users from a cached copy of the front-page.
Logged out users don't care/notice about comment counts, they don't notice that it doesn't update as often, they can't be hiding articles so you can serve the same front-page to the millions of anonymous users and bots, and update that cached copy once and on a slower cadence than every request.
Not sure if this is SQLite or driver/Rails issues? We use it for sites and systems with a lot more (but similar) traffic and have no issues; we did write the drivers we use ourselves (for Node) as we got into much issues with the popular/existing ones.
I jsut had this happen - it was my first visit to the site and probably my second page load. Tried opening the About page and it was completely blank. Thought it was odd & reloaded, which rendered correctly.
What's weird is with Firefox for Android it's so difficult erasing a site from being remembered. Once visited, in my experience, even after deleting the history entry and last closed tabs item it still auto completes the domain in the addressbar (when it didn't before) and the only workaround is a full history wipe (since the Android version offers no granular timeframe like the desktop version).
So if accidentally clicking some link from some other app that auto opens the default browser it's a PITA to get FF for Android to forget about it.
Just want to add that we have the same feature in Ghostel.
As it copies stuff to a remote host, automatic ssh injection is disabled by default but you can enable it by setting `ghostel-tramp-shell-integration` to true.
Cookies can be encrypted and signed and contain whatever information you want, not just some random token that has to be looked up in the database to be actually useful.
This is what aspnet core does by default if you enable cookie-based authentication. Gives you the best of both worlds.
I vibeslopped thousands of pages of blueprints, nobody reviewed them, but another team of digital monkeys with the intellect of an ant have already built the bridge, and it seems to not have collapsed yet, so we're already directing traffic there.
I can't imagine actual engineers feeling anything but deepest contempt for this industry.