Improving startup time in Atom with V8 snapshots • Hacker News Board

Re: Improving startup time in Atom with V8 snapshots

#161

Post by matt4077 » Wed, Apr 19, 2017, 4:12 PM UTC

posguy wrote: post #153

matt4077 wrote: post #145

Earlier quoted context omitted.

I'd offer the alternative theory that the VSCode team learnt everything they could from Atom's past mistakes. Speed is only one of the issues–I'm actually quite happy with Atom in that regard. VSCode has a much more restricted API, and a more robust extension system. With Atom, I always felt like extensions started interfering with each other, and with the 'vanilla' experience. OTOH, I was exploring a few ideas, such…

Sounds similar to the complaints about Firefox, though the only notable issues I've run into with Atom have been related to shared file editing (and resulting sync issues). If someone could just leverage etherpad lite with Atom, it'd make me so happy!

Firefox mostly has the problem that the open web suddenly became incredibly important for Google: it's their platform, in the fight against Facebook and Apple's iOS.

No organisation on the planet could compete with a team that Google considers a core asset for actual survival.

Mozilla has made quite a few mistakes, but the times may change, and I sure hope they'll be around when Google's incentives are no longer aligned with the open web's.

Re: Improving startup time in Atom with V8 snapshots

#162

Post by Veratyr » Wed, Apr 19, 2017, 4:52 PM UTC

reissbaker wrote: post #159

Veratyr wrote: post #122

Earlier quoted context omitted.

I don't think that's true. The JVM is far closer to native code than Javascript, both technically and in terms of actual performance. Here's some synthetic number crunching benchmarks: https://benchmarksgame.alioth.debian.org/u64q/javascript.htm... Even on the I/O heavy workloads that Node/V8 should be able to handle best, Java is ahead: https://www.techempower.com/benchmarks/ And yes, there are many Java apps that l…

The JVM is a virtual machine, just like V8, and neither is particularly "native." Java is an easier-to-optimize language than JavaScript, mainly because static types give better information to the compiler and prevent certain kinds of hard-to-optimize behavior from being written in the first place. That being said, as someone who's used both Atom and IntelliJ a fair amount (although my daily driver is Vim), you can d…

I don't think IntelliJ vs. Atom is a good comparison for Electron vs. JVM. IntelliJ is doing a lot of things Atom doesn't do, like loading/building an index of all of your code and dependencies in order to auto-complete and show docs on demand.

Re: Improving startup time in Atom with V8 snapshots

#163

Post by posguy » Wed, Apr 19, 2017, 5:28 PM UTC

matt4077 wrote: post #161

posguy wrote: post #153

Earlier quoted context omitted.

Sounds similar to the complaints about Firefox, though the only notable issues I've run into with Atom have been related to shared file editing (and resulting sync issues). If someone could just leverage etherpad lite with Atom, it'd make me so happy!

Firefox mostly has the problem that the open web suddenly became incredibly important for Google: it's their platform, in the fight against Facebook and Apple's iOS. No organisation on the planet could compete with a team that Google considers a core asset for actual survival. Mozilla has made quite a few mistakes, but the times may change, and I sure hope they'll be around when Google's incentives are no longer alig…

Google can be out-competed, look at their attempts at social networks & messaging/calling.

Google has lit dumpsters full of cash on fire in an effort to get anywhere near Facebook, Twitter, Whatsapp, Viber or even Signal Private Messenger, and yet their extremely fractured strategy that they have dumped R&D into still has less users than any of those in their respective categories.

