Analogies to other professions give your argument an air of legitimacy, with none.
There’s plenty of people in this world who are expert programmers without following any traditional path.
“Oh yeah, like who”, you say.
Con Kolivas, anaesthetist, work on kernel schedulers including the Staircase Deadline (RSDL) scheduler which was a precursor to the Completely Fair Scheduler in Linux and the Brain Fuck Scheduler and the ck Patchset.
I found it unusable due to out of memory errors with a billion row 8 column dataset.
It needs manual tuning to avoid those errors and I couldn’t find the right incantation, nor should I need to - memory management is the job of the db, not me. Far too flakey for any production usage.
> Search the issues of the duckdb GitHub there’s at least 110 open and closed oom (out of memory) and maybe 400 to 500 that reference “memory”.
Ah, missed this the first time around. Will check this out. And yes, I noticed that DuckDB rather aggressively tries to use the resources of your computer.
I think the authors disagree with me, but I see it like a online analytical processing (OLAP) database, not like a OLTP (online transaction processing) database, so crashes are more tolerable.
Agree with your assessment of small and reliable for SQLite.
Disagree with your baseline requirement. ACID is more important for me and does not contain `No crashes`.
Intuition is relative: when I first encountered unix-style synchronous, threaded IO, I found it awkward and difficult to reason about. I had grown up on the callback-driven classic Mac OS, where you never waited on the results of an IO call because that would freeze the UI; the asynchronous model felt like the normal and straightforward one.
It is a tool. Some tools make you more productive after you have learned how to use them.
I find it interesting how in software, I repeatedly hear people saying "I should not have to learn, it should all be intuitive". In every other field, it is a given that experts are experts because they learned first.
> I find it interesting how in software, I repeatedly hear people saying "I should not have to learn, it should all be intuitive". In every other field, it is a given that experts are experts because they learned first.
Other fields don't have the same ability to produce unlimited incidental complexity, and therefore not the same need to rein it in. But I don't think there's any field which (as a whole) doesn't value simplicity.
I feel like it's missing my point. Using a chainsaw is harder than using a manual saw, but if you need to cut many trees it's a lot more efficient to first learn how to use the chainsaw.
Now if you take the chainsaw without spending a second thinking about learning to use it, and start using it like a manual saw... no doubt you will find it worse, but that's the wrong way to approach a chainsaw.
And I am not saying that async is "strictly better" than all the alternatives (in many situations the chainsaw is inferior to alternatives). I am saying that it is a tool. In some situations, I find it easier to express what I want with async. In others, I find alternatives better. At the end of the day, I am the professional choosing which tool I use for the job.
Right but how do you expose your state machine and epoll logic to callers? As a blocking function? As a function that accepts continuations and runs on its own thread? Or with no interface such that anyone who wants to interoperate with you has to modify your state machine?
I find state machines plus some form of message passing more intuitive than callbacks or any abstraction that is based on callbacks. Maybe I'm just weird.
When I did not know how to program, neither async nor message passing were intuitive. I had to learn, and now those are tools I can use when they make sense.
I never thought "programming languages are a failure, because they are not intuitive to people who don't know how to program".
My point being that I don't judge a tool by how intuitive it is to use when I don't know how to use it. I judge a tool by how useful it is when I know how to use it.
Obviously factoring in the time it took to learn it (if it takes 10 years to master a hammer, probably it's not a good hammer), but if you're fine with programming, state machines and message passing, I doubt that it will take you weeks to understand how async works. Took me less than a few hours to start using them productively.
Not true. I’ve used both, and I often prefer the explicitness of async await. It’s easier to reason about. The language guarantees that functions which aren’t async can’t be preempted - and that makes a lot of code much easier to write because you don’t need mutexes, atonics and semaphores everywhere. And that in turn often dramatically improves performance.
At least in JS. I don’t find async in rust anywhere near as nice to use. But that’s a separate conversation.
It forces programmers to learn completely different ways of doing things, makes the code harder to understand and reason about, purely in order to get better performance.
Which is exactly the wrong thing for language designers to do. Their goal should be to find better ways to get those performance gains.
> It forces programmers to learn completely different ways of doing things, makes the code harder to understand and reason about, purely in order to get better performance.
Technically, promises/futures already did that in all of the mentioned languages. Async/await helped make it more user friendly, but the complexity was already there long before async/await arrived
If I want sequential execution, I just call functions like in the synchronous case and append .await.
If I want parallel and/or concurrent execution, I spawn futures instead of threads and .await them.
If I want to use locks across await points, I use async locks, anything else?
Really? async/await is the model that makes it really easy to ignore all the subtleties of asynchronous code and just go with it. You just need to trial and error where/when to put async/await keywords. It's not hard to learn. Just effort. If something goes wrong, then "that's just how things go these days".
SKIP LOCKED isn't quite enough to get a real MQ product. Oracle has a full blown MQ product inside it transactional with other data.
In particular you need the ability to wait for messages to appear in a queue without polling, and for a proper MQ you need things like message priority, exception queues, multi-queue listening, good scalability etc.
Countries like Japan seem to make policy that serves the people.
Other countries decisions serve politicians, corporates, the rich, and maybe possibly finally, the citizens.
Here in Melbourne a city of 5 million people we don’t have a train from the airport to the city despite decades of political talk about it. But why not? Because the Airport Coporation makes vast unfathomable profit on car parking. What’s most important? Just look around.
Works in progress also had a great article recently (also discussed on hacker news) about how Japanese railways are private, profit earning real estate development corporations. [1]
Unfortunately, people from western countries have very negative views toward the privatization of mass transit despite the wild success that Japan has experienced. The model makes so much sense: if trains are just a way to get people to the real estate that you developed, then you’re going to make sure that the trains AND the destinations are really nice, which also turns out to be very lucrative (at least in densely populated areas) as a cherry on top.
And even worse, like this commenter above alludes to, it is trendy in the West to believe that real estate developers are evil, and that corporations that make money are sucking the life out of society. This kind of degrowth populism pretty much guarantees that the successful Japanese model is out of reach for most countries, because it is exactly the pursuit of profit that makes Japan’s system so nice - not some edicts from a benevolent and extremely capable government.
> Unfortunately, people from western countries have very negative views toward the privatization of mass transit despite the wild success that Japan has experienced
Japanese culture would frown heavily on enshittifying the transit experience to earn more profit. Western culture mass transit is already often shitty, and I cannot imagine how shit it would become if a for profit corporation took it over and started to squeeze it to make more money
Did you read what I said? The whole Japanese system is for profit and the one of the biggest reasons for Japan’s system being so pleasant is that it is done for commercial purposes.
If the incentives are right American companies can make good things, but usually they are not so because of poor policy.
> If the incentives are right American companies can make good things, but usually they are not so because of poor policy
I disagree. The incentives are never right for American companies because the only incentive they care about is making money at all costs. They don't even care about their reputations anymore if they can sell their rep for money
like many other places, there is a airport bus in Melbourne as I recall. there is (or was) a train from Melbourne to Canberra too (with a short bus transfer on the Canberra side). it was very difficult to figure out how to buy a ticket for it!
There’s plenty of people in this world who are expert programmers without following any traditional path.
“Oh yeah, like who”, you say.
Con Kolivas, anaesthetist, work on kernel schedulers including the Staircase Deadline (RSDL) scheduler which was a precursor to the Completely Fair Scheduler in Linux and the Brain Fuck Scheduler and the ck Patchset.
reply