Then again, just because business controls politics doesn't mean there's much more decentralization or openness, either. In the end, the main advantage of this model was predictability - sure, we have an "inner circle" that forces its policies in both cases, but the businesses are at least predictable in their decision making, always chasing profit, based on hard numbers, unlike the other side chasing whatever flavor of ideology they believe in (or want to sell) this month... Wait. I just recalled "colonies on Mars" and "metaverse," and the cognitive dissonance made me blank out for a sec here.

In any case: while the Chinese model seems to have some upsides, especially compared to the current situation in a few other places on the globe, I don't believe it has a significantly higher chance of helping us achieve a "brighter future". I may be depressed, but in virtually every scenario from this point, I can only see a bleak future ahead of us. Getting to AGI under current conditions makes for completely unpredictable societal and political chaos, yet not getting there (and fast) risks the bubble bursting (causing, of course, unpredictable economic and, by extension, societal and political chaos). The longer the current situation persists, the lower the probability of finding an off-ramp that won't upend everybody's and their dog's lives. Yet, there is no incentive to back off from the race either.

I really wonder what's next - what kind of poop will finally hit the fan, and when exactly?

Coming from a kendo background, when I had to chop firewood for a few years while living in the countryside, I generally focused on accuracy. The swing is completely different than with a sword, and getting the chop to land at the exact spot (I drew lines with a marker) tens of times in a row was very satisfying, but required a lot of conscious effort to get there. It's not trivial to land a chop at the exact spot you want, and it's also quite hard to ensure the axe travels at its fastest exactly at the moment of impact.

It can be fun, but you need to be into things like that in the first place; plus, having to do it no matter the weather and all the other things you need to do can kill all the joy instantly.

It's neither of those unless you limit yourself to a lowest-common-denominator feature set. GNU Make, for example, is a Turing-complete, dynamic programming language and a CLI task runner. You can build a build system in GNU Make (https://github.com/omercsp/simple-build-system) just like you can do so in any other language.

Make suffers from unfamiliar and somewhat unorthodox syntax, and inconsistent language design. So it's not a good language, and saying it "sucks" is not completely unjustified, but not because it's limited. Looking at SBS, it also seems quite expressive, although I can't say I ever tried building something in it myself.

It's still worth noting the relative probability: death or life-changing injury is basically what happens in every single accident when you're going 200km/h on a highway surrounded by (what could as well be) steel walls moving at the same speed; in my use case, when not exceeding 40-50 km/h and using roads where other users basically stand still most of the time, you need a pretty specific conditions and a lot of bad luck to even have an accident, much less die or become permanently disabled as a result of one. Still, not a zero probability, but the difference between 100% and 0.01% is kind of noticeable.

That's how I use the current AI, too. I never ask them to do something without specifying how it should be done. I ask questions first, use /plan to let the model ask me questions, then I let it execute the plan while reviewing the results. More and more often, I get something close enough to what I would have written. In the opposite case, I at least know exactly how to rewrite the result, if needed.

I observe the same effect as you: while it does sometimes speed up the implementation a bit, it's not very noticeable; however, it frees me from having to recall all the obscure little details up front. Instead, I can describe them, have the model implement them, and then recognize them (and refresh my memory) when reviewing. The effect is that it's easier to start a task because I don't need to prepare as much to execute it. It's especially notable on things that I haven't touched for some time. I know, more or less, how my Elixir projects are set up, but after ~2 years of not working on them, getting back into them had been a hassle - with AI, it's no longer that. I think the biggest difference comes from the AI lowering the cost of context switching for me - I used to have huge problems with that, and AI certainly helped a lot.

Further, the very operation of this code requires the user to modify it, as described in the usage instructions. You might say that this only gives permission to modify a particular subset of the provided code, to which I don't have an answer (other than that it's unspecified).

You might not be able to fork it and distribute your modified version to others. It's not free/libre. But you can read it and modify it for your own use. To me, that's plenty enough for a project like this. As far as proprietary code goes, this is as harmless as it can get - instead of criticizing it for not being open enough, it would be better to praise it for being this open, to encourage other authors (who would otherwise keep all the code as closed as possible) to follow this model instead.

