Atom is dead now. Starting today, Atom is dead. Probably the editor that had most personality ever – I mean, look at the 1.0 announcement!. But with all things Microsoft does, one thing they know how to do REALLY well is – marketing. Microsoft was able to convince the world Read more…
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…)
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…)
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…)
Few times I feel inclined to answer for a post. There are actually lots of posts that say that Clojure needs “the web framework” like Rails or Django or Phoenix so it’ll be better. Sometimes these ideas have value, sometimes don’t, and sometimes they are simply nonsense at all.
I recently was shown a post that was basically nonsense, and to keep things neutral, I’m not going to link it here. I want to expose why I think these ideas are nonsense, and how a person that’s new to Clojure could think about this lack of frameworks, how to handle this situation, and what to expect from the language.
So, first things first: Clojure is made to be a hosted language. Which means it expects you to use Java libraries, or Javascript ones, if you’re in ClojureScript. Sure, in Javascript things are more difficult mostly because of the weird ecosystem that expects everything to be transpiled first, but most of the time you can use interop just fine.
All this to say: you don’t need to wrap libraries. Most people I know, me included, said sometime that Clojure needs more libraries that wrap over other other things, and while I still would love to just stay on “Clojure-land” most of the time, it’s better to have a stable Java library that we can use over Clojure than an old, unstable, and severely lacking behind features that wrap the Java one to have a “Clojure feel”. Most of the time, you can have a “Clojure feel” with few lines of code anyway.
(more…)
So, I left GitHub. Thankfully so. Only at my work, and because I’m working on Atom, I keep code on that service.
For a while GitHub was degrading into a service that I felt I was not the target client anymore. In the beginning, GitHub felt like a social network for nerds – a place where we could share code, make pull requests, make the code talk instead of other things. Forking was not a bad thing anymore, because we could track who forked, what they were working on, and how to contribute or get their changes in any time.
Now, GitHub feels more like a enterprise thing where things are bureaucratic and you can’t trust anyone. A place filled over the top with telemetry, where you and your code are the product (regardless of which license you choose for your code) and where you must add “rules” for everything otherwise you’ll be bothered over and over again.
I’m referring to the new “please protect you branches” and “add requirements to merge PRs” popups, obviously.
(more…)
Recently Microsoft announced that the destruction of the Atom editor – I already posted about that, but I want to say that the community response for the sunset was really wonderful – in the beginning, I really thought that the Atom editor would die with the Microsoft announcement. But after posting on a lot of channels, and a very organized “call for arms”, we were able to organize ourselves and create something wonderful – the atom-community is now more active than ever, and indeed there is work being done right now.
People decided join our discord servers; we are reimplementing the API that will be discarded by Microsoft, and modernizing the editor like, for example, bumping tree-sitter and Electron (we now can run Atom on Electron 12); we also will need to rebrand it, and the name chose – Pulsar – could not be more fitting: it’s easy to remember, it basically means a “star that dies, but starts to spin faster and give bursts of radiation”.
I also was able to somehow bootstrap the editor without the original “bootstrap script” from Atom (that is famous to not work correctly, and also need an older version of Node.JS). I was also able to build binaries of Atom with “electron builder” – it’s library from the electron community to build the binaries instead of the way Atom do today (that is a bunch of scripts).
So this makes 5000 lines of code less that we have to keep of Electron scripts – except for the fact that there’s actually a lot of things in Atom that depends on things that these 5k lines do – like some plug-ins that misbehave when you don’t run the scripts, and all the test code that currently will not even run if you don’t bootstrap things.
So what this means for the Saturn editor? Is it the death of the product, like, will Pulsar will be basically the editor that I want to have? And unfortunately, it seems the answer for that question is “no”.
(more…)
So, Microsoft blogger decided to post about “sunsetting Atom”.
Honestly it’s an amazing euphemism for “for killing Atom” so I’m not going to bother to sweet-coat anything: in fact this post will probably have some harsh words, so if you like Microsoft (for some reason) I advise you to stop reading…
Anyway: Microsoft is a shitty piece of crap company. They committed so many crimes and the reason why they didn’t answer for most of these is because they bought the lawyers that were accusing them. When they they posted that they are going to Sunset Atom, it sounded like an inevitable thing – Atom was stalled, so they’re going to archive the repositories and if someone wants to keep using this just fork it and keep developing the editor.
But the truth is – not even this is possible. And we’re going to find out why in a moment, but first a little bit of story:
Even though Microsoft told everybody that they were going to keep developing the editor, it is strange that years later they decided to just give up on the idea. But this decision was not rushed in any way – they were planning to do that for a long time!
(more…)
So, my old post made to Reddit, and as I expected, lots of people complained about my conclusion. I still find damaging that Clojure community have this huge energy on defending “core” solutions, even when they are low-level, impractical, or (in this case) does not work well, if it works at all. But, well, I decided to clarify some of the posts, and answer some of the comments that people told me would, supposedly, “solve” the problem. I already answered these questions on other forums, so I’ll try to re-use some of my comments:
<p!Some people asked about interop with <p!. Honestly, when I made the article, this option did not exist. Even then, a Promise can be rejected and resolved with arbitrary data, so to translate this code to ClojureScript means capturing the original result of <p!, check if it’s an ExceptionInfo, with the right type, and extract the right part. It’s also harder to compose IMHO (like, with Promises, you can chain actions, then if any of them fail, you can catch the error and the promise is back to the “success” phase). But at least, now it’s less complicated – although I would say, if you’re going to add a library to your project, why not add funcool/promesa instead of core.async? Remembering that promesa is both faster than core.async, and its constructions can work with any arbitrary data, not only promises, so you can treat all code as if it’s async (or sync), without needing to remember which ones are promises, and which ones are not…
.pause and .resume constantlyThis works, indeed. For example, with sockets:
(.on socket "data" (fn [data]
(.pause rs)
(async/put! chan data #(.resume socket))))
(.on socket "end" #(async/close! chan))
But not all callback-based async code in ClojureScript allow you to pause events. Node.JS Socket do, WebSocket in browser don’t. Also, NPM package pg, when you query with a cursor, also will not allow it. In this case, there’s nothing you can do, really – you will either drop messages, or an exception will happen.
offer!(go (>! and put! both are fragile with callbacks, because you can’t really “park” or “block” threads in Javascript. Keep put!ing messages in a channel, and you’ll hit an exception “No more than 1024 pending operations” (or something like that). So people asked me to use offer! or make a sliding buffer, etc. This doesn’t really solves the problem if you can’t drop messages – and I do have lots of cases when this happens. There were some people that told me that dropping messages is part of the life, and I wholeheartedly disagree – there are LOTs of situations when you can’t loose anything – bank transactions, socket messages (you can’t reconstruct the payload if you lost part of it), downloads, etc. There are ways to mitigate this, for example:
(more…)
So… my last post was somewhat sad – I tell about how impossible is to keep the Atom editor. Unfortunately, it still holds true – it’s close to impossible to handle the insane amount of code that Atom have.
But maybe is there a different way? So I decided to try: presenting, Project Saturn: a huge editor, but less dense. That’s the idea.
Saturn always fascinated me, and still fascinates: it’s a huge planet, but less dense than water. With a sufficient big bowl of water, Saturn would float. That’s precisely the idea I want in this new editor: to be less dense to keep, while somehow maintaining the power and “wow factor” of the editor. So, how to do it?
(more…)