Maurício Szabo

Bun is released – let’s jump the hype (NO)!

Bun 1.0 was released. And again, the JS ecosystem did what they do best – fell up into hype.

I actually have no idea why this happens so much in JS world; maybe it’s a lack of maturity (I mean, Ruby also did the same in the past, then they figured out it’s not always a good idea to throw away everything when a new stuff appears), maybe it’s something else; maybe people are just desperate to have something better in the JS world – who knows?

Anyway, I decided to do some benchmark tests. I was already not impressed, because I did test Bun in the past, but let’s see what happens with this new version:
(more…)

By Maurício Szabo, ago

They locked us outside of freedom

Recently, I saw myself forced to use a Mac. And then, finally things became clear: why I don’t like macs, and why people do like it, and why Linux is not popular.

It is quite simple, honestly – closed-source software works incredibly well with other closed-source software, and incredibly bad with any open standard.

It’s the equivalent of creating a comfortable city, with filtered air and water, but that somehow makes you allergic to natural air and water. And then, they convince you that natural air is bad for you.

So, let’s dive a little on my experience with Mac – remember, I use Linux most of the time, my wife also uses Linux (by choice, by the way, although basically nobody believe me when I say that, and no, she’s not a developer or a technical person in any way), so my whole life is somehow based on open standards. So, the first thing I tried on my Mac was to start some open standard services – OpenSSH, VNC, for remote access…
(more…)

By Maurício Szabo, ago

CommonJS is not a problem – the Javascript ecosystem is

Recently I came across this post saying that CommonJS is hurting the JavaScript world. And while I do agree that the CommonJS specification was not a good one, I also disagree a lot with the article. As someone who have strong opinions about the subject, I decided to write a post about it.

So, here’s the problem: supposing that you have a legacy system that’s years old, and that basically is modular, meaning that people write extensions, or libraries, to that. Like for example, NodeJS’ CommonJS. Now, here’s the problem: if that legacy system is flawed, and you need to change somehow, and your solution is “let’s do something that is better in any way than the older model, it’s faster, etc, but also completely incompatible with the old stuff” – meaning that we have to rewrite everything to be able to be used on this new format – then you’re doing it wrong.
(more…)

By Maurício Szabo, ago

Pulsar have a green CI, finally!

After so many months, finally we have a green CI – we can consider pull requests and changes that break the CI as “unstable”. This is a huge milestone, and I want to both thank everybody that tracked these failures to check if they were legit, to the people that fixed the legit failures and that fixed the flaky tests. This has been an amazing experience, and it helps build trust on the project!

If you look at the commits from the Atom project and check which ones have passing tests, you’ll see a horrible situation: they mostly don’t pass. There’s even a recent commit called “disable tests” that passes, and then the next commits also fail – so Atom was already failing tests when these were disabled (how is that possible, I won’t dare to think).

So it’s a huge milestone to have a CI that confidently (or at least we hope!) say if we broke something new! But on this post, I want to show not only how cool is that, but also the process and how to avoid flaky tests on the near future – both for Pulsar and for other projects
(more…)

By Maurício Szabo, ago

The empire built over beach sand

Completely inspired on this post: https://archiloque.net/blog/a-machine-for-gods-jam/, and my experiences with Pulsar.

The Node.JS Ecosystem, together with so many others, is broken. Maybe beyond repair.

Let’s review the foundations of good software: good code, automated tests, a server that checks if the software works (usually called CI Server), a server that publishes the software continuously as soon as everything is working (usually called a CD Server), and reproducibility – meaning, if something fails, it needs to always fail if we send the same parameters, and always fail in the same place in the same way; if it passes, it must always pass on the same condition.

Now, onto Pulsar
(more…)

By Maurício Szabo, ago

Git is a distributed version control system – let’s use it as such

Here, I’m going to talk about git. Simply git. That’s all.

Git is a version control. It means that, for text files, it’ll store differences between a version and another.
Git is distributed. Meaning that multiple people can work on the same file and sometimes even on the same feature and one will not step on each others’ toes.
Git is semi-immutable. A commit is a fixed, immutable point in time containing the difference between the last version and the new version.

Now, let’s talk about what git is not
(more…)

By Maurício Szabo, ago

HackerNews, Pulsar, and my answer

First things first: I refuse to create an account on HackerNews. It’s honestly one of the most toxic programming communities that I know of. One thing that always come to my mind when somebody links me an article on HackerNews is the phrase:

The person who says it can’t be done should stop bothering the one doing it

Seems that this first phrase was written, without attribution on the “Puck” magazine under a slight different wording and meaning, but I honestly prefer this newer version. Anyway, back to HackerNews, somebody posted about Pulsar on it. And, as always, the comments are mostly negative. This basically triggered me a lot more than I would like, so instead of creating an account and giving them more visibility, I prefer to address these issues on my blog – so I don’t risk being triggered even more when some stupid keyboard warrior writes nonsense on why our work is useless (I told you I got triggered by the comments!).

So, to answer many of the stupid remarks on the site:
(more…)

By Maurício Szabo, ago

Dyson Sphere Around a Pulsar

Well this year has been rough for Chlorine.

Basically, I wanted to keep Chlorine plugin working, but Atom was degrading over time. So, I decided to… make a new editor from the ashes of Atom! Or, basically, reuse the plugins that already had the visual elements, for example, and creates a new thing.

That obviously didn’t go right. The reason is quite simple – in the beginning, the idea was to reuse the fragments and plugins of the Atom, even if I had to depend on internal state because, sure, Atom was stale but at least it was receiving updates and security bumps over time, even when their Electron version was really far from the latest stable.

But then Atom died and I had to make a choice. Either I would keep developing Saturn and give up Atom completely (that was one of my ideas), or I could try to keep a version of Atom that did not have the backend functionality; another option was to change editors, for example, to a NeoVim version that had a webview, and focus on developing Clematis. None of these were ideal, especially because the only NeoVim editor that have a programmable webview is NyaoVim, and that is also dead.
(more…)

By Maurício Szabo, ago

Atom, community, and Pulsar

Okay, so recently I wrote about the Atom editor and how the community took efforts to revive the editor after the sunset announcement from Microsoft.

By now, things have changed a little bit. There was some disagreement on how the project should be handled from the atom-community maintainers: few people that were on the leadership decided that we should make “graceful changes” – things that do not disrupt too much the editor, small PRs that can be reviewed, and lots of stability. And I actually agree – that’s the way a project should be handled!

Except there’s a big catch: for me, this only works when the project is alive. The Atom editor is dead, for better or for worse. It’s announced already, so there’s no way “graceful changes” will be able to keep the editor alive or even relevant than, for example, VSCode – even for people that want a lightweight alternative or have want a different approach on handling code.

There were other disagreements on the roadmap – for some people, they wanted Atom to have the same functionality that it have today. And, speaking for me, I don’t agree – I think there are functionalities on the the Atom editor that are simply too much: for example, native support for CoffeeScript and TypeScript. I firmly believe that all Atom/Pulsar plug-ins should be transpiled – and that’s not only because the editor should only run JavaScript, it because it’s more reliable that way (the native support can fail between different tooling, language versions, etc. As an example, Atom supports plug-ins written in CoffeeScript 1.12 – and the current version is 2.7.0). Also, if a plug-in is bundled in a single JavaScript file, it’s actually more efficient both in terms of memory and performance for the editor.
(more…)

By Maurício Szabo, ago