Yes, FLOSS is good and great, but it's impossible to make all code like that; in reality, where we deal with DRM, app stores, and heaps of unrepairable, uninspectable, obfuscated, phone-home activated code all around, even a bit more openness helps.

I'm sorry, but from a European perspective, this is the problem, not bikes. If your roads and driving culture encourage driving a tank for safety, that's a bit less than ideal.

I commuted to work for 5 years on a moped. I never used a highway, almost never exceeded 50km/h, and had 2 accidents during that time; both resulted in just a few scratches and bruises.

In another post, you said: "maybe speed was a factor" - actually, it's the only factor. If you never go too fast and never use roads where others may go too fast, you're safe - at least from life-altering tragedies.

If, on the other hand, it's generally impossible to get where you want to without using highways, or the sheer distance forces you to step on it - then yeah, don't buy a motorbike. Just note that it's not the bike's fault!

I had two accidents during my 5 years of commuting, and both times I only got minor scratches and had to replace my shoes. Both happened at speeds a determined bicycle rider could achieve, but I suspect I wouldn't be as well protected on a bicycle (both the machine itself and the protective gear tend to be much lighter there than on a moped). If I needed to do that again, I'd buy a model with two wheels at the front, which would have prevented both accidents - though I'm not sure if added stability wouldn't encourage me to ride faster.

So it's pretty specific, but if you're somewhere where driving culture is not too cutthroat, the roads can support single-track vehicles, and the traffic rather than actual distance is the limiting factor - owning a bike can be an objectively better option.

That's a bit of a misrepresentation. Error handling on the BEAM has a few more layers than in other environments; specifically, the supervision tree can be used to "let things fail". That's not the layer where you should log or handle failures - that's a safety net that ensures your whole system won't go down if your error handling in a single process doesn't work.

For error handling, there are roughly these layers:

    - functions can return {:ok, value} or {:error, error}
    - functions can raise errors (similar to exceptions) that can be caught
    - processes can be monitored from the outside, you get notified when they die
    - processes can be linked and exits can be trapped, also notifying you on failure
    - supervisors can handle process deaths in a configurable manner
    - higher-level behaviours often expose their own error handling callbacks

OMG, why? Why would you ever have so many processes? All of them at the same time? Are you going to animate a 3D scene and run a process for each vertex, or something?

No, I mean, if you're WhatsApp - across all nodes - then somehow maybe yes? At scale. But in normal code, slicing workloads too thinly is counterproductive, and having even tens of thousands of processes is a sign that you're slicing it way too thin. Message passing between processes is cheap, but not free. Schedulers do a good job, but rarely have more than 16 cores to work with. And so on.

You can have that many processes if you want, to be sure. But if you're struggling with it, why would you want it?

Reading your comments in this thread, I have a feeling you just didn't spend enough time reflecting on how you want to use Elixir. In effect, you also failed to consider how exactly you should learn it. For example: Elixir is a perfectly capable procedural language. Start by writing CLI tools, without spawning any processes at all. Then try to parallelize their processing. If the tool accepts a list of files as arguments, use a `Task` to compute return values for each file. Tasks are processes, but with a particular contract that simplifies their usage. Later, you can experiment with error handling and supervision by putting the tasks under a supervisor. And so on. You go from the familiar to the less familiar, with a useful, working tool every step of the way.

Every new paradigm is confusing if you don't put in the work to learn it. That's just how the mind works.

What's important is what you get after you don't give up on it long enough. And that, on BEAM, is a hilariously OP superpower of effortlessly[1] parallelizing and distributing workflows. Then there are Elixir macros and the OTP supervision model. The addition of gradual typing is huge, and when the annotation syntax lands, I will definitely switch to Elixir for everything on the backend.

In any case, the only thing I can tell you is that learning Elixir is worth enduring the confusion. From personal experience, it's just a matter of learning it bit by bit over time - there's a finite set of "confusing" ideas in the OTP/Elixir/BEAM mix, and learning about some of them every other day works wonders over a few months.

