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

Atom 1.33

blog.atom.io

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Atom 1.33

#21

Post by coder543 »

hit8run wrote: post #20

I wish they could get Ruby working in Atom out of the box. I still can‘t believe how weak the tooling is in the Ruby on Rails world. Even Jetbrains fails miserably. Why on earth can‘t we have decent code completion in Ruby?! If the human brain can tell what will be available why can’t my computer.

I don't think even the human brain can consistently figure out what's going to be available in Ruby.

Oftentimes, the only way to know is to set a breakpoint, run the code, and inspect it at runtime. This is why the tooling sucks even more for Ruby than most dynamic languages, and the code completion and static analysis will almost certainly always be worse than the equivalent tooling in a statically typed language where more things are knowable.

If you feel so strongly about tooling, I recommend learning Kotlin, Go, or C#, all of which offer incredibly strong tooling with essentially perfect code completion, jump to definition, and real time code analysis.

Re: Atom 1.33

#22

Post by josteink »

melling wrote: post #7
Beefin wrote: post #3

I like the flexibility and customization of Atom but god damn they need to get off the RAM-hogging process that is Electron...

People complained about Emacs memory usage for decades. Then one day 8 MB wasn’t a lot of memory. Everyone knows Atom uses a lot of memory. At some point in the very near future, it will no longer be important. My five-year-old Mac has 16 gigs of RAM. I won’t buy another that has less than 32 gigs.

> Everyone knows Atom uses a lot of memory. At some point in the very near future, it will no longer be important. My five-year-old Mac has 16 gigs of RAM. I won’t buy another that has less than 32 gigs.

As a counterpoint, my 3 year old laptop has 8GBs if memory, my server 12gb and none of them are maxed.

My next unit won’t have more than 16gbs, because that would be an absolute waste.

Maybe use less Chrome and Chromium/Electron based shit, and you’ll find out how insanely much ram 8GBs actually is?

Re: Atom 1.33

#23

Post by pictur »

marsrover wrote: post #2

I'll admit that I haven't used Atom in a very long time, but to be it just seems like a worse version of VS Code. I don't think I've ever introduced an Atom user to VS Code and they stick with Atom. Every one of them switches.

vscode gives me the impression of a shitty microsoft product.

Re: Atom 1.33

#24

Post by willio58 »

pictur wrote: post #23
marsrover wrote: post #2

I'll admit that I haven't used Atom in a very long time, but to be it just seems like a worse version of VS Code. I don't think I've ever introduced an Atom user to VS Code and they stick with Atom. Every one of them switches.

vscode gives me the impression of a shitty microsoft product.

Have you actually used it? I'm by no means pro-microsoft but vscode is a joy to use.

Re: Atom 1.33

#25

Post by mateuszf »

hit8run wrote: post #20

I wish they could get Ruby working in Atom out of the box. I still can‘t believe how weak the tooling is in the Ruby on Rails world. Even Jetbrains fails miserably. Why on earth can‘t we have decent code completion in Ruby?! If the human brain can tell what will be available why can’t my computer.

Because of lot of metaprogramming and monkeypatching Ruby is famous from.

Re: Atom 1.33

#26

Post by Klathmon »

josteink wrote: post #22
melling wrote: post #7

Earlier quoted context omitted.

People complained about Emacs memory usage for decades. Then one day 8 MB wasn’t a lot of memory. Everyone knows Atom uses a lot of memory. At some point in the very near future, it will no longer be important. My five-year-old Mac has 16 gigs of RAM. I won’t buy another that has less than 32 gigs.

> Everyone knows Atom uses a lot of memory. At some point in the very near future, it will no longer be important. My five-year-old Mac has 16 gigs of RAM. I won’t buy another that has less than 32 gigs. As a counterpoint, my 3 year old laptop has 8GBs if memory, my server 12gb and none of them are maxed. My next unit won’t have more than 16gbs, because that would be an absolute waste. Maybe use less Chrome and Chrom…

Is it a waste if it's getting used?

I know this argument tends to become a bit philosophical, but if (ab)using memory the way that browsers or Electron does means that programs can be written faster, be safer, and can run on more platforms, then is it really being wasted?

Sure, it's not runtime efficient in many cases, but that's not the only thing that matters, and it's pretty far from the top priority for many.

I quite frankly make a ludicrous amount of money doing software development. Spending even $1000 on an upgrade to my machine that makes me 1% more productive would end up paying for itself in less than a year.

