Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atom was archived today

github.com

Post reply on HN
Print view View original

331–340 of 614 posts

Re: Atom was archived today

#331

Post by unsafecast »

fragmede wrote: post #294
themoonisachees wrote: post #277

Earlier quoted context omitted.

Forgot to type the rest and can't edit for some reason. On the other hand, vim or Emacs with all features I personally currently use in vscode come in at a fraction of the memory usage, and it is a bit dumb to have to use that much ram for slack or discord considering how light IRC clients used to be.

Yeah it's dumb but what're you gonna do? Technology evolves and the way this industry works is you gotta keep up. Can't keep computing like we're still on mainframes writing Cobol.

According to the industry, my laptop is slow. I, however, think that my laptop is actually very fast. It's just that everyone gets new stuff every year and the threshold for "usable computer" goes up accordingly.

VS Code is unusable on my laptop. I tried it, it's way too slow to be usable. I've used vim with a few plugins that got it to the same feature set as VS Code and it's actually usable. At some point I tried Lite XL, and it was incredibly fast with the same features. More recently, I tried helix and I can say that I've never used such a fast editor with auto complete and all that.

Most electron applications waste me time and energy (both human and electricity), and if software keeps going this way it'll start wasting me money. I'm not thrilled, but like you said, what are you gonna do?

Re: Atom was archived today

#332

Post by TeMPOraL »

nocman wrote: post #236
p-e-w wrote: post #18

Earlier quoted context omitted.

Electron is essentially an operating system that runs on every operating system, so you can target just a single OS and your application works everywhere.

The selling point of Electron is that it is cross platform, but that does come at a cost. The cost is essentially running a separate instance of Chrome for every application you run that is built with it. The runtime overhead for that is significant. It is a tradeoff that works for some applications, but there are a huge number of applications for which it makes them resource-sucking pigs that do not provide value si…

The source of most of complaining about Electron and companies/developers choosing to use it is that it's not just an ordinary trade-off. The gains - being cross-platform - accrue mostly to the producer side (cheaper to develop and maintain). The costs - resource use at runtime - happens entirely on the consumer side.

In other words, it's a typical case of costs being externalized, making the supposed trade-off be a "free win" instead. Since software resists commoditization, consumers don't even have a way to pass those costs back onto the vendor (by e.g. leaving for a competitor).

Re: Atom was archived today

#333

Post by Chazprime »

p-e-w wrote: post #75
esprehn wrote: post #32

Earlier quoted context omitted.

Atom predated the LSP and leaned heavily into customizations with all the plugins running inside the UI thread (more like a traditional web page and 3p scripts). At the time they viewed the extreme customization support as a feature, and there was a thriving ecosystem of folks making plugins. That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up…

VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn. VSCode did almost everything right: The choice of TypeScript as the base language (with wh…

> VSCode is one of the greatest pieces of engineering of our time

I feel this is a slight overestimation of VSCode’s design.

Re: Atom was archived today

#334

Post by modo_mario »

throwaway14356 wrote: post #299
p-e-w wrote: post #143

Earlier quoted context omitted.

> All good tools need getting to know them Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival. Great tools are obvious in their base functionality and have optional additional layers that can be discovered…

I wouldn't put it that blunt but I do agree. The problem are these nerds with seemingly infinite memory. It is almost impossible for them to make a UI for the rest of us. I tried editing a txt document in vim one time. After gazing at the UI for much to long I had to ask for help because it wouldn't let me edit the txt. I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit…

>It is almost impossible for them to make a UI for the rest of us.

Have you considered that their tool is not necessarily made for you? You'd shudder at emacs yet there's still people there that really want it over vim and are more productive with it than most vim and vscode users.

>I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.

it's 1 key. It's not intuitive by default tho that's very much true.

>They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.

If you use a tool every day you're often expected to know a bit about it regardless of which one you use. The previous poster compared it to a hammer and someone else mentioned a nailgun. Similarly a an ax is simple but a chainsaw used more plenty by my father...but he knows how to replace and fix the chain, And even beyond that a nailgun and chainsaw are simple simple machines compared to the tooling you'll find in many workshops. If you processed wood professionally you'd use room filling machinery instead to make boatloads of planks and whatnot in no time.

The thing is. Much of these issues one would encounter with em and things to know them are relatively simple and easy on their own... But seem difficult if you don't know. They're pretty easy to forget if you do it once. But if you've done it dozens of times you just know. Knowing these things doesn't impact the person's ability to learn other related things much. How a new kind of wood to cut behaves or whatever in the same way that remembering that new face and name doesn't obviously directly makes me forget my existing coworkers.

Re: Atom was archived today

#335

Post by leavenotracks »

Brief comment + total noob question here:

I've been using atom for several years now to main a few sites. I have always found it a pleasure to work in, but then admittedly I am probably using a small percentage of the features that it offer.

What does it mean that the project (or any project) is archived? Does it mean that it no longer has maintainers? Should we stop using it because security will worsen due to lack of updates?

If I should stop using it - what should I try instead (apart from Vi / Emacs / VS Code, which are already well represented in the discussion)?

Thanks

Re: Atom was archived today

#336

Post by francasso »

Not even at his funeral can poor Atom be at rest, so many comments torturing or ignoring it while praising the killer.

I, for one, salute you dear Atom. You have been a worthy contribution to the community. Thanks you for all you have done.

RIP

Re: Atom was archived today

#337

Post by Lio »

otikik wrote: post #222
p-e-w wrote: post #122

Earlier quoted context omitted.

Platform conventions matter because uniformity matters. It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser. That is terrible usability, consumes brain cycles for no good reason, and is above all else completely unnecessary because modern alternatives exist that actually blend in with the system they're a part of.

I have C-f mapped to Find and C-v mapped to Paste on vim. It’s trivial to do (one line per mapping) but yes I would be considered an heretic by some vim purists. They tend to go the other way around, using plugins to make their browser behave like Vim. Which makes more sense than it might seem; if you spend a lot of time on the command line vim bindings are better supported than ctrl c ctrlv

I never really see the need to do that remapping. By default in a Linux terminal Ctrl-Shift-v is paste and Ctrl-Shift-c is copy.

On macOS there's an extra set of keys so Cmd-v is paste and Cmd-c is copy.

I think I committed that to muscle memory so long ago that I never really think about it unless someone asks.

Not sure about Windows as I haven't used it professionally since 2006 but I'd guess it's the same as Linux.

Re: Atom was archived today

#339

Post by thom »

satvikpendem wrote: post #251
thom wrote: post #220

Earlier quoted context omitted.

My experience of VSCode _is_ messing around with my config, but giving up and going back to a more mature editor because I could never get it to do what I wanted. I suppose capitulation was also an option, but I dislike the characterisation of tooling as something other than ‘actual coding’.

That's very strange, when did you use it? And what config did you need? In our company there really isn't any config we mess around with, just download the language plug-ins and that's it. If someone wants to add more then that's fine but not required.

I have a setup that I maintain and I pop back to it every six months or so. There are probably three classes of things that end up turning me off.

1) VSCode is very UI heavy and doesn’t allow consistent keyboard and text navigation. I want my text editor to be text-based, and it slows me down to have different types of windows (some of which seem impossible to hide permanently) with inconsistent forms of navigation.

