[HN Gopher] My IDE is too heavy so I moved to Emacs
___________________________________________________________________
My IDE is too heavy so I moved to Emacs
Author : lycopodiopsida
Score : 237 points
Date : 2022-12-12 07:18 UTC (1 days ago)
(HTM) web link (renato.athaydes.com)
(TXT) w3m dump (renato.athaydes.com)
| SanjayMehta wrote:
| I use vim inside a VS Code terminal. Best of both worlds.
|
| I've heard of a vim extension/mod for VS Code but haven't had the
| time to dig into it.
| maratc wrote:
| You could use vim inside a regular terminal for the same
| effect, with a notable exception of sending all of your
| keypresses to Microsoft.
| elcomet wrote:
| Definitely not the same effect. The vscode application is
| much nicer than a terminal, has lot of plugins that I'm not
| sure exist for vim. And you can disable telemetry. And it's
| much faster to learn
| iillexial wrote:
| I feel like Vim has more plugins than VSCode
| elsjaako wrote:
| Nothing wrong with your setup if you like it, but I'm very
| curious what features you are missing in vim. Can you give
| any examples?
| elcomet wrote:
| The learning curve mostly. And most things you need are
| there out of the box, or very easy to install. Also
| plugins like remote ssh. Overall it just works without
| too much effort.
| quickthrower2 wrote:
| Ironically I find using a terminal inside VSCode
| horrendous. And since most times I need to open 2-3 of
| them, I have a much better experience with one terminal
| outside of it, and tmux.
|
| And if you haven't tried it, use tmux.
|
| It is the geeky tool that unlike vim/emacs you can learn in
| 60 seconds and immediately adds value. Whereas vim/emacs
| take longer to learn and get a payoff - I never managed to
| get to that part of the curve.
|
| Add another 5 minutes to set up a tmux script for your
| development workflow!
| elcomet wrote:
| I use screen which I prefer to tmux
| LoganDark wrote:
| I used to use byobu, but the Python dependency eventually
| swore me off of it
| the__alchemist wrote:
| IntelliJ needs a lightweight competitor, if that's possible. As
| the article points out, it's slow! Drains laptop battery,
| requires a powerful computer not to have slowdowns etc. (Using
| PyCharm, mainly with Rust plugin)
|
| Sublime is much lighter, but not as powerful.
| tikkabhuna wrote:
| > IntelliJ is a great product and I don't even consider switching
| to anything else for professional development, where having the
| greatest laptop and the best tools possible should be a priority.
|
| The title should really be "My IDE is too heavy so I moved to
| Emacs for hobby projects".
| deafpolygon wrote:
| That's less click-baity, though.
| throwaway2037 wrote:
| Yes, I agree. And to add my two cents, if you are living in a
| wealthy country and/or working for an established, stable firm,
| you should have an IDE with the world's worst case of type 2
| diabetes: 8+ CPU cores, 16+GB RAM, PCIe 3.0+ NVMe. (Double is
| more ideal.) Gluttony! Except as a golf-like sport, I never
| understand the obsession with "lightweight" development
| environments. Like Protoss and Zerg, it would be fun to watch
| eSports-style coding exercises with type 2 diabetes IDE vs
| vim/emacs + plugins. Example ridiculous exercise: Refactor this
| bloated enterprisey Java mess to upgrade from Spring Framework
| version X to Y. Only slighly joking here, but the vim/emacs
| setup would be smoking at the hood. The IDE would need a few
| mins of indexing, then off to the races!
| ParetoOptimal wrote:
| > Example ridiculous exercise: Refactor this bloated
| enterprisey Java mess to upgrade from Spring Framework
| version X to Y. Only slighly joking here, but the vim/emacs
| setup would be smoking at the hood. The IDE would need a few
| mins of indexing, then off to the races!
|
| It's hard for me to come up with examples where the emacs
| setup wouldn't already be done in a couple minutes or using
| grep and a writeable grep buffer.
| rg111 wrote:
| > _That's why I am currently trying to get back to using Emacs._
|
| I just wish that people write such posts six months _after_ they
| have made the switch.
|
| The author has only started. He only has stuff set up and checked
| speed. He hasn't yet become as efficient as he was with
| JetBrains.
|
| He might never become that, and after 20-30 days, he might throw
| in the towel and go back to JB.
|
| __Being too bullish too soon__ is one of the serious maladies of
| the present personal-brand /influencer culture.
| krageon wrote:
| I switched three years ago and I'm happy with emacs still. I
| don't find I miss anything jetbrains used to offer me. I might
| feel different if I spent a lot of time profiling, the one area
| where an IDE generally has a leg up - but IME the profiling
| experience in anything that isn't visual studio is bad anyway.
| luispauloml wrote:
| Well, the author says "trying to get _back_ " (emphasis mine),
| which makes me think that there is some prior experience, it's
| not "has only started." The article also says:
| > Over a couple of years, I have managed to configure Emacs
| with most basic modern shortcuts that work in most other
| applications post the 1990's (small things like Cmd+S to save,
| Ctrl+Tab to switch buffers etc.)
|
| which, on the other hand, sounds a bit weird to me. It states
| that there are years of experience with Emacs, but it wouldn't
| take years to configure small things like Ctrl+Tab. These are
| things people use very frequently, so I would imagine one would
| configure it within the first month, or even the first week, of
| using Emacs to reduce friction.
| G3rn0ti wrote:
| > and inserting custom snippets for things like
| System.out.println and public static void main
|
| YASnippet!
| the-lazy-guy wrote:
| As an emacs user I have to say that IntelliJ (and pretty much any
| modern IDE) feels snappier than emacs configured to do anything
| comparable (lsp-mode/eglot, corfu/company, tree-sitter etc).
|
| While IDEs may require more resources, they usually utilize them
| better.
|
| Emacs is fundamentally single-threaded and not great at async
| things. With most of the logic written in a very slow non-JIT
| friendly language with naive blocking GC. Rendering pipeline is
| also a mess. Underlying internal datastructures are also very
| naive (which is a good thing when you implement things in C).
|
| Things are slowly changing. emacs now is a lot better than 5
| years. So may be in 10 years it will really rival more modern
| competitors in terms of performance.
|
| Having said all this, emacs universality and extensibility keep
| me with it.
| the_duke wrote:
| This.
|
| I tried to switch to Emacs multiple times, but the lagginess in
| a non-trivial setup just kills me.
|
| I always went back to Neovim.
| throw23948672 wrote:
| I tried to switch to emacs but couldn't find an introductory
| tutorial that was written for mere mortals.
|
| Currently use vim, or things like gedit and kate that come w/
| a DE. I would really like to learn to use emacs, but the last
| so called "beginner" tutorial I tried started with _learn a
| new lisp dialect so you can write emacs extensions_.
| Seriously.
|
| Does anyone know where to find a tutorial that teaches you
| how to do things like open a file, type some stuff, and save
| the file?
|
| Maybe show whitespace change highlighting modes and a few
| hotkeys if I want to get fancy... but like otherwise normal
| beginner stuff?
| ReneFroger wrote:
| Maybe https://emacs.zeef.com might be your friend? There
| are some tutorials listed there for Emacs.
| mplanchard wrote:
| For anything lsp related, this fork by the lsp authors has been
| noticeably snappier and more pleasant to use for me (large rust
| project):
| https://old.reddit.com/r/emacs/comments/ymrkyn/async_nonbloc...
|
| It moves the json rpc stuff to be async, and makes a real
| difference in terms of perceived performance.
| comfypotato wrote:
| Since you mentioned the single-threadedness (and it's relevant
| to the discussion of IDE/Emacs): what's the status of any
| initiative to move Emacs to multiple cores? I'm single, and I
| hope to one day have a family etc.. If I end up staying single
| for long enough, helping move Emacs onto multiple cores is
| something I fantasize about contributing back to the community
| that has helped my life so much.
|
| Does anyone have any input?
| tmtvl wrote:
| Emacs has support for multithreading (threads landed in 26),
| there was an article about the multithreaded model earlier
| this year (https://news.ycombinator.com/item?id=31559818),
| and the Elisp manual has a section on concurrency (section
| "Threads").
|
| If you want to contribute to the future (pun intended) of
| multithreaded Emacs, your best bet may be to make a library
| that adds the nice concurrency facilities that will help
| library authors move to a multithreaded model. An actor
| model, green threads, or supervision trees may be avenues
| worth pursuing.
|
| A big blocker is probably the dynamic binding, but trying to
| "fix" that would break a lot, if not all, of the existing
| libraries.
| medstrom wrote:
| Please DON'T use the threads. As of 2018 it has many data
| races (https://nullprogram.com/blog/2018/05/31/), and
| resultant bugs will be a nightmare to track down.
|
| The Emacs community has always got by through finding other
| ways to ensure responsiveness. It's true that each
| individual user shouldn't have to spend that much time on
| configuration (Doom Emacs and such distros help here), but
| still: people who find it slow must have misconfigured
| something, and on profiling, they'll find at most 1 or 2
| features of their config that's eating all the CPU cycles.
| These won't actually be hard to fix, for a programmer, and
| threads wouldn't have helped matters, and at best only have
| hid the CPU-eater.
| tmtvl wrote:
| Yes, that post was mentioned in the article I linked:
|
| _Even Emacs current threads library suffers from data
| races which is one of the reason I believe it has not
| seen much adoption._
|
| (where _suffers from data races_ is a link to Chris
| Wellons ' post).
|
| The idea now is, as Chris states:
|
| _There really needs to be a safe, high-level API with
| clean thread isolation. Perhaps this higher-level API
| will eventually build on top of the low-level threading
| API._
|
| While you are right that for 99% of standard usage
| single-threaded code is entirely fine, not utilizing
| between half to 15/16ths of potential processing power is
| a bit of a shame, especially considering it means doing
| something like indexing an entire project (yes, we can
| use GNU Global) will require the user to just sit and
| wait.
| medstrom wrote:
| That "99% of standard usage" is the kicker, isn't it? The
| greybeards who opposed multithreading since the beginning
| tend to say that the remaining 1% of use cases is best
| done in an external process, ideally not even written in
| Emacs Lisp, so that Vimmers and the rest of the free
| software community can benefit. The GNU Global you
| mention embodies that ideal exactly.
|
| I suppose if you still want that program to be written
| with Emacs Lisp, you could use async.el
| (https://github.com/jwiegley/emacs-async/) and there's
| finally an use-case for the threads: it'll be relatively
| safe to run those 16 threads only in the external Emacs-
| process.
| comfypotato wrote:
| Thanks for the pleasant surprise of encouraging feedback.
| I'm going to send this comment chain to my email inbox so
| that I can find it later. This is great.
|
| It's such a monumental task to hack on the basics of the
| text editing. I listened to a tts book; I think it was
| titled "The Art of the Text Editor" that delved a bit into
| some of the original philosophy of the text rendering etc.
| in Emacs. You might enjoy it If you ever need a boring book
| to read.
| tmtvl wrote:
| You probably mean _The Craft of Text Editing -or- A
| Cookbook for an Emacs_. I 've skimmed it a bit before and
| it's on my reading list. First I'm still working my way
| through CRLS's _Introduction to Algorithms_ and Aspnes '
| _Notes on Data Structures and Programming Techniques_.
| bloopernova wrote:
| Links to the electronic versions of this out of print
| book: https://www.finseth.com/craft/
| bloopernova wrote:
| Warning, low self-esteem and anxiety ahead:
|
| I really wish I had the capacity and capability to pursue
| this effort. I barely have the energy to be good at shitty
| DevOps and Terraform, writing basic Python and Node is so
| time consuming. I can do some Lisp, but only at the basic
| level of init.el and adapting a few configuration examples.
|
| I do the good thing and donate to the FSF monthly but I
| wish I could donate directly to Emacs because I use it
| every day. Even better would be to sponsor the development
| of a concurrency library and port of major things like
| magit or org.
| chimprich wrote:
| > I wish I could donate directly to Emacs
|
| I've requested this whenever I've had the chance. I would
| be very happy to donate some cash to get core Emacs
| improved. Emacs has made a huge positive difference to my
| professional life for years. Unfortunately this is not
| made easy.
|
| I think one of the issues last time I looked into it was
| that FSF couldn't have donations on a platform that was
| potentially tarnished by having e.g. non-free javascript
| running on it somewhere... All very correct and in tune
| with their mission I'm sure, and part of the reason why
| Emacs etc. has been so successful, but it would be nice
| if they were a bit more pragmatic occasionally.
| db48x wrote:
| Most of what Emacs does just won't benefit from massive
| parallelism. CPUs are ridiculously fast at processing text
| (AVX2 instructions can process vectors of 32 bytes at a
| time), and most of the stuff that _can_ benefit from
| parallelism should just be moved to an external process. For
| example, querying your compiler for a list of methods that
| apply to the current object, or a list of functions that
| start with "Foo" are mostly moving to external processes
| using LSP as the communication protocol. It would be nice for
| some things to use background threads, like Gnus polling your
| IMAP server for email, and Emacs does have the threading
| mechanisms to handle that now. It's just a matter of time
| before someone does the work :)
| the-lazy-guy wrote:
| I disagree. When I am running a compilation (with output
| being dumped into a visible buffer) + query magit for large
| commit. Over tramp. Things noticeably freeze. Technically
| it all is async. Practically, it is implemented as polling
| things on main thread with some witing happening in non-
| async fashion.
|
| > For example, querying your compiler for a list of methods
| that apply to the current object, or a list of functions
| that start with "Foo" are mostly moving to external
| processes using LSP as the communication protocol.
|
| That's why we have lsp-bridge and lsp-mode emacs fork :)
| Both of which build some infrastructure to avoid doing
| communication work with lsp-mode work in main emacs thread.
| So, heavy emacs users are building some async machinery
| which wraps another already async and relatively
| lightweight protocol, because core emacs facilities can't
| keep up with it. Architecturally it is kind of insane.
|
| I think, lsp-mode fork is doing the right thing (from
| practical POV; it goes against "emacs is just an elisp
| interpreter" ideology though) and hope it gets into core at
| some point. A better solution would have being having first
| class async and background threads support at the elisp
| level. Which would never happen due to elisp messiness.
|
| https://github.com/emacs-lsp/emacs
| https://github.com/manateelazycat/lsp-bridge
| comfypotato wrote:
| Hey! Exactly the response I was looking for. Thanks for
| this.
|
| Your response reminded me of an Intel project about regular
| expressions. I think it's called hyperscan, but I'm not
| sure. It's a regex engine (I think that's the correct
| terminology) that makes dedicated use of very specific
| Intel instructions to reach incredible regex speeds on
| Intel processors. Would be cool if Emacs could make use of
| this tech when configured properly. I bet there are some
| internals that rely on regex.
| ykonstant wrote:
| Does emacs use specialized instruction sets like AVX2?
| lallysingh wrote:
| Ha! No. Native compilation just snuck in a little while
| ago. SIMD will take... longer.
| omnicognate wrote:
| The asyncness of Intellij IDEs annoys me at times. I'm used
| (from emacs) to bashing out a series of key combinations in the
| expectation that the effects of one will be complete before the
| next is processed. There are cases in Intellij IDEs (can't
| remember specifics, I'm blissfully back in emacsland and don't
| anticipate using an IDE again in the near future) where that
| can result in the later keypresses being processed before the
| window pops up or whatever from the earlier ones.
|
| Just a minor annoyance, really. It would be nice for emacs to
| improve on the async front, but synchronicity does have its
| benefits when interacting with humans. I sometimes find the
| lack of asynchronous behaviour annoying in emacs, but not very
| often despite using EXWM (so locking up emacs means locking up
| the window manager).
| 29athrowaway wrote:
| You can lower the autocomplete time threshold.
| singron wrote:
| I use IdeaVim on a Mac and I'm 80% sure it reorders
| keystrokes sometimes when I go between normal and insert
| mode.
| pindab0ter wrote:
| I've never had this happen to me. Could you describe what
| happens a bit more clearly? Now I'm curious.
| marcosdumay wrote:
| This is a major annoyance in Visual Studio. You have to stay
| all the time waiting for feedback from the software,
| otherwise your commands will get processed on the wrong
| order.
|
| And yes, autocompletion fires from many different keys, and
| if it misses the keys order, it will automplete into some
| completely different code.
| pabs3 wrote:
| Emacs now has AoT compilation of EmacsLisp, using GCC's JIT
| library:
|
| https://blog.phundrak.com/emacs-29-what-can-we-expect/
| the-lazy-guy wrote:
| This is awesome! I use it since initial "gccemacs"
| announcements.
|
| It is still order of magnitude slower than JS. Dynamic
| binding, ability to redefine or advice any function and
| fundamentally cache-unfriendly core datastructures (cons-
| cells) and absence of JIT hotspot optimization do not help to
| catch up with competition :(
| ragnese wrote:
| Yeah, Emacs's performance isn't really that great when going
| head-to-head as an IDE. Yes, it uses less memory and disk
| cache, but if we're talking about, e.g., working on a large
| Rust project with Emacs+lsp-mode/eglot+rust-analyzer, you're
| going to be in the ballpark of IntelliJ for memory usage, and
| the responsiveness will be nowhere near it. I will say, though,
| that the disk usage will be much less, and that has mattered
| for me on this 256GB disk MBP- between Xcode, Docker, and all
| these package managers for various languages, my disk space has
| become a precious commodity.
|
| I still like Emacs. I prefer free software. I love Magit. But,
| the UI responsiveness is honestly frustrating when using LSP.
| jmount wrote:
| For me Emacs pretty much grinds to a halt if I turn on
| showing line numbers.
| User23 wrote:
| You're probably using the old notoriously slow linum-mode.
| The newer line-number-mode is much snappier.
| TacticalCoder wrote:
| Try to determine which one you're using by running _" M-x
| linum-mode"_ and then _" M-x display-line-numbers-mode"_.
| Note that you can use _both_ at the same time (which would
| make zero sense: it 's only to troubleshoot which one is
| problematic for you).
|
| Do not use linum-mode anymore.
|
| I can display buffers with _hundreds of thousands of lines_
| while showing the line numbers (Emacs 29 / native
| compilation / display-line-numbers-mode / CPU is an AMD
| 3700X with 32 GB of RAM) and Emacs is ultra responsive.
| mort96 wrote:
| This is the kind of thing which infuriates me the most
| about emacs. There are thousands of similar but not
| equivalent ways of doing the same thing, both
| StackOverflow and the emacs wiki contains some (but not
| all, and not the same, and usually not the right, and
| usually contradictory) ways of doing things. And it's
| impossible to figure out which way is the right one
| without asking around in IRC channels.
|
| Why oh why couldn't they improve linenum-mode instead of
| introducing a new mode.
| ParetoOptimal wrote:
| > There are thousands of similar but not equivalent ways
| of doing the same thing, both StackOverflow and the emacs
| wiki contains some
|
| What about the manual?
|
| https://www.gnu.org/software/emacs/manual/html_node/emacs
| /Di...
|
| The issues you described are mostly totally solved by
| looking in the manual first rather than externally.
|
| > Why oh why couldn't they improve linenum-mode instead
| of introducing a new mode.
|
| The double-edged sword of being very backwards
| compatible.
| nverno wrote:
| Doesn't lsp run in a separate process for other editors as
| well? I've only found emacs slow for larger Java projects in
| the past, using eclim, and font-locking very large javascript
| files. But the new lsp-java seems to have cleared that up, and
| I'm not sure what changed w/ javascript-mode, but it also seems
| much faster since a few years ago.
| oblio wrote:
| LSP runs in a separate process, but handling that process is
| synchronous in Emacs, I think. So if LSP is slow for
| something, Emacs will block.
| lallysingh wrote:
| Yes it gives us both a super-predictable queued operations
| model for using emacs, and serial operation in a parallel
| world. Years ago when single core performance was king this
| wasn't an issue, but now we're stuck having to optimize the
| long hot path.
| jonnycomputer wrote:
| The next AMD processor should have an optional Emacs
| dedicated core.
| pjmlp wrote:
| XEmacs was my IDE when UNIX environments didn't offer anything
| better, and most likely Emacs nowadays has implemented most of
| the stuff that XEmacs had going for it over Emacs.
|
| So it was my "IDE" between 1995 - 2005 when working on UNIX,
| muscle memory is still there and I still remember basic elisp
| stuff, yet I see no reason to abandon my IDE's, now that they are
| available everywhere that matters to me.
| logicchains wrote:
| I write C++ professionally and primarily edit code using Emacs
| inside Tmux over ssh, and I've found once you get accustomed to
| it you can be just as productive without any fancy plugins. E.g.
| instead of autocomplete, it only takes a couple seconds to split
| the window, open the other source file in the second pane, jump
| (by text-based search, if you weren't already there) to where the
| definition is, highlight the word and copy-paste it back to the
| first pane. And that way you never have to worry about your
| tooling randomly breaking in template-heavy code, something no
| C++ IDE is safe from. No more moments of frustration when the IDE
| randomly freezes while you're trying to do something important.
| G3rn0ti wrote:
| If you think lsp-mode is too slow you can simulate ,,jump to
| definition" using old-school ,,xref" and ,,etags" that comes
| with your Emacs. It creates a reverse index for you. Then you
| can put that in your git repo and add it to your .gitignore.
|
| Finally, you can press ,,M-." for jump to definition and return
| to your buffer pressing ,,M-," -- if the name of the function
| is unique. In practice, that works good enough most of the
| time.
|
| ,,etags" runs so quickly you can call it from a git hook and
| re-generate the reverse index every time you pull or check out
| a branch.
|
| It works with all languages. No lsp server required.
| marcosdumay wrote:
| Doesn't the language server lisps provide that? (I'm
| postponing installing and learning to use any for years...)
| G3rn0ti wrote:
| Yes, language servers provide that feature, too, and all
| language server clients replace ,,xref" with their own
| implementation. ,,lsp-mode" even provide some gui
| extensions to Emacs so it can display a hover window when
| there are several possible matches for your definition
| (e.g. all overridden methods in your inheritance tree).
| That's quite cool.
|
| But the disadvantage is you now need to run a static
| analyzer in the background parsing half of your code base
| to find definitions. On very large code based this can
| create slow downs.
|
| Furthermore, finding definitions by means of static
| analysis cannot always work, especially so in dynamically
| typed languages or in languages employing generic
| variables.
| ParetoOptimal wrote:
| > instead of autocomplete, it only takes a couple seconds to
| split the window, open the other source file in the second
| pane, jump
|
| It takes less than 0.3 seconds with autocomplete and doesn't
| force a context switch.
|
| Maybe your method isn't a context switch for you, but it very
| much is for me.
|
| Also, if you know the source file to open don't you likely know
| the word making the faster option to just type it?
| yCombLinks wrote:
| I can't tell if this is a joke or not, it sound awful. Further
| it requires already knowing the API, something autocomplete
| aids in learning.
| sidlls wrote:
| Most of the things IDEs provide are unnecessary, and ultimately
| harm the developer by permitting skill atrophy of one sort or
| another. My opinion (obviously, and perhaps controversially).
| There are some exceptions (e.g., because the other tooling is
| garbage, one might consider Visual Studio "necessary" for
| building certain applications on Windows), but not many.
| IshKebab wrote:
| > E.g. instead of autocomplete ... split the window, open the
| other source file in the second pane, jump (by text-based
| search, if you weren't already there) to where the definition
| is, highlight the word and copy-paste it back to the first
| pane.
|
| Just to be clear, are you being serious? I mean this is what I
| do too when autocomplete doesn't work, but it's very obviously
| far inferior to actual autocomplete.
| rahen wrote:
| I thought the title was a joke, until I remembered a second later
| Emacs is now perceived as lightweight. The same Emacs was that
| belittled for its insane memory usage, typically megabytes of
| memory.
|
| I must be an old-timer now.
| medstrom wrote:
| The title also mentions IDEs. Haven't things termed "IDEs"
| always been heavier than Emacs, even back then?
| hyperman1 wrote:
| I recently started using intelliJ's datagrip. For some reason, it
| stores its metadata in xml files, 150Mb or so per database. One
| postgres DB cluster it actually refuses to index unless I select
| only some of the DBs in it. Mind you, these databases are not
| particularly big, e.g. 17GB for the cluster it doesn't want to
| index.
|
| When it starts up, it loads all this metadata in memory. You feel
| the laptop being slow for a minute or so. After that, its mostly
| a good tool. Once in a while, it indexes something and grants you
| another coffee break.
|
| I keep wondering, why XML? If you build this much metadata,
| wouldn't it make a lot more sense to store it in a database
| itself, and only load what you need from it? Say sqlite or h2 or
| something.
| cerved wrote:
| DataGrip isn't perfect but it's radically changed how I work
| with SQL. It makes writing queries so incredibly easy, with a
| god mode autocomplete. JOINs are so easy <3
|
| Does anyone knows of vim or emacs plugins that do similar heavy
| lifting? Preferably decent at T-SQL
| bayindirh wrote:
| My guess it started relatively small, and more features added
| over time to the feature, and they never thought changing about
| the XML part.
|
| Another thing is, XML can be converted to objects and vice-
| versa relatively easily, so it _is_ a neat serialization format
| in nature.
|
| Also, parsing XML fast is a solved problem for the most part.
|
| I have worked with relatively big XML files, and when done
| right, the path is not heavy, at all.
|
| Edit: Oh, Considering this is IntelliJ and Java talks XML
| natively, this might also played a role in this being XML.
| hyperman1 wrote:
| Not complaining about the xml vs json vs yaml vs csv thing.
| It's more that when you choose XML, you've chosen streaming
| and reading it completely. There is no way to read it
| partially and only use the little bit needed.
| bayesian_horse wrote:
| My space suit is too heavy so I moved into my bathing suit.
| gpderetta wrote:
| Well, the bathing suit comes with rockets and you can bathe in
| lava though.
|
| And a kitchen sink. Can't forget the kitchen sink.
|
| You might need to jerry rig the life support system though.
| jlengrand wrote:
| I absolutely love Kotlin (and I do like the folks behind
| Jetbrains), so I'm kinda de facto locked onto IntelliJ but damn
| that post is right in the feels.
|
| Yesterday, I had to let go of my 4K screen and go back to working
| on the laptop screen of my 1 year old M1 because of some issue
| that is open for 7 years
| (https://twitter.com/jlengrand/status/1601246555066859520).
|
| Back then, I upgraded my laptop because the indexing of semi-
| large projects was making me go bonkers.
|
| Sometimes, it does feel like my DevEx is getting worse over time.
| Not better
| dotancohen wrote:
| Emacs people: How well does Emacs manage many files being open in
| disparate directories? I've often got two dozen files open as I
| navigate source code of a new codebase, and my current IDE
| (Jetbrains) does not have a good way of organizing the tabs so
| that I can quickly find them by module (not filename).
|
| For instance, consider the following open files:
| projectRoot/beatles/foo/bar/alice/bob/charlie/a.c
| projectRoot/beatles/foo/bar/alice/bob/charlie/b.c
| projectRoot/beatles/foo/somethingElse/UI/keyboard/usbSupport.c
| projectRoot/stones/mick.c projectRoot/stones/bass/dick.c
| projectRoot/stones/bass/ricky.c
|
| I'd like a single "view" (whatever that may be. In Jetbrains it's
| a tab bar, in VIM it's an ASCII list) to see all the files, but
| collected into "groups". So the files in the
| `projectRoot/beatles/foo/bar/alice/` group are all together, the
| files in the `projectRoot/beatles/foo/somethingElse/` group are
| all together, and the files in the `projectRoot/stones/` group
| are all together. All other files would be in a separate "group"
| visually.
|
| Notice that each "group" is _not_ a child of a single parent
| directory. I would define these groups manually - each project
| only has a handful of groups that I need. This is the feature
| request for Jetbrains, with each group defined as a Jetbrains
| "scope":
|
| https://youtrack.jetbrains.com/issue/WI-61955/Tab-bar-row-pe...
|
| Any ideas for how to handle this situation in Emacs would be much
| appreciated. I've begun using Emacs for org-mode (with Evil) and
| I'd love to actually develop in Emacs if it has really good
| groupings of files.
| teddyh wrote:
| It seems that by default, Emacs wants to treat what it calls
| "projects" as files having a common root directory:
|
| https://www.gnu.org/software/emacs/manual/html_node/emacs/Pr...
|
| https://www.gnu.org/software/emacs/manual/html_node/emacs/ED...
|
| There are, however, a fairly large number of third-party
| packages12 which seem to be for project management, but I have
| not tried any of them.
|
| 1. https://elpa.gnu.org/packages/
|
| 2. https://stable.melpa.org/#/?q=project
| dotancohen wrote:
| > Emacs wants to treat what it calls "projects" as files
| having a common root directory
|
| Yes, I am using that terminology. I'm not looking for project
| management, rather, I'm looking for a better listing of open
| files.
| ParetoOptimal wrote:
| ibuffer sorting by filename?
|
| Also alphapapa has something related...
|
| Ah yes, bufler.el:
|
| > A butler for your buffers. Group buffers into workspaces with
| programmable rules, and easily switch to and manipulate them.
|
| https://github.com/alphapapa/bufler.el
| dotancohen wrote:
| This looks terrific, thank you! I'll go over it this weekend.
| ParetoOptimal wrote:
| Great! I'm still just using ibuffer, but will reach for
| Butler as soon as I need custom rules.
|
| Then again, maybe sooner for tab bar support...
| G3rn0ti wrote:
| It sounds a bit like you want ,,perspective.el" (1). It allows
| you to define ,,virtual workspaces" of buffers with individual
| window layouts. On each virtual desktop the standard buffer
| list is replaced with a shorter showing only buffers belonging
| to the current context. I use it every day to keep ,,code"
| buffers separate from my ,,test" buffers.
|
| (1) https://github.com/nex3/perspective-el
| dotancohen wrote:
| Thank you very much, I will go over perspective-el this
| weekend.
| hadrien01 wrote:
| I don't know the impact on battery, but there's a Power Save mode
| in Jetbrains IDEs that makes the IDE slightly snappier, when you
| just want to read some code or do one or two modifications.
| jansan wrote:
| What really irritates me about IntelliJ is the terminal (on
| Windows). It is slow as molasses (can be down to two characters
| per second), and sometimes typing occurs not at the prompt, but a
| few lines above. How can something like a terminal be that
| broken? And there were a ton of issue reports in the past, so I
| don't even bother to write another issue report.
|
| I finally found that disabling "Typeahead" in Advanced Settings
| seems to help quite a bit so I will stick with IntelliJ, because
| I quite like it aside from the terminal. But I was ready to jump
| ship a short while ago (because of the performance of the
| terminal, can you even imagine?).
| gnramires wrote:
| I highly recommend the Geany IDE as well, it's very simple and
| lightweight, but still has conveniences like an integrated
| terminal if you like, automatic state saving, etc. Best IDE in my
| humble opinion!
| WesSouza wrote:
| Cooking is too complicated so I'm back to hunting and gathering.
| buescher wrote:
| Ordering takeout is too complicated, and they always botch my
| special orders, so I'm remodeling my kitchen. Again.
| Sohcahtoa82 wrote:
| > Jetbrains is working on Fleet, a new, lighter editor from
| JetBrains, and while it seems very promising (it's quite pretty,
| well thought out, modern)
|
| Heh, these days I'd consider a program advertising a "modern"
| UI/UX to be a bug, not a feature. Current trends of making
| everything flat and hiding functionality sucks.
| nucatus wrote:
| Submitted a bug report regarding poor performance like 2 years
| ago and they are still "looking" into it. I guess the shiny look
| has priority over performance for them.
|
| https://youtrack.jetbrains.com/issue/IDEA-270042/High-CPU-us...
| 5e92cb50239222b wrote:
| They definitely don't seem to care about performance or bugs
| very much, but it should be noted that the latest version
| starts up much faster even from cold storage. I used to look at
| the splash screen for ~8-10 seconds, but not anymore. It was
| the first significant performance improvement in a _very_ long
| time.
|
| Other than that, I agree with you. In addition to well-known
| performance issues and longstanding bugs, I'm also still
| waiting for features like full Wayland support that was
| promised by the end of 2020. I mean, I understand it's not on
| their highest priority, but why promise things you're not
| actively working on?
| rhdunn wrote:
| I'd suspect that it is a combination of the following:
|
| a) a lot of existing code that needs to be untangled (e.g.
| moving various tasks to not depend on indices);
|
| b) figuring out how to avoid unnecessary re-indexing (e.g.
| the downoadable index caches for things like Java files);
|
| c) having to define a migration path to spread out breaking
| changes to give plugins enough time to adapt.
|
| IIUC, some of the performance work with the latest version is
| due to parallelizing the various background processes, which
| uses coroutines, so you could add "implementing language,
| library, and tooling support to Kotlin/Java" to that list.
| ergonaught wrote:
| I assume I'll use emacs as long as I continue to use computers,
| and it's been decades since I thought editors really should be
| written in assembler, but this:
|
| "I use an underpowered MacBook Air from around 2019"
|
| and this:
|
| "Mac M1 with 64GB of RAM and 10 CPU cores, everything feels
| lightweight"
|
| are insane sentiments to express, and it's an insane world that
| makes those thoughts seem agreeable to anyone.
|
| There is zero justification to consider a 2019 Air "underpowered"
| for this task. There is zero justification to consider that of
| course one needs an obscenely powerful portable supercomputer for
| this task.
|
| IDEs do a lot. They do NOT do enough to justify this insanity.
|
| I'm sure there's an element of people not knowing what's been
| lost, and an element of people not understanding just how
| inconceivably fast computers are today, but it's hard to wrap the
| brain around anyone tolerating this (as customers, as purchasers,
| as users).
|
| Perhaps the same sort of jaw-drop that occurs when someone takes
| a naive python app to go or rust and discovers that python is in
| fact actually really slow (whether or not it's "fast enough")?
|
| Get off my porch, whippersnappers, etc etc.
| davidf18 wrote:
| 0x4d464d48 wrote:
| "Get off my porch, whippersnappers, etc etc."
|
| I'm only in my early 30's and share this sentiment already.
|
| Tech sure moves fast...
| manmal wrote:
| Well a modern IDE does way more than an IDE 10 years ago. E.g.
| I expect full text search that is pretty much instant. I
| remember times when a full search took multiple seconds to
| complete. Compilers for heavily typed languages are constantly
| re-compiling my code while I'm typing. Decent autocompletion
| has to perform tasks that are usually only required of a
| compiler. Code comments are converted into formatted
| documentation instantly, always available when I look for it.
| Device and build processes are monitored, git status is kept up
| to date, etc etc
| roperj wrote:
| > Well a modern IDE does way more than an IDE 10 years ago.
|
| Really? Like what? What types of refactoring, indexing and
| completion features does IntelliJ have that it didn't in
| 2013?
| manmal wrote:
| Here's a current changelog, looks like quite a few CPU
| eating features have been added:
| https://www.jetbrains.com/idea/whatsnew/
| roperj wrote:
| I don't see what you're talking about. A bunch claim to
| be performance improvements - there are some additional
| features for language plugins that are similar to those
| that have already exist for other languages such as
| better completion (a language plugin
| completion/refactoring features shouldn't be eating much
| CPU if that's not the active file one is working with). A
| few more Java inspections, some Spring and Kotlin
| niceties, etc. All incremental. Most of these should not
| be terribly CPU eating with the existing infrastructure.
| Search Everywhere and Find Usages at their core have been
| there far longer than a decade.
|
| Seriously what is this major new infrastructural
| component in the past 10 years? One could argue these AI
| code things, but they're mostly cloud.
| manmal wrote:
| I never wrote about new infrastructural components, you
| argued yourself into that corner. I wanted to express
| that IDEs have grown way more complex and capable, and
| that this added capability might explain why modern
| systems are needed to get a snappy experience out of
| them.
| roperj wrote:
| I'm saying the complexity of IDEs such as IntelliJ is
| concentrated in their base infrastructure of indexing and
| refactoring engine and that hasn't changed all that much
| in the past decade. That there are more and more new
| language plugins and some nice UX features built on this
| core do not reflect some major new complexity in the past
| decade.
|
| New language plugins and some incremental features that
| usually only cost when you use them have been added
| continuously for years.
|
| IntelliJ was already capable in 2010. Your initial
| example was about fast global search - a feature
| available for more than 10 years.
| anthonyskipper wrote:
| The best answer to this is look at the VS Code ecosystem
| (as Intellij is niche by a small number of developers). In
| that ecosystem you will have all kinds of plugins from
| things watching and notifiying you about pipeline status to
| things like DVC, etc that allow things that you couldn't
| do, at least not without severe side effects back in 2013.
| spullara wrote:
| The best thing to do is not look to the people
| reinventing the wheel. There are tons of new features in
| IntelliJ since 2013 including support for things like Go
| and Rust.
| [deleted]
| yrgulation wrote:
| A modern IDE does nearly all the ai hype hopes to achieve,
| minus code completion. It reviews code, auto completes,
| hints good practice, searched code real fast, etc.
| roperj wrote:
| IntelliJ was doing all that 10 years ago.
| jjfoooo5 wrote:
| The target market is enterprise. If I showed up for my first
| day of work and they handed me a 2019 MacBook Air I'd be pretty
| unhappy.
|
| I really don't get this attitude of indignation when a powerful
| machine's resources are fully utilized. What else are you doing
| with with that computing power? There's not some finite pool of
| computing power we are depleting here, they are figuring out
| how to make more all the time!
| sowbug wrote:
| It's your right as a consumer to have a pro-consumption
| attitude, because you're spending your own money. Be thrifty.
| Be profligate. You choose.
|
| But having it as a developer is a different matter. That
| "powerful machine's resources" aren't yours. They belong to
| your customer, and it isn't your business what your customer
| is doing with the computing power your program isn't using.
|
| Writing programs that demand more resources than necessary
| forces people to discard and replace otherwise perfectly good
| computers. Which, again, you as the developer don't have to
| pay for.
|
| If tragedies of the commons don't bug you, then none of this
| matters. But if they do, then imagine millions of people
| ordering millions of cardboard boxes from Amazon containing
| millions of sticks of DRAM to run that O(n^4) loop that
| you're about to check in.
| spac wrote:
| Equality of access to compute around the world could be a
| principle pointing towards doing more with less.
| malwrar wrote:
| The problem isn't that people are hogging all the CPU, the
| problem is that it's hard to get computers to people around
| the world, connect them to infrastructure (power,
| internet), and train people to use them. Plenty of smart
| people have actively tried to solve this problem and have
| failed. I'm not sure if adopting such a principle means
| anything whatsoever in the face of what appears to be a
| larger challenge than providing computing power to a
| willing yet deprived population.
| asmor wrote:
| The 2019 Air is underpowered (1.6 GHz Dual-Core, 7W TDP[1])
| even when comparing it to more affordable hardware from
| 2019 or secondary market business laptops from the prior 5
| years or so.
|
| [1]: https://www.intel.com/content/www/us/en/products/sku/1
| 89912/...
| cmiles74 wrote:
| MacOS is probably not helping that 2019 MacBook Air feel
| responsive. I have a Dell that's a little older than that
| running Linux and it doesn't feel slow or sluggish.
| medo-bear wrote:
| wow when i read that, i thought the op said "MacBook Air from
| around 2009". i have the same M1 laptop and do not consider it
| underpowered at all !
| graycat wrote:
| > ... apparently, writing code on anything other than top-of-the-
| line machines is too much to ask for.
|
| You guys are way ahead of me, so I need to learn. E.g., I'm
| missing the need for "top of the line".
|
| For my Web site startup, I typed in 100,000 lines of text, 24,000
| programming language statements, in Microsoft's Visual Basic .NET
| using an old desktop computer with a processor with a single core
| with a with a 1.8 GHz clock, Windows XP, SQL Server, calling
| LINPACK via Microsoft's _platform invoke_ , and the editor KEDIT
| (with ~100 macros I wrote) with command line commands in ~100
| Rexx scripts I wrote.
|
| Once I got past some documentation frustrations, I was thrilled
| with all of it: I typed in code using KEdit, compiled it using a
| Rexx script, then used another Rexx script to run it, e.g., to
| run the Web site _locally_ , i.e., with IP address 10.0.0.177.
|
| I thought that the compiling was fast, nicely fast, really,
| blindingly fast. For the code to start running and the Web site
| to be functioning -- again blindingly fast. I was thrilled.
|
| Something went wrong, apparently with the motherboard, and I got
| an HP laptop with a 2 core processor and a 2.5 GHz clock to use
| while I plugged together a desktop with an 8 core processor and a
| 4.0 GHz clock. Then compiling the code and running it were faster
| than blindingly fast, nearly too fast to get finger off the Enter
| key.
|
| I've considered moving to Emacs instead of KEdit and to Power
| Shell instead of Rexx, but so far I've not seen anything like
|
| > ... apparently, writing code on anything other than top-of-the-
| line machines is too much to ask for.
|
| What am I missing? Maybe I'm missing some big things an IDE
| (integrated development environment) would do for me?
|
| I've been delayed by collecting data, etc., but am getting back
| to code writing and running so would like to know what I'm
| missing?
|
| In simple terms, I see programming as just typing in text and
| like KEdit, and my macros, for that. Then for the compiling,
| _building_ , just run the compiler -- it runs right away.
| projektfu wrote:
| Does KEdit do symbol completion, show you documentation as you
| type, and perform automated refactoring? Those are the big wins
| for the heavyweight editors. Especially when working with a
| verbose language like Java or C#, editor support is very nice.
| Also, in languages without keyword arguments, seeing the
| correct order of arguments as you type is very helpful, as well
| as seeing a docstring to confirm that your unreliable brain
| picked the right function.
| graycat wrote:
| > Does KEdit do symbol completion, show you documentation as
| you type, and perform automated refactoring?
|
| KEdit is not specific to software development but is for
| nearly all typing. E.g., I also use it for word processing,
| reading/writing email, notes on everything, Internet content
| on finance, BBQ, coconut cream pie, Moo Shu Pork, ....
|
| So, for writing software using KEdit, need some _more_ : It
| has a good macro language, so can write macros to do some
| work specific to software.
|
| > symbol completion
|
| Interesting question! I do some of that with command line
| commands in text console windows. E.g., in _walking_ in the
| file system directory tree, I have a little Rexx script
| dn 'argument'
|
| where 'argument' is a string, maybe the first few characters
| of the name of a subdirectory of the _current_ directory. If
| the _completion_ is ambiguous, then the script writes out a
| list to pick from.
|
| I just checked the KEdit Help: So, in the case of an
| ambiguous completion, in a macro can use the command POPUP to
| create and display such a window and in it have a menu the
| user can pick from with either mouse or keyboard, and then
| the selection is returned to the macro. So, then, need the
| macro to know what the legal _completions_ are: Okay, might
| get those from the current file being edited. Or maybe the
| list is in the macro or in a file the macro would read, maybe
| that file particular to the current directory of if there is
| no such file then, ... be as fancy as want with a _hierarchy_
| of files of the legal completions, one for C code, one for
| cooking, one for .... Depend on file system caching to make
| the file reading fast. And have the macro use the KEdit
| locate command which is really fast. The user 's string might
| be from the start of the keyword, anywhere in the keyword
| spelling, after some spell checking in the macro, as fancy as
| want!
|
| > show you documentation as you type
|
| My approach to that was to put tree names of documentation
| files in the comments in my source code. Then I wrote a
| little KEdit macro that would, assuming simple syntax, grab
| the tree name and display the file. If the file type was HTM,
| then the macro would invoke Firefox to display the HTM file.
| I have 500+ of those. The file might be just simple text, and
| then the macro would open the file and have it in the _ring_
| (collection) of files KEdit was working with when it ran the
| macro.
|
| > perform automated refactoring
|
| I'll have to guess what that is: Maybe it is changing some
| name from, e.g., call_sql
|
| to call_sql001
|
| For things like that, I just use versions of the KEdit
| command to locate a string. Here the command would be one of
| /call_sql/ >call_sql> l/call_sql/
| all/call_sql/
|
| etc.
|
| Could write a macro, pass as an argument the strings
| call_sql call_sql001
|
| and have a loop for a little _dialog_ that would locate the
| first argument, thus show the context, permit change or not,
| and then _loop_ for the next change candidate.
|
| Of course, if the work is really simple, then could just use
| c/call_sql/call_sql001/ * *
|
| for make the change on all the lines and all cases on each
| line.
|
| In short, KEdit has a lot of good functions and a good macro
| language.
|
| And for the start of this thread about needing high end
| processors, I've been using versions of KEdit back to VM/CMS
| and PC/DOS. So, it's small and fast.
|
| KEdit is a PC version of IBM's XEDIT written in France by
| some guy on his own time. Once it was on IBM's internal
| network, it spread to IBM sites around the world quickly. In
| a word, KEdit is _elegant_. It is my most heavily used tool.
|
| The KEdit macro language is a version of Rexx, the scripting
| language developed by an IBM guy Mike Cowlishaw. Early on
| KEdit macros could be written in Rexx and run on the instance
| of Rexx that served text window command lines, but eventually
| some operating system changes blocked that, and the author of
| KEdit wrote a version of Rexx and included it in KEdit.
|
| Emacs may be a more powerful editor.
|
| Power Shell may be a more powerful way to write scripts.
| projektfu wrote:
| Refactoring is anything that simplifies the code and
| prepares it for modification. For example, extracting a
| function, or a variable; pulling code up to the superclass
| because it's common or pushing it down to subclasses
| because it shouldn't be common; etc. Renaming is a part of
| refactoring but most refactorings involve code motion.
|
| KEdit sounds pretty scriptable, but it seems limited by
| treating everything as text and not being aware of syntax.
|
| I do most of my work myself in Emacs without much of the
| "heavyweight" stuff. Nonetheless, for writing Java or
| exploring a large program, an editor that has already
| grokked and indexed everything is really useful. As an
| example, I can point to a name and go to its definition
| immediately, without running a more generic search. Then I
| can enumerate its uses and see what the idiomatic use is.
|
| Not trying to convince you to use something else, just
| giving you an idea why people like these tools.
| graycat wrote:
| I do a little with _objects_ but not a lot. Doubt that I
| ever wanted to _refactor_ some! Yes, some of my code
| _editing, revisions_ involved _code motion_ , but I don't
| recall that was a big problem.
|
| > KEdit sounds pretty scriptable, but it seems limited by
| treating everything as text and not being aware of
| syntax.
|
| Right. To have KEdit honor syntax, would have to program
| that in the KEdit macro language. No doubt that is
| doable, and since the macro language has a lot on string
| handling quite doable. Doable but for me more work than
| worthwhile.
|
| KEdit is old but so is Emacs.
|
| > Not trying to convince you to use something else, just
| giving you an idea why people like these tools.
|
| Thanks, I've been wondering what I'm missing not using
| Emacs.
|
| For an IDE, once I looked at Microsoft's Visual Studio.
| Created a _project_ or whatever it was called -- years
| ago. It created a directory with lots of files. And that
| was before even "Hello World". I didn't know what all
| those files were for, didn't want to go to the trouble to
| find out, and was concerned that if something went wrong
| I'd have to fix it. I gave up, but here with the start of
| this thread wondered what value I might be missing from
| some heavy computing busy trying to make my work easier
| -- what was it, 12 cores, 64 GB of main memory, gads?
|
| So, for now, stay with KEdit and Rexx.
|
| I could have wasted time evaluating IDEs. Thanks!
| flumpcakes wrote:
| I don't use IDEs at all. The features I see that I think
| "that's nice" are:
|
| * Integrated with the build system (shows lines that fail the
| build etc.)
|
| * Integrated with the debugger (mark lines to stop at, follow
| the lines)
|
| * Integrated with a language server (highlighting, style
| errors, help, "IntelliSense")
|
| * Automated Refactoring (rename variable, function, class, and
| it's updated everywhere)
|
| * Integrated source control (git, etc.)
|
| * Inline documentation as well as autocomplete.
|
| Things I haven't seen but seem like natural progressions:
|
| * Integrated CI/CD: deploy straight from your IDE, view
| pipeline outputs
|
| * Production/remote debugging: connect to running processes
| non-destructively to find memory leaks, etc.
|
| To be honest, you sound perfectly productive without an "IDE".
| If everyone has a set of tools they are comfortable with I
| don't see why that isn't as good as a singular IDE. Then again,
| as I said, I don't use IDEs at all...
| tomerbd wrote:
| Checkout also https://github.com/AstroNvim/AstroNvim
| gavi wrote:
| I noticed that I focussed more when my Mac terminal was full
| screen and only using vi to learn rust with almost no plugins. It
| forced me to reason about the borrow checker before cargo build.
| I still use vscode for debugging once in a while, but I think it
| improved my understanding of the language and also prevented me
| from getting distracted.
| [deleted]
| hannofcart wrote:
| I've never understood why developers look to be _tied_ to a
| single IDE/editor. I also don't get the obsession that some of us
| have with our IDEs.
|
| What's with the "I am moving to editor X...". You don't have to
| give up one editor to use another. You can use whichever may be
| convenient for a given situation.
|
| I use several editors/IDEs based on whatever the
| language/ecosystem/task at hand is.
|
| Quickly editing a config file? I just use a barebones vim or
| Sublime Text.
|
| Writing some quick Python/Rust code, I use nvim with plugins.
|
| Writing some SQL: I spin up DBeaver.
|
| When I want to do extensive refactoring or step debugging in
| Java/Rust/Python: I open a Jetbrains flavour: Jetbrains
| vanilla/PyCharm/CLion.
|
| IDE at work containing a mix of JS+TS frontends and
| Go+Python+Rust services: VSCode (it's a nice general purpose
| workhorse).
|
| I guess the secret sauce to all this is that I have vim shortcuts
| configured everywhere, so the transitions are easy.
|
| I don't see a reason to be monogamous to one IDE/editor :)
| worthless-trash wrote:
| > I don't see a reason to be monogamous to one IDE/editor :)
|
| Years of muscle memory.
| TrickyRick wrote:
| Today you can usually customize everything anyway. And if you
| just want the default setup from another editor there's
| probably a plugin for that. I remember when moving from
| Eclipse to IntelliJ a long time ago I brought some of the
| most commonly used shortcuts into IntelliJ. I then later
| moved those with me to VSCode and still use them today, took
| me a maximum of 30 min to configure ONCE so I really don't
| understand the author's reluctance to configure that in a new
| IDE.
| layer8 wrote:
| Nah, when I tried to switch from NetBeans to IntelliJ,
| there were too many things that just couldn't be set up the
| way I was used to operating NetBeans, from window/panel
| handling to keyboard navigation and code-template
| expansion. I would have had to write a number of plugins
| myself.
| markus_zhang wrote:
| TBH nowadays I give up learning either emacs and vim, it's just
| too much time to replicate the experience in Jetbrain editors.
| I'd just throw in an extra thousand and buy something more
| powerful, like a 16g m1 macbook pro. Time is precious.
| ParetoOptimal wrote:
| > too much time to replicate the experience in Jetbrain editors
|
| That's not what most emacs or vim users are trying to do?
| markus_zhang wrote:
| Or I should say same smoothness? I think experience is a
| better word.
| FpUser wrote:
| My "least powerful" laptop that I still use for development is
| ASUS TUF A15. With Ryzen 7 4800H CPU. 8 Cores 16 threads. I
| bought it recently dirt cheap for $799 Canadian (translates to
| $586US approximately). Stuffed it with 64GB RAM (I had it lying
| around but it is cheap anyways).
|
| I run CLion from JetBrains on it for my C++ development. When
| doing full rebuild of the project and libs (all cores at 100%)
| the fan comes on but not really loud and goes back to sleep for
| the rest of the development. Building itself is really fast.
|
| Not sure why you have such poor experience. Maybe those thin
| laptops can't really handle CPU loads without overheating.
| schipplock wrote:
| We still have many Thinkpad T490 with Intel Core i7 and 40GB
| Ram. They overheat and throttle gpu and cpu to the point you
| can't work anymore. Even the mouse comes to a halt. The fan
| barely spins up. Absolutely rubbish.
|
| Then we have Thinkpad P15v2 Gen2, also with Core i7, the moment
| you fire up your compiler, the fans spin up immediately (also
| very loud). No throttling, you can compile all day.
|
| At home I have a Thinkpad Ryzen laptop, no fan noise, no
| throttling, full power. It's just a different kind.
| FpUser wrote:
| I guess the recipe is - do your homework and do not buy crap
| but that is what many corporations do for their employees.
| Their laptops cost way more than the one I mentioned and are
| still slow.
| ColonelPhantom wrote:
| That's some crazy powerful hardware, and would be a significant
| upgrade for most people.
|
| My main and only laptop (apart from some ancient ones) has a
| quadcore i5-8350U and 8GB RAM. (I kind of want to upgrade its
| RAM though)
|
| I also have a PC, that I upgraded to a Ryzen 7 5800 and 32GB
| RAM recently, but a few months ago it was an i7-4790K with 8GB
| RAM.
|
| Sure, 8GB RAM is quite little, but it's still within the
| mainstream. In laptops quad-core CPUs also only became
| mainstream in the last few years, let alone more than that.
|
| FWIW, I don't have any real performance issues with Jetbrains
| IDEs on either of my machines, but I don't use them much either
| as I don't like the convoluted user interface.
| FpUser wrote:
| >"That's some crazy powerful hardware, and would be a
| significant upgrade for most people."
|
| I have my own company. Cost of this laptop goes as a business
| expense and is peanuts comparatively to revenue.
|
| >"Sure, 8GB RAM is quite little, but it's still within the
| mainstream."
|
| I've never cared about mainstream. Not in the industry and
| neither in private life. I do what works for me / my company
| and could not care less about what others do.
| spapas82 wrote:
| I also find intellij idea (and friends) too heavy. I am using it
| only when developing java or kotlin because the experience is
| much better than anything else, despite the slowness.
|
| For anything else (python, js, elixir) I use VSCode with a
| careful selection of plugins. It works very nice even on my
| Thinkpad T420.
|
| I agree with the people that said that if you install a lot of
| plugins (lsp etc) on a bare bones editor it will feel very slow;
| I had exactly this experience using vim on Windows: Using it as a
| text editor with only a few plugins (fzf etc) was great but when
| I started using is more like an IDE the experience wasn't that
| good anymore resulting in choosing VSCode instead.
| dmitriid wrote:
| > For anything else (python, js, elixir) I use VSCode with a
| careful selection of plugins.
|
| I find JetBrains IDEs to be significantly better at Python and
| JS/TS (they do have dedicated IDEs for them after all).
|
| I wish Elixir support wasn't just one guy from Jetbrains
| working on it in spare time though...
| mdaniel wrote:
| > I wish Elixir support wasn't just one guy from Jetbrains
| working on it in spare time though...
|
| Better that than the travesty they did to the intellij-hcl
| plugin, where they .. hired? in-housed? I don't even know
| what they did to that plugin except completely and utterly
| broke it and made updates to it go into this weird black hole
| it wrote:
| Kiss your productivity goodbye. Emacs has lots of half-baked
| features that you'll be tempted to fix with its LISP dialect.
| It's so much fun to tinker that you'll wonder where your day
| went.
|
| The $20 I spend every month on my JetBrains subscription is
| easily worth it. I can depend on my IDE to be working well and
| not waste time on fixing buggy features. The JetBrains people are
| also highly responsive to bug reports.
| RunSet wrote:
| > running the community edition of Jetbrains' IntelliJ IDEA
|
| ...
|
| > As much as it hurts me to say this, as a fan of JetBrains and
| its tools, IntelliJ just seems to have become too heavy to run
| properly on a laptop that's not at the very higher end of laptops
| in the early 2020's.
|
| IntelliJ does what I want, but only barely. The autocompletion
| gets it wrong as much as it gets it right and it is a performance
| _hog_.
|
| I can deal with that.
|
| The problem for me was JetBrains' privacy policy[0]. It is
| loosely-worded enough to forbid them practically nothing, and I
| find that especially appalling in a so-called "community
| edition".
|
| So I began searching for alternatives. Emacs may serve for OP but
| I always forget how to exit it so I wanted something with a
| clickable "close" button in the top right.
|
| I am getting a good initial impression from Codelite[1]. I'm sure
| Codelite doesn't do everything IntelliJ's IDEs do, but it has the
| functionality I use and it is a breath of fresh air after waiting
| for IDEA and the like to catch their breath during text editing.
|
| [0] https://www.jetbrains.com/legal/docs/privacy/third-parties/
|
| [1] https://codelite.org/
| ParetoOptimal wrote:
| > Emacs may serve for OP but I always forget how to exit it so
| I wanted something with a clickable "close" button in the top
| right.
|
| That's the cool part, you don't!
|
| Jokes aside:
|
| - Every emacs install i've ever done had the familiar X at the
| top right to close it. How did you install?
|
| - Related to the joke, running emacs as a server is quite nice
| heurisko wrote:
| > The problem for me was JetBrains' privacy policy[0]. It is
| loosely-worded enough to forbid them practically nothing, and I
| find that especially appalling in a so-called "community
| edition".
|
| What, specifically? Because I can see they are bound by the
| GDPR and it seems clear to me:
|
| > If you install on-premises products such as IDEs or .NET &
| Visual Studio Tools, these products are located on your
| hardware. JetBrains does not provide hosting for these products
| and does not have access to any of your data processed with
| these tools, unless you actively decide to share this data with
| JetBrains.
| vindarel wrote:
| > I wanted something with a clickable "close" button in the top
| right.
|
| c'on! Last time I checked (2 seconds ago), Emacs' GUI has a
| "close" button in the top right. And a "File" menu at the top
| left with a "Quit" entry, that teaches you the shortcut (C-x
| C-c).
|
| Emacs in the terminal (emacs -nw) doesn't have the top right
| button but still has the menu. We can't click it by default
| though. Use: F10, or M-x menu-bar-open, or M-x xterm-mouse-mode
| and click on it.
| https://www.gnu.org/software/emacs/manual/html_node/emacs/Te...
| heurisko wrote:
| Something I recently missed emacs for, was being able to use it
| to transparent edit a file over SSH.
|
| I couldn't find an easy way to do that with IntelliJ/phpstorm.
| 29athrowaway wrote:
| 1. Disable unused plugins
|
| 2. Exclude folders from indexing
|
| 3. Tune the JVM
|
| It is less work than tuning emacs.
| deliriumchn wrote:
| > The shortcuts are just unergonomic in my opinion
|
| Extensions -> type "emacs" -> done
|
| I really hate this articles that scream "look I'm so old school I
| use vim/emacs" while emacs is a single threaded nightmare that
| will work worse than any IDE if you will try to configure it to
| make it usable for actual every day work.
| worthless-trash wrote:
| Many, many people use emacs and vim for everyday coding. You
| sound confident, but you'd also be wrong for a large swath of
| programmers.
| jmclnx wrote:
| > (funny, because at the time it was created it was considered a
| heavyweight... how things change)
|
| No kidding, but I remember in the early days, when people
| complained, RMS said something like "the hardware will catch up".
|
| Seems he was right :)
| roland35 wrote:
| IntelliJ also has a "Power Save" mode if you want to disable a
| lot of the background stuff while on battery.
|
| The reality is, with large projects there is a lot of crunching
| going on in the background. Laptops tend to reduce their
| processing power when on battery, so a few options are:
|
| - use a dev server! I have a desktop at home I can use - a cheap
| desktop is much better than a cheap laptop. Or rent an on-demand
| from the cloud. IntelliJ has nice remote development support.
|
| - plug into the wall
|
| - turn off everything non-essential like plugins
|
| - use emacs/vim!
|
| I love vim as much as anybody but now that I am older I don't
| have much time to mess around with configurations. I am learning
| rust and it is great to open up CLion and just get down to
| business.
| ineiti wrote:
| True - nowadays, `Eight Megabytes Always Continuous Swapping` is
| a feature, not a bug...
| fileeditview wrote:
| A long time ago I switched to Emacs(with evil mode) from whatever
| IDEs I was using but it was also way too slow. I then switched to
| vim and configured it with lots of plugins. This was the best
| thing ever. I transitioned to Neovim but Vim would also be OK.
|
| Vim/Neovim are always fast. Even with 30+ plugins configured. I
| can run them on any hardware and they are blazing fast. Not to
| mention the superiority of modal editing if you are used to it. I
| have every feature I need (LSP/code completion/diagnostics/even
| debugging via DAP).
|
| Pretty sure that I won't switch setup for a long time/ever again.
| omaranto wrote:
| Speed definitely depends on use cases. I switched from Vim to
| Emacs because Vim's syntax highlighting in LaTeX files was so
| slow it lagged behind my typing (and I am not a fast typist!).
| This is a well-known problem in Vim and the manual even has a
| section about it (see :help tex-slow). Emacs was perfectly
| snappy for LaTeX and I didn't want to use one editor for LaTeX
| and another for everything else, so I just switched to Emacs
| for everything.
| eloisius wrote:
| Same here except that each year it seems like I shed a plug-in
| that I'm not using anymore. Over the last decade I've been told
| over and over whenever I join a new team that Vim isn't going
| to cut it and I should switch to the current hotness.
| Invariably, I give the new hotness an honest shake and can't
| suffer the productivity hit. My favorite is when someone
| promises me that the "vim bindings" are actually really good.
|
| What I think people don't get is that it's not just Vim. You
| can add hjkl to another editor and it doesn't make a
| difference. The terminal is my IDE. I run vim within tmux side
| by side with a shell, and I'm way faster at grepping for
| something than IntelliJ is at indexing and searching. My editor
| never has a few-second lockup. I never depend on the IDE to
| build my code, so when I work on something there's a
| functioning Makefile or equivalent and it's inherently ready to
| build and test on CI.
|
| I don't care about Vim vs emacs. I'm sure emacs is great if
| you've invested in it like I have vim. But contrary to all the
| IDEs and editors I've been urged to switch to over the last ten
| years, vim is still kicking and I keep getting better with it.
| If I adopted the new hotness every few years that wouldn't be
| the case. You can pry vim from my cold dead fingers.
| oblio wrote:
| What Jetbrains provides, and is quite hard to replicate, is
| the linting and auto-correct suite for
| medium/large/enterprise development teams.
|
| That's actually the main thing, deep and wide integrated
| linting.
|
| Almost everyone does autocompletion (up to a point).
|
| Almost no one does linting as well as they do.
|
| Quick experiment for you.
|
| Take a big source code file you've worked on, preferably
| solo, so you won't have excuses :-p Not a "best case
| scenario" file you've cleaned up and polished. Be honest with
| yourself, something big and reasonably messy where the
| deadline was tight or the issue was complex.
|
| Open the entire project and configure it in a Jetbrains
| product.
|
| Open that specific file in the IDE.
|
| My guess is that the top-right green checkmark won't be
| there.
|
| You just can't hold all that stuff in your head at all times.
|
| That's why we use computers and tools (such as advanced
| IDEs), to remind us of this stuff.
|
| Anyway, in the rare case that you actually do all of that on
| your own, <<you>> are an outlier. 1%, 10%, for sure you're
| not lower than 50% of developers. The majority of developers
| need that help.
| fileeditview wrote:
| For my day job I mostly write Go. There are tons of great
| linters you can use with golangci-lint e.g. which is easy
| to integrate into Vim. I wouldn't see any benefit of using
| Jetbrains here.. maybe it is true for other languages that
| don't have good community linters but I think there are not
| many of these..
| gabrielgio wrote:
| I was about to say that. I used to work with
| python/django and pycharm really does a lot of heavy
| lifting on the autocomplete/linting part. It knows django
| and would autocomplete even django's ORM params (which
| are quite dynamic).
|
| Now I moved to Go, and that is not needed anymore. Most
| thing are already bultin or can easely be extended (like
| with golangci-lint). It's static typed with simple OO
| model which makes things a lot easier. Since then I've
| been working neovim and I don't feel I miss anythig from
| full-featured IDE.
| eloisius wrote:
| That's an expensive experiment to try, so I probably won't
| do it, but what does the green arrow checkmark mean? That
| my code lints? I use Syntastic most of the time, which just
| runs a linter like flake8 and then puts a red arrow next to
| offending lines. It runs every time I save, and I generally
| take its feedback right away because the slight shift to
| the right when the arrows are present nudges me to fix
| them.
|
| Definitely not saying anyone else should use Vim if they
| don't want to, just that Vim is part of my productivity
| superpower and I take offense to it when part of the
| onboarding experience is setting up an IDE and someone
| really pushes it on me.
| oblio wrote:
| Yes, the green checkmars means that the code is lint-free
| (up to a point).
|
| The Jetbrains linters are proprietary, though they can
| integrate Open Source ones, and generally better and more
| thorough than Open Source ones. They're especially better
| for professional development where you use various
| frameworks.
|
| > I take offense to it when part of the onboarding
| experience is setting up an IDE and someone really pushes
| it on me.
|
| That's fine, but being a part of a team sometimes
| requires sacrifices. It's as true in football as it is in
| software engineering :-)
|
| Plus I'm sure reasonable teams just leave you alone if
| you do your job well and your setup doesn't intrude on
| what everyone else is doing.
| fileeditview wrote:
| > That's fine, but being a part of a team sometimes
| requires sacrifices. It's as true in football as it is in
| software engineering :-)
|
| It's only fine if this provides something to the team
| which you could not provide otherwise and in my
| experience this is not the case usually.
| the_duke wrote:
| Many languages have linters and formatters.
|
| That is what you should use. You can't run Intellij IDEs on
| CI to validate the pull request.
|
| That said, I do appreciate the powerful code analysis
| provided by Jetbrains IDEs.
| mdaniel wrote:
| That's the problem Qodana is trying to solve:
| https://www.jetbrains.com/qodana/
| matwood wrote:
| I came across LunarVim not long ago and it helped me go from
| just using neovim for quick edits and editor keybindings to
| going down the path of fully using neovim.
|
| I still use IntelliJ for Java, but for everything else neovim
| is working well. I still have VSCode for a fall back.
| illegalmemory wrote:
| https://spacevim.org/ is also good alternative , it is
| basically vim/neovim sensible plugins pre-configured with
| smaller config file and simpler management.
| xigoi wrote:
| Also see:
|
| https://www.lunarvim.org/
|
| https://nvchad.com/
| agrippanux wrote:
| +1 to LunarVim, I use it daily. It has sensible default
| shortcuts and plugins. I think I have configured maybe 2
| things in the last few years.
| MrMan wrote:
| astrovim is really good as well
| racked wrote:
| Thank you, that's just what I was looking for!
| souvlakee wrote:
| I suggest that everyone go through this journey before using
| Neovim: https://www.chrisatmachine.com (so you can understand
| how and why something works, and also fine-tune your setup).
| Chrisatmachine's setup as for me looks similar to AstroVim.
| fileeditview wrote:
| There are many of these distributions and I recommend them to
| people new to Vim because they can get a good out-of-the-box
| experience.
|
| However after some time you probably want to configure your
| own and only include what you truly need. For this a good
| solution is to just adapt https://github.com/LunarVim/nvim-
| basic-ide to your liking. This is made by the author(s) of
| LunarVim.
| kingkongjaffa wrote:
| Oh this feels like spacemacs I already use evil mode
| spacemacs I think the most important feature is org mode but
| maybe I'll play with spacevim over the holidays!
| cerved wrote:
| Then you couple this with IdeaVim and complement by running
| JetBrains IDEs on the side
| fileeditview wrote:
| This sounds like exactly what I wouldn't do?! I actively stay
| away from IDEs because the are bloated and slow and don't
| offer me personally anything that I am missing in my
| (configured) Vim.
|
| I have used JetBrains in the past and I never was a fan. It
| is very slow and lagy in many situations. If I'd go the "IDE"
| route vscode would be my choice.
| samiam_iam wrote:
| samiam_iam wrote:
| jbverschoor wrote:
| I abandoned JetBrains a long time ago.. too bad, because they
| always have really good language/framework/platform tooling, but
| I just can't stand the IDE. I don't see them just creating a
| language backend for VSCode.
| wiredfool wrote:
| I'd be happier if:
|
| 1) Some random mode couldn't kill M-% search and replace.
| Something somewhere does it in some of my installs.
|
| 2) Magit was reliable on MacOS. On one machine, it's fine. On
| another, I have some random issue with emacs server and therefore
| I'm not able to commit, or do anything where I can edit a message
| buffer.
| bitwize wrote:
| Back in Emacs's heyday, it was the editor everyone was
| complaining about for being too bloated and slow ("Eight Megs And
| Constantly Swapping").
|
| Today, Emacs is a great retro video game, but you will be
| kneecapped if relying on it for serious programming work. For pay
| or otherwise. And if you're like me, you'll become mired in it
| and everything else will seem as a pebble in the shoe. Don't be
| like me.
|
| Using a modern IDE, or IDE-like editor, is a critical developer
| skill because that's where all the tooling and attention is.
| Focus on that and don't attempt to cosplay as an old-school
| wizard by faffing about with things like Emacs.
| ParetoOptimal wrote:
| > Today, Emacs is a great retro video game, but you will be
| kneecapped if relying on it for serious programming work.
|
| I haven't felt like this was true since lsp support matured.
|
| Plus there are big benefits to having the same editor,
| autocompletion, etc while coding that I already use daily with
| org-roam.
| bitwize wrote:
| LSP helps, but even with it Emacs is falling behind. Language
| hackers support Visual Studio Code first these days, with
| extensions that go beyond LSP.
| ParetoOptimal wrote:
| > Language hackers support Visual Studio Code first these
| days, with extensions that go beyond LSP.
|
| Can you give me an example of one?
| bitwize wrote:
| Julia's VSCode extension provides linting, debugging, and
| live interactive development features that go beyond the
| language server:
|
| https://www.julia-vscode.org/
| chimprich wrote:
| I don't agree with this at all. I think a modern, fully-tooled
| up Emacs is significantly more capable overall than e.g.
| VSCode. There's more configuration involved and Emacs lacks
| some features, but that goes both ways.
|
| Compared to my non-Emacs using colleagues I'm significantly
| faster at manipulating code. I don't think that's because I'm
| smarter or intrinsically faster (they're mostly younger, for a
| start). Emacs is just a lot more efficient once you've learnt
| all the tricks and built up a platform that suits your
| preferences.
| soheil wrote:
| I think the cycle repeats itself, there used to be bloat-wares
| like Eclipse (IntelliFuck) that programmers would swear by. Then
| came Sublime and people had a revelation about how light and fast
| an IDE can and should be. Recently there has been another wave of
| hipster programmers swearing by bloat-wares like VSCode.
|
| Now people have to rediscover Emacs from 47 years ago.
| eloisant wrote:
| It's really funny that people see Emacs as an alternative to
| bloatware.
|
| For most of its history, Emacs has been the very definition of
| bloatware.
| tmtvl wrote:
| What do you mean, doesn't every IDE need its own Infocom-
| esque text adventure, psychoanalyst, IRC client, web browser,
| Morse code translator, ASCII art drawing tools, and Tetris
| implementation? Of course all that bloat is an acceptable
| price to pay for the best editor available.
| ris58h wrote:
| Sorry but Sublime isn't an IDE. It's a text editor. Emacs and
| Vim too.
| soheil wrote:
| Anything that does syntax highlighting, jumps to definition
| and allows you to install additional packages/functionality
| is an IDE and everything else that you call an IDE is
| actually bloatware (see, I can do that too.)
|
| No, I don't need to freaking have a goddamn FTP and SSH
| client built into the tool that I so heavily rely on every
| day just because there is a use case for it in someone's
| brain that is orthogonal to the vast majority of its users'.
|
| Also fuck the evil that is Codespaces.
| prmoustache wrote:
| It all depends at which level you configure them in the end.
|
| vanilla emacs/vim with default config are just editors, but
| they can be configured to have most if not all the
| functionnalities of an ide.
| ris58h wrote:
| I agree but people often compare vanilla text editors with
| fully-featured IDEs which doesn't make sense.
| jb1991 wrote:
| The OP would probably find that any IDE works just fine on the
| baseline MacBook Air from the Apple Silicon era. But anything
| older than that is probably going to have problems.
| tiffanyh wrote:
| Slightly off topic: any reviews of Zed or Helix here?
|
| How does it compare?
| omaranto wrote:
| Zed! That's a blast from the distant past! I enjoyed this 1980
| paper about its development:
| https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.43801001...
|
| EDIT: I just saw in my own comment history that I knew (but
| forgot) there is a more recent Zed text editor which is
| probably the one you meant.
| bugeats wrote:
| A couple of months ago I switched from Neovim with a carefully
| crafted config file to Helix with zero config. I haven't looked
| back.
|
| As far a performance, well, Helix + Alacritty is the fastest
| thing I know of. Snappy AF. You're still at the mercy of
| whatever language server might be grinding away, but at least
| it doesn't block the UI in any way. Every other component
| (tree-sitter, ropey) is performance optimized by Rust nerds who
| love that sort of thing.
| mro_name wrote:
| Yes. I have to build small, permacomputing-inspired stuff, so I
| resort to (neo)vim wherever possible.
|
| The complexity of the toolchain tends to sip into the result over
| time.
|
| Conway's law.
| sidlls wrote:
| I love emacs. I don't use an IDE unless I'm forced to, mainly
| because I simply don't use the features most IDEs offer, and have
| considered them bloated nightmares since the first time I used
| one. Emacs has everything you need, and is fast enough, with few
| exceptions. Same for vi(m).
| [deleted]
| etra0 wrote:
| I remember when I was a kid, I wanted to start coding so
| naturally most places mentioned Visual Studio.
|
| I installed it in the hopes to begin something new and
| challenging.
|
| Every time I open Visual Studio, it took an average of 18 minutes
| (yes, I timed it), and it was using my full 2 gigs of ram that I
| had at that time, so the typing experience was even worse.
|
| I wish I was more persistent with the idea of start coding, but a
| heavy IDE was one of the causes my curiosity was killed.
|
| Since that day I have kind of a resentment against big IDEs like
| the ones from Jetbrains and VS, although my PC doesn't struggle
| at all with them nowadays.
|
| I mostly use VIM and it's enough for me.
| indymike wrote:
| I've got an Emacs window open on the top and PyCharm on the
| bottom of the screen. The main story in the IDE for me is first
| class debugger, visual refactoring tools and luxury level
| toolchain integration. The main story in Emacs is org-mode, runs
| almost anywhere, plus, great text editing features (try running a
| macro in the IDE... sometimes I can actually type faster... all
| on a 2022 i7 with 32GB of RAM). I think we're dealing with the
| same problem we do with all development tools: functionality vs.
| performance.
| ThePhysicist wrote:
| I'm still on Sublime Text, after briefly switching to VSCode.
| Unless you're on latest-gen hardware it seems that most feature-
| rich IDEs are just terribly laggy, which drives me nuts. A
| computer just shouldn't need several seconds to load and parse a
| source file even if it has 100.000 lines. Editors like Emacs or
| Vim were always too low-level for me though, Sublime is a nice
| compromise between simplicity and speed.
| mgaunard wrote:
| I tried to switch from Sublime to VSCode as well, and it's
| mostly been a disappointment.
| skerit wrote:
| All the code I work on is hosted on a separate development
| server, so I used to use Sublime to edit these files over the
| network, using NFS.
|
| But now I use code-server, which is hosted on the same
| development server. So everything got a lot faster for me.
| baby wrote:
| Really? I did the switch and there's no way I could go back
| to ST.
| robryan wrote:
| Sublime still feels a bit snappier to me. The ecosystem
| around it has obviously fallen behind a bit now though.
| hit8run wrote:
| Only partially true. The ecosystem has some really
| awesome plugins: - GitSavvy - Sublime-LSP (plus LSP-
| Copilot) - Sublime_Debugger - Terminus
|
| All these together and you have a keyboard driven
| ultrafast IDElike experience.
| jonwinstanley wrote:
| Agreed. I loved Sublime for years but VS Code is now miles
| ahead in my opinion.
| cameroncooper wrote:
| In what ways do you think VS Code is miles ahead? With
| language server and debug adapter plugins, I find ST to
| be a very good replacement for VS Code.
| mtkd wrote:
| I'm in the market for a new IDE as Atom is end of life (prev.
| Sublime)
|
| I tried VSCode and went back to Atom -- it still works fine
| but expecting that won't last
|
| Ideally I really need one where I can run bash sessions in
| tabs alongside code, I don't really use autocomplete and such
| -- but it needs to handle a lot of open large files with zero
| lag and instant search
| _thisdot wrote:
| I switched from Atom to VSCode a while back. Code has
| better extensions and is faster. Only thing that bothered
| me is the missing Git view on right side. But now Code lets
| you have a Primary and Secondary sidebars. I keep Git on
| right side and File Explorer on left side
| bloopernova wrote:
| I moved from Atom to VSCode a few years ago. It's a worthy
| successor, in my opinion.
|
| What were your blockers to moving to VSCode? My remaining
| issue is to be able to css style any element of the UI like
| I could with Atom. There're plugins that let you monkey
| patch to get that feature, but updates to VSCode break
| them.
| hibbelig wrote:
| I think Pulsar might be interesting: https://pulsar-
| edit.dev/
|
| I understand these are some folks trying to keep Atom
| alive.
| prmoustache wrote:
| >Ideally I really need one where I can run bash sessions in
| tabs alongside code,
|
| Wouldn't it easily be solved if people were actually using
| decent desktop environment or take the time to configure it
| correctly?
|
| I mean it is not complicated to move from ide to terminal
| if the desktop and shortcuts are well made.
| blackoil wrote:
| Vscode now allows terminal to be in editor area along with
| files.
| PurpleRamen wrote:
| > A computer just shouldn't need several seconds to load and
| parse a source file even if it has 100.000 lines.
|
| Why? It doesn't just load the file, but also analyze it, find
| flaws and put it into a bigger picture which assists the user.
| And you don't need a last gen for this. I work on a 10 year old
| machine quite fine with a rather heavy IDE-Setup. Just accept
| that a computer can be your partner, helping you to reach your
| goal, and that he needs his time for doing his work too.
| throwaway2037 wrote:
| I love these weird, artificial "no true Scotsman" arguments
| that appear on HN when people are discussing little more than
| the colour of the bike shed. "Oh, but how does it do with
| 100k lines?" I can already tell you from my lovely, bloated
| IDE: Terrible. And, I don't care. Why? WTF is this file 100k
| lines!?
| PurpleRamen wrote:
| I know at my workplace, the vim&emacs-users are the reason
| for the codesinks here. They have no relevant penalty for
| growing everything in singles files, but they have some
| benefit as they can navigate code better with a poor setup.
| And at some point, reasons like "not destroying the git-
| history" and such are added to the list. And laziness might
| be another reason on that list.
| zelphirkalt wrote:
| Because your are not viewing those 100k lines at once ever.
| Taking that into consideration, enormous optimizations are
| possible.
| PurpleRamen wrote:
| The lines are all interconnected. Whether you view them or
| not, they still influence each in some way or another. And
| figuring this out is the hard part in coding and software-
| design, which the computer takes care of and assists you.
| zelphirkalt wrote:
| All the lines being interconnected is a rare edge-case.
| Often there are multiple independent top level
| expressions in a file. Talking about code here, because
| that is the most common thing that needs to be
| highlighted and where lines influence each other
| potentially.
|
| To make a simple example: Have multiple functions defined
| at the top level of the file? Great! Independent parts!
|
| Of course it could be, that in one function another is
| called, but does that have to affect highlighting?
| Immediately?
| lmz wrote:
| The code model still needs to be built from the entire
| file, which I suspect is what most of the slowdown is
| when using an IDE (not highlighting, although the code
| model can inform advanced highlighting e.g. different
| colors for local vs instance vars).
| zelphirkalt wrote:
| Well, that is no justification for any slowdown. The
| "code model" does not need to be complete the moment I
| start an IDE or open a file or project in it. A
| temporarily incomplete model is very acceptable. More
| work can be put off to a background thread. It can be
| delayed until I perform the first action, that actually
| needs a complete model, like say a renaming of something.
| There are relatively few actions like that. Many facts
| can already be concluded from import statements in
| various languages.
|
| Furthermore we are fighting a strawman here: Who in their
| right mind opens a 100k line code file in an IDE? And who
| in their right mind creates such a disaster in the first
| place? This is not a realistic scenario we are talking
| about here.
| R0flcopt3r wrote:
| I don't really know what you do with your text editor, but
| Emacs (and vim) are very much not "low-level" editors unless
| you chose to not configure them.
|
| Emacs has all the features of VScode, plus more. And it keeps
| expanding by each day. A "fully featured" Emacs "IDE" is also
| just as laggy, sometimes even more, as any other "fully
| featured" IDE. Some Emacs configs even take tens of seconds to
| load! Mine however takes 1.5s, but that is because everything
| is lazily loaded. The first time I open a C++ file, it takes a
| couple seconds.
|
| A really nice easy to use framework for getting productive in
| Emacs quickly is Doom[1]. You should give it a peak if you
| think Emacs is "low-level".
|
| [1] https://github.com/doomemacs/doomemacs
| ilrwbwrkhv wrote:
| After all these years, sublime still stands on a league of its
| own.
|
| Fleet is supposed to be this lightweight editor but unless it
| can beat sublime at startup, it's not.
| sgc wrote:
| One of only about three things I miss from switching away
| from Windows, is that I now have to use Sublime instead of
| Notepad++. It was just so much better at dealing with large
| files and batch operations, which are a priority for my work.
| But Sublime has beat everything else I have tried out on
| Linux, and obviously has features Notepad++ does not.
| sbuttgereit wrote:
| I took the same journey. I switched from Sublime Text to VSCode
| and stuck with VSCode for months, and depending on project du
| jour I've done this a couple of times. For me its mostly speed
| and a number of small, but frequently encountered, quality of
| life issues that keep me coming back to Sublime Text. Some of
| the small differences around cursor/multi-cursor management
| never stop irritating me in VSCode compared to ST. Also, I do a
| lot of PostgreSQL related stuff and I've yet to find a syntax
| highlighter that's 1) just syntax highlighting; and 2) able to
| handle things like dollar quoting well for VSCode where in
| Sublime Text I've had such highlighting for years.
|
| Sure it doesn't see frequent updates... but so what? That might
| well be a strength since some kinds of changes can be low value
| & highly disorienting. The plug in eco-system isn't as broad as
| that for VSCode, but unsurprisingly there's more cruft there,
| too.
|
| Ultimately your mileage will vary based on your preferences,
| but I'll stick with Sublime Text until there's something really
| more compelling.
| shkkmo wrote:
| Interesting, it was mutlicursor bugs in SublimeText that
| never got fixed the drove me to finally switch to VSCode.
| ben-schaaf wrote:
| ST dev here, what multicursor bugs specifically?
| Mawr wrote:
| Here's an annoying one:
| https://github.com/sublimehq/sublime_text/issues/1054
| TehShrike wrote:
| ah yeah, that one has me disabling word wrapping on files
| where I wouldn't otherwise.
|
| Hasn't been enough motivation to leave ST though
| FredPret wrote:
| > ST dev
|
| Just wanted to say thank you for a fantastic text editor.
| It feels like a superpower when I show it to non-tech
| people
| ElectronBadger wrote:
| > Just wanted to say thank you for a fantastic text
| editor.
|
| This. ST has been my best coding tool for the last few
| years. A keeper. Thank you!
| shkkmo wrote:
| First off, thanks for years of productive development
| with ST. I really enjoyed using your software for a long
| time and it carried me through a significant portion of
| my early career.
|
| It was a bug where selecting some text and using the key
| shortcut to multi select the next instance would select
| incorrect text for certain strings. It was a while ago so
| I don't remember the details, it may have been some
| combos of whitespace and non-alphanumeric characters.
|
| It wasn't the only reason, but it was the final impetus
| to try some other solutions.
| xenodium wrote:
| While lightweightness is often an important factor considered in
| choosing text editors, their hackability and the fun associated
| with it can be so rewarding (if you're into it of course).
|
| Sure, elisp may take a bit of time to get used to but writing
| short snippets can often bring delight, tailored to your needs.
|
| A couple of years ago, I wrote a smartish Swift yasnippet
| (https://xenodium.com/emacs-generate-a-swift-initializer). A few
| days ago, I revisted and made it smarter
| (https://xenodium.com/emacs-generate-a-swift-initializer).
| Lately, I've made lots of command-line utilities easily
| accessible with a small package I wrote
| (https://xenodium.com/seamless-command-line-utils). You can
| accomplish quite a bit with very little code. Here's another
| usage integrating with macOS (https://xenodium.com/emacs-reveal-
| in-finder-dwim-style). You can also goof around a little and
| create a welcome screen (https://xenodium.com/emacs-a-welcoming-
| experiment). Perhaps you want to blur the lines between your
| editor and your shell (https://xenodium.com/yasnippet-in-emacs-
| eshell). There are lots of packages available that do the heavy
| lifting, like multiple cursors (https://xenodium.com/inserting-
| numbers-with-emacs-multiple-c...).
|
| An all-time favorite of mine is the Emacs Rocks multiple cursors
| episode (https://emacsrocks.com/e13.html). Well worth the watch
| to the very end. He's just having so much fun.
| omaranto wrote:
| Haha! I didn't recognize your user name or domain name and when
| you mentioned seamless access to command-line tools I almost
| recommended Alvaro Ramirez's dwim-shell-commands package to
| you. Glad I clicked the link first. ;)
| xenodium wrote:
| Oh yay! Nice to hear you find dwim-shell-command useful.
| Thank you.
| schipplock wrote:
| As much as it hurts me to say this, as a fan of JetBrains and its
| tools, IntelliJ just seems to have become too heavy to run
| properly on a laptop that's not at the very higher end of laptops
| in the early 2020's.
|
| They advised you to turn off/uninstall plugins, which I did as
| well. I disabled most of the plugins, even the ones that get
| shipped by default. For me it improved the performance a lot.
|
| But imho you just need a more powerful computer :). You are
| obviously missing the features from IntelliJ :).
| Majestic121 wrote:
| Even with a middle of the line laptop from 2017, IntelliJ is
| not that bad.
|
| Disable extra plugins, do not hesitate to mark directories as
| 'excluded' if you don't need them to pop up in search
| (especially build directories), and be patient during the 5-10
| minutes indexing when you switch to a new project (which should
| not happen often) is more than enough to get very good perfs.
| LoganDark wrote:
| IntelliJ ran great on my MacBook from 2015...
| janlaureys wrote:
| I thought I did this as well, but I went to check my plugins
| after reading this comment and I just disabled at least 30
| plugins. Thanks !
| PracticalHelp wrote:
| Did you try the last step, for maximum performance? Uninstall
| IntelliJ? /s
| dist1ll wrote:
| > But imho you just need a more powerful computer :)
|
| Or maybe we need to stop tolerating performance creep and
| resource bloat?
| Sohcahtoa82 wrote:
| That ship has sailed long ago.
|
| These days, Windows Calculator takes over 20 MB to run,
| despite not significantly changing in functionality since
| Windows 3.11.
|
| How did we get here?
| jodrellblank wrote:
| > " _despite not significantly changing in functionality
| since Windows 3.11._ "
|
| Here you can run Win 3.1 in a VM in your browser with a
| click: https://copy.sh/v86/?profile=windows31 and
| Calculator is in accessories. Make sure to put it in View
| -> Scientific mode for a full comparison.
|
| Now launch Windows 10 Calculator, you'll see that it is
| resizable, Win 3.1 calulator can only be minimised. Win 10
| shows Unicode characters like Pi, square root, superscript
| exponentials, Win 3.1 shows them as "x^y" and the letters
| "PI".
|
| Win 3.1 has a memory. Win 10 has a history log of
| calculations done, a scrollable editable copyable history
| and clicking on the entries brings them back to do again.
|
| Win 3.1 has a bug where (2.01 - 2 == 0), Win 10 has that
| fixed.
|
| Win 3.1 has normal and scientific mode, Win 10 has normal,
| scientific, date calculation, multiple unit converters,
| equation graphing with customisable theme, zoomable
| scrollable live updating high quality, themeable graph.
|
| Win 10 integrates with the Windows contacts in some way to
| let you share graphed equations with other people. Currency
| conversion pulls currencies and live rates from the
| internet.
|
| Win 10 has Programmer mode which does base conversion,
| logic gates, bit shifting, bitwise number representation
| with click-to-toggle-bits for entry and viewing.
|
| Win 3.1 calculator is a binary blob, Win 10 calculator is
| open source MIT licensed on GitHub
| https://github.com/Microsoft/calculator
| vkoskiv wrote:
| Precisely. This pervasive attitude of 'duh, just upgrade your
| hardware' comes across as elitist, and is very toxic. Not
| everyone can afford to drop several thousand $ every few
| years just to maintain a tolerable development environment.
| Software bloat is ruining the world, it's a significant
| contributor to making people more jaded about technology and
| making the future seem depressing and lame.
| schipplock wrote:
| I'm on your side, but there is not much you can do to
| convince Jetbrains to make IntelliJ more performant. They are
| adding more features with every release. You can expect
| IntelliJ to become slower and slower if you don't upgrade
| your hardware.
|
| As a user your choice is buying new hardware, or not using
| IntelliJ. Paulo Renato de Athaydes decided to do the latter
| :). However, he states that he's missing the features of
| IntelliJ :). That's why I would buy a more potent computer
| (or one that has more fans and able to cool down good
| enough).
| bowsamic wrote:
| bennyp101 wrote:
| I'm assuming that was missing a '/s'?
| bowsamic wrote:
| No? Why did you interpret it as sarcasm? If you explain then
| perhaps you could help me understand
| vkoskiv wrote:
| https://justforfunnoreally.dev
| jraph wrote:
| Many people like to work on hobby projects, and hobby is
| usually done at home or somewhere else than work.
|
| It's also not recommended working on personal stuff with
| work's hardware and means, you risk losing your hobby
| projects to your company.
|
| And during work time, you are supposed to work on things
| the company told you to do, not personal stuff. If you are
| planning to do extra hours for that, why should it matter
| where you do it?
|
| Your comment probably seems non intuitive to many of us for
| all these reasons.
| bowsamic wrote:
| I don't really understand, but that's okay
| wheelerof4te wrote:
| I did not understand this viewpoint until I started to program
| for a living.
|
| So, don't worry about the downvotes. They will understand
| someday.
| jraph wrote:
| You are assuming everyone should reach your conclusion. Some
| of us have been programming for a living for years and still
| like programming outside work. Because for instance you get
| to build whatever you want under whatever condition you like.
| tmtvl wrote:
| A code monkey is not selling their programming skill to per
| employer, person is trading hours spent doing work-related
| tasks for money. Once the agreed amount of hours has been
| filled person can do whatever person want (without reasonable
| bounds, of course) and does not have to think about per work.
| If per employer wants per not to program outside of work, per
| employer could offer a contract stipulating that, but I would
| expect person to seek a rather sizeable remuneration afore
| accepting such an offer.
| vkoskiv wrote:
| My employer pays me to work 37.5 hours a week. An excessive
| amount of hours beyond that would raise potential legal issues,
| as there are limits on how much overtime is allowed.
|
| And yes, people do things for fun, too, not just for money.
| pabs3 wrote:
| If you use open source at home, eventually you'll want to
| improve it by doing programming at home.
| favadi wrote:
| If I'm a cook, I should not cook outside of the restaurant
| ever?
| ris58h wrote:
| > You should not be programming outside of that
|
| I shouldn't do what I like because what? Because bowsamic
| doesn't like it?
| bowsamic wrote:
| I don't think it's very respectful to your boss
| n-e-w wrote:
| I think I speak for essentially everyone here when I say,
| "fk this guy's boss". Old mate here in this thread slacks
| off or 2 days, his boss is already very respectfully
| thinking of firing him.
|
| It's not 1920. The modern middle manager has more invested
| in his fantasy football league than his direct reports --
| and by some magnitude. Grow up.
| brabel wrote:
| Are you serious? If anything, the boss should be happy
| someone is improving their skills on their spare time
| instead of learning everything on the job.
| ris58h wrote:
| Could you explain how things that I do in my free time is
| disrespectful to my boss?
| rob74 wrote:
| > _On my top-of-the-line Mac M1 with 64GB of RAM and 10 CPU
| cores, everything feels lightweight and smooth [...] But when I
| am at home and want to work on a hobby project, I prefer to use
| my less powerful laptops [...] after just an hour or so writing
| code and running tests using IntelliJ, the laptop becomes
| unusably hot. The fans get louder and louder until it's really
| annoying._
|
| To add my anecdotal evidence: I have a relatively new Dell Core
| i7 laptop with "only" 16 GB of RAM, and while using IntelliJ IDEs
| "normally" (i.e. not while it's updating its cache), the CPU
| usage rarely goes above 5%. So the impression that you need top
| of the line hardware for running IntelliJ products that the blog
| post is giving is a bit exaggerated...
| jeroenhd wrote:
| There could be some kind of limitation on Apple's chips, there
| are complaints across the Internet of IntelliJ being slow on
| Mac despite the power of the M-series SoCs. It could be that
| there are optimisations to be made in their JVM for generating
| ARM code.
|
| Disabling plugins helps a lot, though. On install you'll get a
| screen that let's you select tons of features that had me going
| "gimme gimme gimme" but in hindsight I've never used 90% of
| them. For example, Android support is a major plugin I've never
| used with Idea because Android Studio exists and seems to
| integrate much better. Disabling that cut down startup time by
| a noticeable amount when I last culled my install.
|
| My experience with tricked out command line editors has been
| that they start out blazing fast but as you add more and more
| features (syntax highlighting, linting, etc.) they become
| slower than your average IDE. They're still responsive when
| they're not doing anything, but sometimes they just need a few
| seconds to think, breaking up my work flow.
|
| Another issue that I've seen some people run into is that
| IntelliJ will index all your files. If you have some kind of
| process that slows down your computer when you're opening tons
| of tiny files (say, an antivirus program or a project stored in
| a hard drive) that can instantly kill your work flow. The only
| alternative seems to be to postpone loading all the files until
| you start searching (which VS Code seems to do) but then you're
| just moving the problem around, not really fixing it.
|
| It's what I get for using a text editor for an IDE, I suppose.
| My experience with Jetbrains tools is that they're a lot more
| powerful than most of the competition at the cost of some minor
| input latency during heavy operations such as indexing.
| jansan wrote:
| I am using a seven year old ThinkPad T550 with 16MB and onboard
| graphics, because I know that if it runs fast on my machine, it
| runs fast almost everywhere else. IntelliJ is very usable with
| that configuration, except the terminal (as I wrote in another
| comment).
___________________________________________________________________
(page generated 2022-12-13 23:02 UTC)