For me, RAM isn't something I worry about, I have 32GB in this system and i'm not anywhere near maxing it out at my current day job (and for what it's worth, my atom instance that i've had open for about 3 days now is taking up a combined 432mb of memory at this moment, Android Studio is sucking down a whopping 1.5 GB. In my experience the "ram usage" of Electron is blown wildly out of proportion, it's really not that bad to be honest). Atom makes me more productive, so I use Atom, and the memory usage could greatly increase and it wouldn't impact me at all.

Some people work differently, they either aren't as fortunate as I am and can't afford the fancy hardware (or can afford it but simply don't want to buy it, which is okay!), or just prefer working in an environment which starts up faster or uses less resources, or anything else. For them there are other editors, other IDEs, other software they can use.

None of them are objectively "bad" or wrong, they just prioritise different things.

Re: Atom 1.33

#27

Post by 013a »

melling wrote: post #7
Beefin wrote: post #3

I like the flexibility and customization of Atom but god damn they need to get off the RAM-hogging process that is Electron...

People complained about Emacs memory usage for decades. Then one day 8 MB wasn’t a lot of memory. Everyone knows Atom uses a lot of memory. At some point in the very near future, it will no longer be important. My five-year-old Mac has 16 gigs of RAM. I won’t buy another that has less than 32 gigs.

That's a poor comparison. The difference between back then and now is: Back then, no one knew we'd have such an exponential increase in computing power. But we got it. Today, everyone expects that tomorrow will yield an exponential increase in computing power, because that's the way its always been. But that increase isn't coming.

In other words, products back then were never engineered with that exponential increase in mind. Often it just happened, accidentally or because the creators had a large vision that genuinely needed that much memory. Products today, like browser rendering runtimes and by extension Atom, literally are. The problem with writing code engineered ideally for the computers of tomorrow is that, in the realest sense of the word, tomorrow never comes. Today, its "32gb of memory is expensive and rare, but it'll get cheaper." You keep that product development mindset and tomorrow it'll be "64gb of memory is expensive, but it'll get cheaper." Your product will always be slow. Tomorrow never comes.

And it'll take teams like the Chrome team far too long to realize that we're fucking done with exponential increases at an industry level. They're over. Maybe in twenty years we'll get a revolution like memristors or graphene or something, but that shit is not going to be soon. The backend engineering world has already figured this out and moved hard to scale-out instead of scale-up, but the UI world is still caught-up in this pretty little fantasy that, well, you know, the next iPhone will have 6gb of memory so it'll just be a little slow until then.

Re: Atom 1.33

#28

Post by Waterluvian »

rimunroe wrote: post #10
marsrover wrote: post #2

I'll admit that I haven't used Atom in a very long time, but to be it just seems like a worse version of VS Code. I don't think I've ever introduced an Atom user to VS Code and they stick with Atom. Every one of them switches.

Hi. I've been using VS Code for a bit now but I'm actually going back to Atom. I run into a lot more bugs with VS Code--or at least the (very few) plugins I'm using with it--than with Atom. For example When writing JSX, I'll occasionally add a wrapping element around another, and suddenly I'll get lint warnings about unexpected tokens. Using the "reload window" command or exiting and opening the editor again makes it…

FWIW lint warning errors is not a vscode problem, it's a plugin or eslint configuration problem.

And you can do a lot to clear up the UI of features you don't want.

Not saying you're wrong in your feelings or decision to switch. But there might be remedies!

Re: Atom 1.33

#29

Post by RandallBrown »

Beefin wrote: post #3

I like the flexibility and customization of Atom but god damn they need to get off the RAM-hogging process that is Electron...

I believe Electron was created to build Atom, so you can't really "get off" of it without making an entirely new application.

Re: Atom 1.33

#30

Post by [deleted] »

jrsnyder wrote: post #19
marsrover wrote: post #2

I'll admit that I haven't used Atom in a very long time, but to be it just seems like a worse version of VS Code. I don't think I've ever introduced an Atom user to VS Code and they stick with Atom. Every one of them switches.

After looking at both, I chose Atom. The VS Code developers observed that things can pretty tangled with open-ended plugins and HTML rendering, so they cordon off plugins to separate processes, and only offer limited UI control to plugins. This helps keep things stable and fast, but I think the ability to have plugins easily create new UI in an open-ended way is the coolest feature that Electron enables in an editor.…

[deleted]
Post reply on HN