Live data from Hacker News

Atom was archived today

github.com

571–580 of 614 posts

Re: Atom was archived today

#571
post #488

Earlier quoted context omitted.

On the contrary, working in a professional environment, almost no one I know is using vim or Emacs seriously day to day for coding. We all use VSCode because that is a tool that just works for our team and company. Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs. No, everything sim…

Sounds like junior web devs working on Javascript pull-in-the-whole-internet code bases. Not criticising your choice, it might be the best solution to your specific challenges; that just does not sound like the environment I work in. If somebody can't configure their own editor and its dependencies, I wouldn't trust them to handle application dependencies in the supply chain either. Then again, I might pre-date the w…

For seniors, sure that makes sense, use whatever editor you want, but for onboarding juniors, we definitely have a recommended toolset just so we can make sure there aren't incompatibilities and that their productivity is still high, ie having a debugger when needed, using code completion, error checking, linting tools etc.

My point is you could configure all this stuff in Vim or Emacs but it's not as straightforward plus it wastes time when onboarding. We'd rather have an IDE like experience.

Re: Atom was archived today

#572
post #282

Earlier quoted context omitted.

On the contrary, working in a professional environment, almost no one I know is using vim or Emacs seriously day to day for coding. We all use VSCode because that is a tool that just works for our team and company. Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs. No, everything sim…

I don't understand, what config is necessary to work on the same codebase? Whatever program I use to open source code, eg. emacs or vscode, shouldn't matter should it? The only time I ever had to use vscode working with other programmers was for pair programming, using the vscode sharing thing. Apart for that, not being able to use emacs would be a deal breaker - using other editors is like wading through quicksand f…

I made a related reply here: https://news.ycombinator.com/item?id=34020775

It's not just the code, we'd want everyone on the team to use the appropriate toolsets including debugging and error checking support. They can set it up in Vim and Emacs if they want but it saves time for the team as a whole if we all use a standardized set of tools.

Re: Atom was archived today

#573
post #225

Earlier quoted context omitted.

I don't like any framework that uses templates. I already know JS, let me use that. Also they usually work poorly with editors and TypeScript since they require custom syntax to be supported. I'll stick with JSX.

I like JSX too, it allows multiple composable components in the same file, but Sveltekit support for typescript has been amazing so far, the whole framework has been written with typescript in mind and it shows.

That's good to hear. I also used to use Vue before switching to React, which has a similar layout, ie HTML, styles, and script tags in a single file component. It was alright but it had some weird rules, like registering plugins, two way data binding, etc.

Biggest thing though is the package support for Vue and other non-React libraries was miserable compared to React, so I switched and I definitely prefer it over any template-based framework.

Re: Atom was archived today

#574
post #564

Earlier quoted context omitted.

No, but it does allow remote pair programming via its live share feature

As a vim user with only superficial emacs experience, does emacs have something like the remote file system setup that VS Code with the ssh extension provides? Basically local editor with local response time, but file system is external? I realize sshfs provides something similar, but it has a few rough edges compared to the vs code implementation.

Yeah, look at tramp-mode

Re: Atom was archived today

#575
post #564

Earlier quoted context omitted.

No, but it does allow remote pair programming via its live share feature

As a vim user with only superficial emacs experience, does emacs have something like the remote file system setup that VS Code with the ssh extension provides? Basically local editor with local response time, but file system is external? I realize sshfs provides something similar, but it has a few rough edges compared to the vs code implementation.

I hesitate to dive into comparing editors, but here goes. I've used editors for a very long time, I believe the first was TECO sometime in the 1970s at the time I stopped punching cards. My preferred editors now are Emacs, Neovim, Jet Brains IDEs, and VSCode (in that order). All of them are really great professional grade tools.

Emacs supports editing remote files via ssh, ftp, or scp; one simply refers to filenames like: /ssh:host:filename or /ssh:user@host:filename. It's pretty simple and transparent. One can browse remote directories, etc.

Likewise editing a local file under a different user id is also supported using paths that look like /sudo::filename.

