3 ms·
> Not sure why I would choose Windows unless I needed the C#/.Net toolchain. You're missing out on Visual Studio... for Python, C++, etc.
by dataflow 6y ago
> Not sure why I would choose Windows unless I needed the C#/.Net toolchain.
You're missing out on Visual Studio... for Python, C++, etc.
- loloquwowndueo 6y agoThanks to jetbrains, no, you’re not.
- dataflow 6y agoBefore we even get to talking about CLion's features/usability vs. Visual Studio, you have to get over the fact that it's like $90/year...
- Icathian 6y agoI always find this such a strange argument. We're in the middle of hundreds of comments arguing about convenience and losing time fighting with bugs and environment problems. For the umpteenth time in the last year. And the price of an hour of your time (two at most) once per year might be a sticking point for solving much of that? Just doesn't make sense to me.
- dataflow 6y agoWhy do you imagine Microsoft made Visual Studio free even for companies with <= 5 users if the same people would've paid for it anyway?
- npteljes 6y agoPeople would pay, especially companies would pay, because they are legally required to. But if you make it free than you have bigger chance to dominate the market.
- freeone3000 6y agoHonestly, you're not missing much. Using Visual Studio is always a clunky, slow experience with frustrating UI changes every time I click something.
- dataflow 6y agoI'm using it as we speak and I'm finding it helpful rather than frustrating. I'm not sure what you're clicking that's changing your UI, but maybe you need to configure it a bit? You can disable Ctrl+Click for example if you don't like it, then forget about it.
- freeone3000 6y agoWhenever I click "run", everything moves around and I'm not able to edit files. I had it customized, but if I'm going to have to customize it continually, it's not worth it.
- dataflow 6y agoWhat do you mean by "everything moves around"? Are you referring to how the tool window layout is independent for debugging vs. developing (like in Eclipse)? That's actually something many of us find incredibly helpful because some toolboxes don't even make sense in the development perspective (like the Locals toolbox), so we don't want them there. I'd bet once you got the hang of it and customized it, you wouldn't want the exact same toolboxes in both places either. (Eclipse does this too, except it's awful because it doesn't switch back automatically when exiting debugging.) What you want to do there is to customize it when debugging, but that takes like 1-3 minutes tops, and you just do it once and never have to think about it again. Tossing it out because of that is like abandoning your home because you don't like your room layouts and you don't want to arrange things in more than one room... if this is what's bugging you, you should really reconsider. As for VS being slow, it mainly depends how big your project/solution is. Where I know it can be unreasonably slow is when you have lots of projects (several dozen) and you're trying to change all their settings, or something like that. However, if you're referring to the startup time specifically, it might actually be due to your computer not having generated the native images yet (try running ngen.exe executeQueuedItems for both 64-bit and 32-bit). If you mean editing source code, it shouldn't be sluggish at all. But if you mean features like Find Reference, Go To Definition, etc., those rely on Intellisense which takes a while to update for a complicated language like C++ (or a dynamic one like Python)—I don't expect much variation across IDEs here. ___________________________ UPDATE: I think you deleted your reply, but I replied to it already, so I'll paste it here: You're talking just about when you hover on the tool tabs, right? (i.e. the delay should not be there if you click, right?) It takes 400ms to open by default because that's the default menu show delay on Windows. It's the same delay you see if you right-click inside a folder and hover on New, for example. The delay actually works well for menus for older folks/non-techies, but it's glacially slow for developers (including for menus) unfortunately. You can reduce the delay by changing HKEY_CURRENT_USER\Control Panel\Desktop\MenuShowDelay in the registry from 400 to something else (I like 40) and then logging out and logging back in. I can't speak to what CLion does with the memory you give it, but it's generally bad for programs to take up arbitrary amounts of memory, given that'd deny the memory to other apps. I wouldn't judge a program positively if it takes up more and more memory the more I give it. For the ngen thing this is specifically what you want to run: C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe executeQueuedItems C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe executeQueuedItems If this is the reason for the slow startup, it should reduce the startup time drastically. For reference, on my laptop (almost 3GHz) VS 2019 takes around ~1 second to launch into an empty environment, which I find pretty acceptable for an IDE. As to what you're missing by using CLion, well the first thing is the subscription money and the second thing is that it doesn't support nearly as many languages. Beyond that, I'm not sure I can give an accurate response right now because CLion has changed a fair bit since I last tried it, and added new features it didn't use to have before. I know one thing I can think of off the top of my head is that CLion uses Make and/or CMake, both of which have so many rough edges (like relative paths, paths with spaces, etc.) that anything based on them turns me off a priori (and in fact terrifies me because it means my files might get accidentally wiped). Other than that, I'd have to try it again myself and see what might have changed. You should just give both of them a real try and compare; you might end up liking both for all I know. But I can't think of anyone I know who's given VS a real chance and disliked it—the only exceptions I know are people who just hate it because they hate things Windows things altogether.