6 ms·

had that feeling... as a side note, i think more and more people are starting to realize that the async paradigm is not a panacea. that paradigm or at least th

had that feeling... as a side note, i think more and more people are starting to realize that the async paradigm is not a panacea. that paradigm or at least the way we implement it might even mean more trouble than a synchronous counterpart. also, other editors that i feel will be sunset or not worked on at some point are atom and brackets.

sq_ 6y ago
Atom already seems to have gone somewhat towards maintenance mode since Microsoft bought Github. Feels like there's a lot less by way of features being released and a lot more just keeping up with ecosystem/OS changes. I could certainly be wrong though.
- brunoqc 6y ago
  Microsoft probably wants people to use vscode.
  - pjmlp 6y ago
    And given how Office loves React Native, and Microsoft is making it work across all major desktop OSes, with the team continuously bashing Electron's bloat on their talks, I look forward to the way when RN powers VSCode.
- andrewflnr 6y ago
  Atom competes pretty directly against VS Code doesn't it? It makes sense that Microsoft would consolidate their efforts.
  - sq_ 6y ago
    That's what I thought, too. Hopefully the team that was working on Atom has gotten/will get a chance to bring some of its components/features to VS Code if it doesn't already have them.
    - bhl 6y ago
      There was this one comment when Github Codespaces got released that that's where ex-Atom devs got moved to: https://news.ycombinator.com/item?id=23093150 https://news.ycombinator.com/item?id=23093150
- ilrwbwrkhv 6y ago
  Atom is open source. The community can always keep working on the project if they care.
- ComputerGuru 6y ago
  I don’t see anything wrong with that, tbh. While it’s apples and oranges to compare atom to sublime, I think in an extremely fair and objective head-to-head comparison between VS Code and Atom, the latter is just a worse choice on all fronts. It came first, it filled a need, and now there’s something better. (And it and that something better is now both owned/maintained by the same organization, making it even more of a no-brainer to slowly phase the inferior option out.)
gw 6y ago
> as a side note, i think more and more people are starting to realize that the async paradigm is not a panacea. This is why libvim (from the oni2 project) is based on vim rather than neovim. Even aside from performance, it is a huge simplification if you can interact with an editor engine in the same process, synchronously. At some point we replaced simple function calls with baroque APIs accessed over localhost...
- nhooyr 6y ago
  It's not that cut and dry. See https://github.com/onivim/libvim#why-is-libvim-based-on-vim-and-not-neovim https://github.com/onivim/libvim#why-is-libvim-based-on-vim-... It's mostly due to their build system.
  - gw 6y ago
    I've seen that but Bryan said this just a few days ago: > This was a smaller consideration - but more fundamentally, the model Neovim uses for input - queuing it on an event loop and handling it asynchronously - is at odds with what we required - to be able to process the input -> handle updates synchronously. https://news.ycombinator.com/item?id=23628381 https://news.ycombinator.com/item?id=23628381
The_rationalist 6y ago
I believe that his async code would have been far more maintainable / readable / expressive if it had used a reactive streams implementation such as colorless kotlin coroutines + flow. Sadly rust doesn't yet have one. What are your thoughts on this topic @raphlinus ?
- Matthias247 6y ago
  I think this is not about coding style for async code (coroutines vs. callbacks), but about general asynchronity between various processes/threads. If you have any asynchronous background task it means the state of your application can change without the current thread having made any change. And your code needs to account for that possibility, which makes it a lot more complicated.
CyberDildonics 6y ago
I don't think you can blame this on an async design. Right off it talks about having the keyboard input as a separate process, not knowing what version of the buffer input should apply to, using timeouts and I guess, doing everything over local IP. It almost reads like a list of what not to do. Why not put the input into the window, put a version number with the buffers and keyboard input and use shared memory? Of course something isn't going to work if you don't confront the problems you have at a fundamental level.

sq_ 6y ago

Atom already seems to have gone somewhat towards maintenance mode since Microsoft bought Github. Feels like there's a lot less by way of features being released and a lot more just keeping up with ecosystem/OS changes. I could certainly be wrong though.

brunoqc 6y ago
Microsoft probably wants people to use vscode.
- pjmlp 6y ago
  And given how Office loves React Native, and Microsoft is making it work across all major desktop OSes, with the team continuously bashing Electron's bloat on their talks, I look forward to the way when RN powers VSCode.
andrewflnr 6y ago
Atom competes pretty directly against VS Code doesn't it? It makes sense that Microsoft would consolidate their efforts.
- sq_ 6y ago
  That's what I thought, too. Hopefully the team that was working on Atom has gotten/will get a chance to bring some of its components/features to VS Code if it doesn't already have them.
  - bhl 6y ago
    There was this one comment when Github Codespaces got released that that's where ex-Atom devs got moved to: https://news.ycombinator.com/item?id=23093150 https://news.ycombinator.com/item?id=23093150
ilrwbwrkhv 6y ago
Atom is open source. The community can always keep working on the project if they care.
ComputerGuru 6y ago
I don’t see anything wrong with that, tbh. While it’s apples and oranges to compare atom to sublime, I think in an extremely fair and objective head-to-head comparison between VS Code and Atom, the latter is just a worse choice on all fronts. It came first, it filled a need, and now there’s something better. (And it and that something better is now both owned/maintained by the same organization, making it even more of a no-brainer to slowly phase the inferior option out.)

gw 6y ago

> as a side note, i think more and more people are starting to realize that the async paradigm is not a panacea. This is why libvim (from the oni2 project) is based on vim rather than neovim. Even aside from performance, it is a huge simplification if you can interact with an editor engine in the same process, synchronously. At some point we replaced simple function calls with baroque APIs accessed over localhost...

nhooyr 6y ago
It's not that cut and dry. See https://github.com/onivim/libvim#why-is-libvim-based-on-vim-and-not-neovim https://github.com/onivim/libvim#why-is-libvim-based-on-vim-... It's mostly due to their build system.
- gw 6y ago
  I've seen that but Bryan said this just a few days ago: > This was a smaller consideration - but more fundamentally, the model Neovim uses for input - queuing it on an event loop and handling it asynchronously - is at odds with what we required - to be able to process the input -> handle updates synchronously. https://news.ycombinator.com/item?id=23628381 https://news.ycombinator.com/item?id=23628381

The_rationalist 6y ago

I believe that his async code would have been far more maintainable / readable / expressive if it had used a reactive streams implementation such as colorless kotlin coroutines + flow. Sadly rust doesn't yet have one. What are your thoughts on this topic @raphlinus ?

Matthias247 6y ago
I think this is not about coding style for async code (coroutines vs. callbacks), but about general asynchronity between various processes/threads. If you have any asynchronous background task it means the state of your application can change without the current thread having made any change. And your code needs to account for that possibility, which makes it a lot more complicated.

CyberDildonics 6y ago

I don't think you can blame this on an async design. Right off it talks about having the keyboard input as a separate process, not knowing what version of the buffer input should apply to, using timeouts and I guess, doing everything over local IP. It almost reads like a list of what not to do. Why not put the input into the window, put a version number with the buffers and keyboard input and use shared memory? Of course something isn't going to work if you don't confront the problems you have at a fundamental level.