2) The terminal window is its own thing, even if you open it in an editor window, which is then ignored by anything that interacts with the terminal. This is more what I want but is very limited and immature:

https://marketplace.visualstudio.com/items?itemName=jeffgran...

The lack of an infrastructure like Emacs comint mode also means there’s no good text-based database mode either. I want the same navigation, search and editing functions in every single window I have to interact with.

3) Where analogues to Emacs modes exist, they are universally less featureful, often because of fundamental limitations of the VSCode extension API. REPLs do less and offer less programmability. Edamagit is a fine and welcome effort but not as good as Magit.

If people want an editor with a little bit of auto completion and some squiggly lines to tell them they’ve typed something wrong VSCode is great. I have many mostly happy VSCode users within my organisation. But I think every individual programmer, like every team, should have a regular little retrospectives with themselves. What work did I do today, what would have made it flow better? In every case, I can build that in Emacs, but it’s much more friction in VSCode. This is partly immaturity and partly the APIs not offering as much. Long term I’m rooting for VSCode because it’s snappy and has undeniable market share. But it’s never quite been there for me yet.

Re: Atom was archived today

#340

Post by rodw »

wsc981 wrote: post #295
rodw wrote: post #255

Earlier quoted context omitted.

> Very minor feature. Moreover it is supported out-of-the-box in emacs: `M-x list-packages`. I think `:packadd` or something may be the equivalent for vim.

It’s also supported out of the box in SublimeText, though probably not as extensive as VSCode. Code completion, for example, is more like guessing in SublimeText. Though I can’t imagine either emacs or VSCode to respond as quickly to input as SublimeText, which is one of the reasons it will remain the text editor of choice for me. At least when writing some code in Lua.

I appreciate that perspective. Launching quickly and no input latency are probably my base demands from a text editor. Not sufficient, but necessary. I may need to give Sublime a closer look.

FWIW you _can_ get emacs to launch as quickly as, say, vi, and to respond to input as quickly as just typing in the terminal (but in my experience the default GUI doesn't have noticeable input latency):

* `emacs -nw` will launch emacs in a terminal rather than a OS-native GUI window. This has surprisingly little impact on the interface or usability, but it does make cosmetic tweaks like font-rendering more difficult.

* `emacs --daemon` will start an "emacs server" process running in the background, and `emacsclient` will connect a UI instance to it (so you don't need to re-process all your .emacs stuff each time)

That said you can probably introduce a lot of input latency by hooking a slow method to the keypress event, but that applies to Atom and VSCode as well as emacs. But all three of them seem to do OK suggesting auto-completions of one kind or another, which must be handled on keydown or similar, so maybe that's not as critical as I assume.

I usually have a text editor open all the time anyway (recently Atom, lately VSCode) so the time-to-launch isn't that big of a deal in practice (and isn't _that_ large to begin with) but I am disproportionately, irrationally annoyed every time I need to wait for the editor to start.

Post reply on HN