[1] An exaggeration - I know! But it does make it much easier to implement parallel and distributed workflows. Recently, most of the important languages finally started getting their m-n concurrency models (from Java to Python), so the BEAM is not as much ahead on SMP, but for distribution (you can send closures to execute on different machines transparently!) it is still in a league of its own.

The it's-not-X-it's-Y formula is the most visible tell. It's overused, being used, I think, 3 times, with 2 being slightly less obvious. This-was-X-and-now-it's-Y is also overrepresented.

It's still not a bad comment. We can discuss it just fine. What we can't do now is assume this is entirely an EastLondonCoder's text, so we can't use it to form an opinion of that person (whether good or bad) based on its content (since we don't know how much of it comes from that person, and how much from the machine). Some will also form an opinion (good or bad) about the poster simply because they used AI.

That's an Internet discourse of 2026, in my experience. I wonder what's next.

I hear you. I collect knives as a hobby, and always have some kind of a cutting tool on me - they solve a surprising amount of little day-to-day problems (unpacking things bought in a shop being a prime example). I lost one of my folders to the UK border guard because, while a 6.5 cm blade was OK, they said its locking mechanism is illegal in the country. What's particularly funny is that I was actually trying to get back to France then - when entering, nobody asked about any knives. I never got that one back. :(

I wish I knew what the people who wrote this law thought. A folder without a locking mechanism is just as dangerous to others in violent scenarios, but way more dangerous for the user in typical EDC tasks. In Poland, there is no limit on the length of the blade nor on the locking mechanism. Technically, carrying an automatic foldable scythe or a zweihander is legal; you can't, however, carry a sword-cane or any other blade that is disguised as another item, like an umbrella. To put that all in perspective: in both countries, just like almost everywhere else in the developed world, the most lethal type of knife is the good old kitchen knife - ubiquitous, solid, with a tip ideal for thrusts, with a handle that protects the user's hand during the thrust, and so on. Such knives are generally not within the scope of knife-related laws.

So yeah, I don't get the logic behind the knife regulations at all. I'm not sure if completely dropping all of them is the way to go, but they would definitely benefit from a rational reevaluation. As an example, making the locking mechanism mandatory, instead of banned, would have no impact on knife-related deaths while allowing quite a few people each year to actually still have all their fingers.

I'm afraid a similar thing will happen with LLMs and later AIs. Regulators will "compromise" and focus on some kind of danger that's not entirely impossible, but also not very probable (assassins with blades in umbrellas...?), will fight for months over semantics, then pass the regulations to absolutely no visible effect - and the really dangerous uses will become either normalized or at least will move to the gray zone. The judiciary will try its best to apply existing laws to new situations, and in some cases, that will inevitably fail. We'll all deal with the consequences of these failures, unfortunately.

Don't blame the poor guy who was subjected to this. You're projecting your understanding of what is normal for the interviewer and assuming that the particular interviewer didn't cross any of the lines you wouldn't. Unless you are the interviewer or know their side of the story, there is literally nothing in the post that would suggest your reading is correct.

A simpler explanation: the interviewer was an amateur psychologist with little experience in either interviewing or therapy. They asked "interesting questions," then were overwhelmed by answers they hadn't expected and couldn't gracefully handle. That's it. Please, unless you know more about that particular instance, don't reflexively blame the candidate for what looks like a series of errors on the interviewer's part.

Lambda calculus, primitive recursion, Brainf*ck (Turing machine) are all models that discard all of the accidental complexity - all of it: syntax, higher-level constructs, abstractions, etc. What's left is the bare computation itself, amenable to analysis.

It's not meant to be practical - it's a research vehicle that shows what's possible and what's not possible in the realm of ideas, without looking at any real-world constraints (you would, in practice, want to see the result of your computation in less than 100 years - that's not the consideration when using one of the models).

So yeah, it's not something you use, it's something you learn to arm your brain with tools that will help you debug and write complex code that works. It's really worth spending a year or two deep-diving into these "pure theory CS" things; considering that you're going to be writing code for 20+ years (AI allowing), spending 10% of that time learning the foundations on which everything else rests is not that big of a task.