BiteCode_dev

I will include a section about the things that it was not good for and the problems with it. Spoiler, there were not that many and they fixed them astonishingly well (even one this week!). But obviously there were some, no software is perfect although they worked hard to not make it too opinionated for the first taste.

I can ping you when it comes out.

Would love to hear what gotchas to find so I can add that to the list.

Nailed it.

What's the big deal ?

But practically, the difference is intention, which drives design and ecosystem.

E.g: starlark is very oriented toward idempotence and limiting side effects to get reproducible config data. By default they discourage reading files: https://github.com/bazelbuild/bazel/issues/13300

But rhai is not particularly oriented toward config, and the doc promotes an extension to read files: https://rhai.rs/book/lib/rhai-fs.html

The tutorials, stdlib, language design anf tooling will all reflect this.

You probably don't want to use starlark to automate much action, but it will be well suited to describe states.

But this is a fireable offense in my book.

It has a super limited compiled extensions ecosystem, plugin ecosystem and is not used as a system language in mac and linux.

And of course node is much more recent and the community less diverse.

tldr: node is playing in easy mode.

It's foss, and ypu can point it to any otel compat enpoint. Plus the client that the pydantic team made is 10 times better and simpler than the official otel lib.

Samuel Colvin has a cool intervew where he explains how he got there: https://www.bitecode.dev/p/samuel-colvin-on-logfire-mixing-p...

The card effects are interesting, the illustrations illarious and the interractions a lot of fun.

The twist of the game, the mindbug itself, is a blast of bluffing and gambling that garanties some smiles.

Limited to 2 players but a great small box to have on all occasion of you are into that kind of stuff.

The rules are simple so ir's easy to get in.

It's a great reality check, poking into human nature, morality, suffering, all with real life examples and littlz tolerance for bullshit without delusion of grandeur.

Quarto is more for publications.

Until it's good enough it can release it an nobody is the wiser.

But again, it's a LOT of work to do that.

E.G:

To write "https://www.bitecode.dev/p/back-to-basics-with-pip-and-venv", I need to be able to rely on "https://www.bitecode.dev/p/installing-python-the-bare-minimu..." which in turn needs to rely on "https://www.bitecode.dev/p/ultra-beginners-first-steps-for-t...".

That's almost 9000 words, or 10% of the average novel size just to give beginners a good chance of success on one single topic.

Between doc, tutorials, FOSS and forums, the entire software industry is just standing on a gigantic pile of billions of hours of free labor.

I'll nitpick a bit.

You can't tell your user to "echo 'awesomecopter' | sudo tee /etc/hostname" if you may have windows users.

And even for purely linux user, "Good: Give the reader a bash snippet that evaluates conditional logic for them" is quite a scary wall of code for a beginner that as no idea why copy/paste that.

All in all, don't confuse "giving the shortest path to a working solution" and "teaching", which both can be in a tutorial, but they have different goals and you should choose accordingly.

I think the "Teach one thing" is probably the best advice in the article, and too often ignored. I remember as a kid reading Swinnen's book to learn Python and having to understand OOP with his example using ions was a terrible experience.

And if you think "well you should have known that, they teach it in school", you are missing the point.

That being said, writing an excellent tutorial takes a lot of work. Way more than a good-enough one. Choose wisely.

Non programmers using notebooks are usually the least qualified to make them reproducible, so better just ship the whole thing.