sifoobar

I started working professionally in Delphi around 1998, and then spent 13 years evolving and maintaining a sprawling 2+ mloc reservation system.

They had a great thing going around that time, but then the pivoting and squeezing started. Instead of evolution we got enterprices, buzzwords and bit rot. By Delphi7, I'd say it was already as good as dead.

All owners so far share an unfortunate tendency to oversell half-baked solutions with no future, all the way up until the point where they pivot and push a brand new successor with no future while deprecating the previous attempt asap.

Their database, Interbase; was open source for about a month. Until the suits realized that no one would buy their shiny enterprice crap if they could simply download it for free, and it was closed again asap. Only now all the people who knew anything had joined effort in a fork called FirebirdSQL.

It was even released for Linux under the name Kylix, free for non-commercial use if I remember correctly. Until Microsoft bullied them into dropping the cross-platform game right now in return for cozy time with the centerfold creep and his side kick sweaty monkey. I just threw up a little in my mouth writing that so I'll stop here.

Told them to start acting human or sod off? I can wish, can't I?

Trying harder is never the answer to anything. People already are doing their best, whatever that means in a specific context. And however far from whatever expectations.

Pushing harder might very well lower productivity overall, since everyone now likes working there even less than before. And it's very difficult to regain trust and loyalty.

No one wants to hear that there are no short cuts, especially in today's messed up world where everything is fake and for sale.

But THERE ARE NO SHORT CUTS.

Regardless of language.

You'll have different kinds of bugs, but as long as there are programs they will contain bugs. Or the languages themselves will, or the libraries used, or the OS.

Assuming the presence of bugs/failures and providing powerful tools to deal with them like Erlang is a more realistic option if you ask me.

What is it with these people and controlling the choices of other, quite possibly more experienced, programmers?

Why is it not enough to offer better tools and let the rest take care of itself? Or to solve problems using a tool that fits your way of thinking? Why do you need a cult/marketing effort if the language is as good as it claims to be?

The more of this bullshit I'm confronted with, the less inclined I am to ever let Rust slip into a project I'm involved in.

I would be careful with projecting that experience, everything is not about signaling; sooner or later mostly everyone will come to the conclusion that pretending isn't leading anywhere. Because it isn't.

Not depending on Instagram's algorithms and the opinions of its marketing department and your followers is _better_, for everyone. Dependency in general is rarely a good thing.

Judging is a different issue. But not giving a shit about what other people think usually goes hand in hand with not giving a shit about what they do either.

Funny story: I had just started working at a SV-based startup with mandatory surfing lessons and a fivefinger-wearing transhumanist CEO when Silicon Valley started.

Watching it was very painful, to say the least. Having to go through it is one thing, having your nose rubbed in it another.

I've used Reddit since day 1.

The new website is a usability disaster, and one that they don't mind shoving down your throat at every turn.

Moderators are increasingly beating anyone who isn't politically correct enough over the head with their moronic code of conduct and banning users for simply disagreeing.

Most of the people who still hang around are very negative individuals who seem to be there more to project their hatred in general than to learn and/or share. Oppose their abuse and they'll invariable mob up on you and make sure your posts never see the light of day.

If I was Aaron Swartz, bless him; I would be turning in my grave by now.

They're also supposed to serve the people; and when they don't, it's the people's responsibility to remove them from power.

Which is just about where we are right now in many countries, at the point where that coin drops collectively.

It's one of those languages that does things differently to solve actual issues, not to check boxes.

From my limited experience, Erlang doesn't share data between processes; you throw it over the fence by sending to the process inbox, which is where the locking takes place.

Still, shuffling data between OS threads is an easier problem to solve than serializing between OS processes.

Processes by name, from Erlang.

They're implemented (in my mind so far) as preemptive threads, one per interpreter; which makes them slightly more heavy-weight than Erlang's NxM and a nice complement to purely cooperative multitasking.

I am aware, it's simply the most portable universal solution to the problem that I could think of. AIO comes with its own share of issues; Unix (and thus Posix) are pretty much dead; and it's not universal, I can't use it to open a database connection unless the database has support built-in.

From what I know, cooperative multitasking suffers significantly less from unpredictable performance than preemptive threading. The biggest source of uncertainty in Snigl is the preemptive IO loop.

The things is that I really don't feel like writing a concurrent runtime; been there, done that. I'm planning something along the lines of Erlang's processes and channels based on separate interpreters for those scenarios.