He's the guy from FOOF[1]! I didn't immediately make the connection, thanks. Yeah, that series was kind of fun, even if it kind of reinforced my layman understanding that all chemists are explosion nerds :D

[1] https://www.science.org/content/blog-post/things-i-won-t-wor...

Well, it's the kind of "meditative" you get when training martial arts forms. It gets good after a few years of preparation; before that, it's not as fun as spars and way less useful than general conditioning.

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.

> Because it's really limited and not expressive?

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.

The OCaml ecosystem tried the Make route, it was complex, turns out no one likes maintaining makefiles by hand, and they like opaque make rules even less. Like it or not, dune exists for a very good reason.

Make works fine with OCaml. There's a handful of rules you copy and paste around which is not ideal, but that's much easier to deal with than dune.

Can you link a Makefile for an OCaml project, which ensures reproducibility and locality? What I mean is checking checksums of dependencies upon when they are installed, and acting only in the project directory, not changing the surrounding system in order to run the program. Asking, because I tried and failed.

ocamldep will set up the dependencies correctly. For examples, have a look at the multiple Makefile.am files in libguestfs, guestfs-tools & virt-v2v projects. All run as non-root so they don't change anything about "the system" assuming that's what you meant. (On mobile at the moment so can't link easily.)

You mean this one: https://github.com/libguestfs/libguestfs/blob/master/Makefil... ?

I don't see how ocamldep is used in there. It seems to use multiple different programming languages somehow. I don't find it easy to understand what it does. It seems to be building a website as well.

I'd rather not have to maintain lists of source files to compile by hand; dune eliminates this drudge work.

> Make suffers from unfamiliar and somewhat unorthodox syntax, and inconsistent language design

You just answered the question "why does every language need to re invent packaging, building, etc." Because people don't want to build build systems in Make

In Make you can’t even have recipe-local variables with scope spanning more than a single shell command. At that point I prefer to write a Bash script where at least variables work.

> Maybe I don't remember how to stitch something together, but i know it can be done.

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.

> Some US highways

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 lack the commenting impulse control to say this in a politically correct way so my apologies for the outrage that will follow, but to put it crudely there is someone in my extended family who became a retard after falling off their bicycle at roughly walking speed and with a helmet on. It's rare but you can easily die just from walking and slipping on a banana peel.

While you're right about slower generally being safer, you should still treat it like a life-altering tragedy could happen at any time and like you're going 200 kph.

I'm sorry for your relative, and of course you should always do things like driving (diving, cycling, sailing, climbing - or even cooking and cleaning) as if a tiny mistake could cost you everything: that's because it's actually true. These activities will never be risk-free; the best you can do is bring the risk down to a level comparable to that of alternatives (with "just don't do it" included in the set) and hope no unfortunate incidents occur to you.

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.

Probably depends on the locale. In Europe, riding a moped in a big city is a way to drastically cut your commute compared to driving a car. It's not exactly dangerous when all the other road users are moving at 5m/min, and being able to just skip all the traffic jams is a godsend. By car, my trip to the office was about 45min - it was 15min on a moped, a stop at a shop for some snacks included. And that's with riding speed never exceeding 50km/h.

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.

oh interesting, I should have realized it was fairly common in Europe

In Europe many people have both, and use the motorcycle to go to work/etc because it's faster and more convenient, especially in a larger city with traffic jams.

I am going to get to work with my classic Vespa scooter. Its cheaper than a car and i live only 7 kms away from my workplace. Riding bus and tram is time consuming and expensive. Its fun to ride a classic scooter and it never failed so far because i use it everyday. My classic runs up to 70km/h and people think its a slow, modern scooter so they dont really pay attention to me.

>Riding bus is time consuming and expensive.

I've always thought it made more sense that instead of large metrobuses the local transit authority operate more like a locals-only taxiservice – similar to their already-existant handicapped-access services (which send a solitary transport driver, with ramped single-occupant van/vehicle).

I'm not going to blame you _too_ much, since I had similar suspicion, but you could have (as I did) just downloaded the .zip file and examined the contents. In the shareware version, some things are probably missing (I think not all themes are there), but otherwise it's just a bunch of PHP files, no obfuscation or anything. The markup language is configured in a text file, and the parser for that file is just next to it. The configuration is used for configuring the markup parser, which is also present. And so on. It's not open-source only if your definition of OSS is "has to have a Github page".

Just because you can see the source code does not make it open source. Shareware software is proprietary software.

Open source means free software, which is a license that allows unrestricted use of the source code. Shareware isn’t free (as in speech OR as in beer) software.

The definition of OSS is well defined, and isn’t my definition. This is why there is a term called “OSI-approved license”.

It's not open source but you can repair it yourself. So it does walk the walk.

No. Shareware does not provide you with a license that allows modification.

Ok, but given that there are no license terms anywhere (not in the .zip with the code, and I don't think there is one on the web page), you also can't say that this particular license disallows modification. The terms are simply not specified.

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.

A lack of a license also does not grant you permission to modify it.

Source available software is not open source, and attempts to redefine it as such are ridiculous. This apologism for proprietary software (hypocritical proprietary software, at that) doesn’t benefit anyone.

> Elixir is having to handle (possibly) hundreds of thousands of processes

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.

> No, I mean, if you're WhatsApp - across all nodes - then somehow maybe yes?

I mean, we had one process per client connection (which is 100% the way to go) and depending on the era, hundreds of thousands or millions of connections per chat node. I don't think we ever really summed the number of processes over a cluster.

Other than client processes, there weren't that many processes per node; like you say, it doesn't make sense to spread too thin.

There's a lot of client connections and so a lot of client processes, but it ends up being pretty simple to work with them. They all do the same thing... wait for a message, process the message, wait some more. Some of the messages are tricky to process (like the user just logged in again over here, so please transfer the state)

I learned it for almost a full year by trying to build a live chat app. I went through Elixir in Action and the official guides and yet those questions were never really answered. I never said I want hundreds of thousands of processes, but thats definitely a thing you need to account for. Errors are often simply swallowed.

> Errors are often simply swallowed.

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

So there's a bit more to error handling on the BEAM, and I get that becoming familiar with all of them and using them properly can be a challenge. The defaults skew towards high-availability, which is not always what you want in development - sometimes, failing fast and completely (up to stopping the app or the BEAM as a whole) is more convenient. You can have that; you just need to ask for it specifically in your code.

> Errors are often simply swallowed.

That's a choice, but it's not idiomatic.

You're expected to write things like...

    ok = thing_that_might_not_work().

(Well, that's what it looks like in Erlang anyway). If there's an error, it doesn't match, so it crashes. You don't have to check for success, but it's easy to, and 'let it crash' is the mantra, so yeah. Then you watch for crashes, and fix them with hot loading, and pretty soon you have a reliable system.

Let it crash ends up not quite working, so you end up catching a lot of errors, but you should be logging them, not swallowing them...

> It's so confusing to build for the BEAM that I ultimately gave up on it.

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.