See section 18.5 Remote Files in the Emacs user manual[1].

[1] https://www.gnu.org/software/emacs/manual/html_mono/emacs.ht...

Re: Atom was archived today

#576
post #564

Earlier quoted context omitted.

No, but it does allow remote pair programming via its live share feature

As a vim user with only superficial emacs experience, does emacs have something like the remote file system setup that VS Code with the ssh extension provides? Basically local editor with local response time, but file system is external? I realize sshfs provides something similar, but it has a few rough edges compared to the vs code implementation.

Yes, when you're editing a remote file, using commands to access a shell or browse directories will open a shell in the remote system/browse remote directories- it all feels the same as working with local files.

Something I have yet to try is using an lsp server with a remote project. I'm not sure how some, like the rust lsp, that need the whole project (at least w/ emacs it doesn't yet support isolated files), would work.

Re: Atom was archived today

#577
post #75
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 impressive, but to keep it in perspective, consider that an editor with a bug might corrupt a file, an OS with a bug might corrupt an entire file system and at worst a bad OS could actually damage hardware. Windows, MacOS, and Linux or BSDs are incredibly impressive software.

Emacs has around 6000 packages available from the most common repositories. Nine years ago Emacs had over 1.6 Million lines of code. It would be much larger now. How many lines of code in VSCode? I don't know.

However, consider really large projects in lines of code (see [1]):

     Average iPhone app: .... 40,000

     Space Shuttle: ........ 400,000

     Windows 3.1: ........ 2,300,000

     World of Warcraft: .. 5,250,000

     Android OS: ........ 11,800,000

     F35: ............... 24,700,000

     Windows 7: ......... 39,300,000

     Facebook: .......... 61,000,000

     Google: ......... 2,000,000,000
Where does VSCode fit in this list.

[1] https://thenextweb.com/news/google-requires-5000-times-code-...

Re: Atom was archived today

#578
post #282

Earlier quoted context omitted.

I don't understand, what config is necessary to work on the same codebase? Whatever program I use to open source code, eg. emacs or vscode, shouldn't matter should it? The only time I ever had to use vscode working with other programmers was for pair programming, using the vscode sharing thing. Apart for that, not being able to use emacs would be a deal breaker - using other editors is like wading through quicksand f…

I made a related reply here: https://news.ycombinator.com/item?id=34020775 It's not just the code, we'd want everyone on the team to use the appropriate toolsets including debugging and error checking support. They can set it up in Vim and Emacs if they want but it saves time for the team as a whole if we all use a standardized set of tools.

Yes, that makes perfect sense. If they want to set up an alternative editor, doing it on their own time is a reasonable expectation. No question vscode is millions of times easier for juniors.

Re: Atom was archived today

#579

Earlier quoted context omitted.

Honestly I’m not a fan of VSCode as a user. It’s too generic and lacks identity (too powerful to edit simple configs); it auto-updates every time I start it; it’s too complicated to configure; JSON is ugly and it’s 2022, why not favor GUI configurations? If my goal is to program in language X then I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about. That being said,…

These seems impression by somebody who's not a VSC user at all. Specifically: > it’s 2022, why not favor GUI configurations? VSC provides, at all the (four) levels, both GUI and text-based configuration editing. > JSON is ugly You can't get any simpler than JSON. The VSC designers have actually been admirably pragmatic, and opted for JSON5-ish, which supports comments and terminal commas (in arrays). > too powerful t…

If you like JSON that much, obviously you haven't yet seen https://github.com/Enhex/Deco

Re: Atom was archived today

#580
post #229

Earlier quoted context omitted.

again, like the JVM I am not particularly fond of Java (I know I am not alone :-D).

The third most loved language [1], below Rust and Elixir, uses the JVM: Clojure. [1]: https://survey.stackoverflow.co/2022/#section-most-loved-dre...

Yeah, I wasn't suggesting the JVM was bad (on the contrary, I think it is quite good). I was just putting Java in the "crappy language" camp.

The best use of Java is implementing Clojure. Of that (Clojure) I am a fan.

Post reply on HN