3 ms·

I converted 140+ CLion users to VS Code / vim / Emacs (mostly vscode) at our company. It's not about the "text editor". It's about the LSP and implementations

by kmarc 2y ago

I converted 140+ CLion users to VS Code / vim / Emacs (mostly vscode) at our company. It's not about the "text editor". It's about the LSP and implementations for it. Like it or not, before LSP, code intelligence tooling was quite bad in the "text editor" land (except for some tools like clangd or jedi). Today it's a bliss to use a performante, small footprint editor and offload code intelligence. Although, IDE-lover users swear that their IDE's built-in code intelligence is superior (which, in some cases, is objectively true). Thanks to Microsoft, I guess. Thanks to the FOSS world for the implementations, too.

thom 2y ago
Was this before or after Nova? I’ve found CLion quite pleasant coming from Emacs - it’d been years since I wrote C++ and I’d never used CMake so I was finding myself spending too long feeding Emacs to get an environment I was happy with. It’s nowhere near as powerful as a modern Java or .NET IDE (I have indulged this new guilty pleasure and played with the whole JetBrains suite at this point) but I’ve found it plenty powerful. I still default to Emacs for ecosystems I know well though, and expect I’ll migrate back fully at some point.
- kmarc 2y ago
  We were among the first to try Nova (talking directly with the Developers) and while it's slightly better than CLion classic, the double size package and still no remote index support didn't warrant rolling it out, unfortunately. We created a clangd-based setup with remote indexes so that our developers can open their editor (vim / vscode) and within 10 seconds they get access to full code intelligence on the 20M+ SLOC monorepo. This is unimaginable with CLion, where developers have to scope down their "view" on the monorepo to a handful of directories, and still wait half an hour for the indexing to happen
  - thom 2y ago
    Gotcha, nicely done.
  - bbkane 2y ago
    I'd love to know what product/monorepo has 20M+ SLOC if you'd be comfortable sharing that
    - kmarc 2y ago
      Internal. 30+y of development with multiple languages, and I'm still a rookie when I look at the code and the progress of it, and part of the revenue (maybe even most of it) doesn't even come from this monorepo codebase. My understanding is that 20M+ SLOC is not even considered a super large code base, though, when it comes to those "textbook" monorepo examples (urban legends?)

by kmarc 2y ago

thom 2y ago

Was this before or after Nova? I’ve found CLion quite pleasant coming from Emacs - it’d been years since I wrote C++ and I’d never used CMake so I was finding myself spending too long feeding Emacs to get an environment I was happy with. It’s nowhere near as powerful as a modern Java or .NET IDE (I have indulged this new guilty pleasure and played with the whole JetBrains suite at this point) but I’ve found it plenty powerful. I still default to Emacs for ecosystems I know well though, and expect I’ll migrate back fully at some point.

kmarc 2y ago
We were among the first to try Nova (talking directly with the Developers) and while it's slightly better than CLion classic, the double size package and still no remote index support didn't warrant rolling it out, unfortunately. We created a clangd-based setup with remote indexes so that our developers can open their editor (vim / vscode) and within 10 seconds they get access to full code intelligence on the 20M+ SLOC monorepo. This is unimaginable with CLion, where developers have to scope down their "view" on the monorepo to a handful of directories, and still wait half an hour for the indexing to happen
- thom 2y ago
  Gotcha, nicely done.
- bbkane 2y ago
  I'd love to know what product/monorepo has 20M+ SLOC if you'd be comfortable sharing that
  - kmarc 2y ago
    Internal. 30+y of development with multiple languages, and I'm still a rookie when I look at the code and the progress of it, and part of the revenue (maybe even most of it) doesn't even come from this monorepo codebase. My understanding is that 20M+ SLOC is not even considered a super large code base, though, when it comes to those "textbook" monorepo examples (urban legends?)