Mozilla can be competitive, akin to Darktable vs Adobe if Mozilla chooses to be. No more mucking about bailing their friends out (ie: Pocket acquisition), or trying to fight Google on hardware prices (Firefox OS's entire strategy). Mozilla can create a playing field tilted in their favor, and force others to compete on their turf rather than duking it out on Google or Chinese OEMs turf.

Re: Improving startup time in Atom with V8 snapshots

#164

Post by type0 » Wed, Apr 19, 2017, 8:08 PM UTC

matt4077 wrote: post #145

WhitneyLand wrote: post #143

Is there any way not to conclude they have just been out designed/architected/optimized by Microsoft? What a compliment to the VSC team that after all this work, Atom still doesn't seem to match startup time, or more importantly perceived performance while editing. It's a more interesting comparison since they're both bound by similar constraints, and building cross platform apps. In the bad old days I once worked fo…

I'd offer the alternative theory that the VSCode team learnt everything they could from Atom's past mistakes. Speed is only one of the issues–I'm actually quite happy with Atom in that regard. VSCode has a much more restricted API, and a more robust extension system. With Atom, I always felt like extensions started interfering with each other, and with the 'vanilla' experience. OTOH, I was exploring a few ideas, such…

Why is it always Atom and VS Code and no one talks about Adobe Brackets, is it comparable for JS development? too bad Adobe doesn't care about Linux.

Re: Improving startup time in Atom with V8 snapshots

#165

Post by ruleabidinguser » Wed, Apr 19, 2017, 10:23 PM UTC

coldtea wrote: post #160

ruleabidinguser wrote: post #91

Earlier quoted context omitted.

Well sure we beat reddit I guess, and maybe I just don't post here enough, but I feel like the community is deteriorating. I used to hold this place to higher standards. Also I still don't think what I said was ridiculous, and its something I basically believe.

Well, it might not be ridiculous IF qualified. E.g. "most of algol-derived languages are quite similar, aside from small differences in syntax and feature set". Or: "Most modern mainstream languages, etc have pretty much similar feature sets and syntax (while still differing in being dynamic vs statically typed etc)" That's not the same as what you said.

i suppose youre right

Re: Improving startup time in Atom with V8 snapshots

#166

Post by jnordwick » Wed, Apr 19, 2017, 11:19 PM UTC

wingworks wrote: post #146

jnordwick wrote: post #62

I'm way more worried about memory issues while running. Atom take up 1 gig+ with very little open. It pushes all my other tools out of RAM and into swap. Switching to the browser to see documentation takes a few seconds if I'm lucky. Compiling a few more seconds to page in. Ssh a few more. Everything on my laptop slows to a crawl as they fight for RAM with Atom taking up the way more than it should. I know the answer…

Sounds like you're running on 4GB of RAM, which in today's dev world is nothing, I've been on 16GB for over 3 years and have yet to worry about RAM being a limiting factor. I'd say buy some more RAM, it IS cheap and you never have too much.

Laptops with 16 gb are still very rare.

Re: Improving startup time in Atom with V8 snapshots

#167

Post by wingworks » Wed, Apr 19, 2017, 11:40 PM UTC

jnordwick wrote: post #166

wingworks wrote: post #146

Earlier quoted context omitted.

Sounds like you're running on 4GB of RAM, which in today's dev world is nothing, I've been on 16GB for over 3 years and have yet to worry about RAM being a limiting factor. I'd say buy some more RAM, it IS cheap and you never have too much.

Laptops with 16 gb are still very rare.

I've had 16GB in my laptop for about 3 years now. Laptop CPUs have supported 16GB for quite a while. Granted I'm an Apple guy, so maybe 16GB isn't as accessible in Windows world? :(

Re: Improving startup time in Atom with V8 snapshots

#168

Post by jeremy_wiebe » Thu, Apr 20, 2017, 4:49 AM UTC

frik wrote: post #141

itp wrote: post #11

New world, same old problems. Fascinating to see how this parallels the way Emacs tackled this problem long ago. - https://lwn.net/Articles/673724/ - https://news.ycombinator.com/item?id=11001796

Is Coffee-Script still a thing? Looking at Atom source code it's still 80% in Coffee-Script. Why hasn't someone rewrote (eg transpiled and than refactored) it in JS with hand-tuned optimisation? https://github.com/atom/atom/tree/master/src

Was listening to a podcast with one of the first Atom authors (Nathan Sobo) and he mentioned that all new code is in ES6 these days. The codebase is pretty big. They're doing a convert-on-touch approach he said.

https://itunes.apple.com/ca/podcast/the-changelog/id34162326...

Re: Improving startup time in Atom with V8 snapshots

#169

Post by jazoom » Thu, Apr 20, 2017, 12:48 PM UTC

WhitneyLand wrote: post #143

Is there any way not to conclude they have just been out designed/architected/optimized by Microsoft? What a compliment to the VSC team that after all this work, Atom still doesn't seem to match startup time, or more importantly perceived performance while editing. It's a more interesting comparison since they're both bound by similar constraints, and building cross platform apps. In the bad old days I once worked fo…

Plus their speed of development has been incredible. I don't imagine it's a very large team.

And their change logs are great, thankfully.

Re: Improving startup time in Atom with V8 snapshots

#170

Post by computerex » Sun, Apr 23, 2017, 10:52 AM UTC

ruleabidinguser wrote: post #81

computerex wrote: post #61

Earlier quoted context omitted.

Not useful to serious programmers? Do you feel the same way about Vim? Just because you haven't gotten used to using something, doesn't mean it's necessarily total shit. There is a reason why people have been using emacs for decades.

I do actually, and I should reword that to "not useful for serious programming." VIM to me is best used for lightweight, quick and short editing tasks. THats how I use it. For any involved work, you're going to want a debugger, you're going to want automated build tools, you're going to want effortless compile/run cycles and so on.. You don't really want to implement all of that in VIM because your work won't be port…

Sounds to me like you aren't familiar with Vim and the ecosystem. Plug-ins are your friends. Use a package manager like Vundle to easily install plug-ins. Not sure why you say vim isn't portable. I have my vimrc file on my github. Not only is vim available on all major platforms, it comes pre-installed on a bunch of systems. All I need is my vimrc file, Vundle and an Internet connection to customize any vim install to exactly how I want it.