Live data from Hacker News

PyCharm 2023.1

jetbrains.com

51–60 of 60 posts

Re: PyCharm 2023.1

#51
post #18

Will JetBrains IDEs survive VSCode + GPT plugins combo?

You can run copilot in Jetbrains and a variety of other AI plugins as well

VSCode has dozens of ChatGPT and GPT-4 plugins now, not just copilot/tabnine/kite.

Re: PyCharm 2023.1

#52

I've fully moved past jetbrains. The program is slower than every other IDE I use. Any time you reboot or change environments there it takes like 3-10 minutes with my tower. I know that seems like a niche reason, but when no other IDE has this issue, and they have similar/better plugins; why bother? Since the VIM addon of Spyder, I've been hooked. I personally like the data visualizations the best. They are fast and…

I used JB software for years and was a big avocate (I am an amateur dev).

Then I started to mix Python, Go, TypeScript, Vue, ... and had to be juggle between editors. Some features were common, some other not.

I forced myself to fully switch to vscode for a week and after initial struggles this is, for me, by far a better ide.

It misses things but heads a mich better configuration. All languages are consistent and can live together.

I am not coming back.

Re: PyCharm 2023.1

#53

Interesting. I heard many good things about Pycharm, but it kind of looks bloated? How does it compare to VS Code (which is quite good (notebook and repl support mostly), but not great, in particular regarding the debugging experience)?

I think that while it takes forever to boot up from cold, those monolith-style classic IDEs with their centralized caching (and most important, centralized AST caching) outrun (by a lot) those Language Server Protocol based text editors when you're jumping around and editing code.

Going around code is faster. Global search is faster. Autocomplete is faster. Refactoring is faster.

Using the Java Language Server Protocol in VS Code was very painful even for very trivial Java Spring Boot projects.

Granted, their boot and first pass of project analysis is really slow.

That being said I still use VS Code very often (as a cool text editor, not as IDE), and I have no clue how VS Code boots and feels so snappy when most other Electron apps that I use feel like unresponsive slow garbage.

Re: PyCharm 2023.1

#54

Earlier quoted context omitted.

I don't mind the changes

And that's fine! But why do software vendors feel the need to shove a new design down everyone's throat, even for those who don't want or care for it? As far as I can tell, there is an option to opt out of the new UI, but I won't bank on it lasting long.

I guess because it is too hard to support two very complex and different UIs

Re: PyCharm 2023.1

#55

I've fully moved past jetbrains. The program is slower than every other IDE I use. Any time you reboot or change environments there it takes like 3-10 minutes with my tower. I know that seems like a niche reason, but when no other IDE has this issue, and they have similar/better plugins; why bother? Since the VIM addon of Spyder, I've been hooked. I personally like the data visualizations the best. They are fast and…

I don't think any other IDE has "better" functionality. A Jetbrains IDE packs a ton of features (I have tried several alternatives but none come close). The only language where VSCode even seriously competes is Typescript (Rider is much better at C#). I used them originally on 4GB laptop and now on 16GB macbook, and I never found it to be too slow. (the indexing part can be slow, but they mitigated it somewhat by all…

If the OS is Windows, I'd suggest anyone struggling with lag make absolutely certain that the project and scratch folders are excluded from Defender real-time scanning. It makes a huge difference.

Re: PyCharm 2023.1

#56

Earlier quoted context omitted.

People always use bloated as an argument against something. Bloated framework, bloated linux distro, bloated ide… What really is the problem with having all “the plugins installed”/features, nicely integrated, always compatible, reasonably configurable, maintained and with support vs inflating a minimal editor (framework, *) yourself, without all the advantages mentioned earlier. Yes it may cost some cheap memory, vs…

> Everything just works That's... That's a huge stretch. I've been on an outdated version of pycharm for nearly a year now because they broke support for docker-compose in a pretty huge way. Moreover, I have yet to have a pycharm project where I didn't need to create my own docker override file.

Interesting, i recall doing that in the early days of the docker integration. It is pretty solid now. Also might have been the weird way that project was setup, but i do not remember the specifics.

Also cannot judge it because you gave no examples.

Maybe your project is an outlier?

Re: PyCharm 2023.1

#57

Interesting. I heard many good things about Pycharm, but it kind of looks bloated? How does it compare to VS Code (which is quite good (notebook and repl support mostly), but not great, in particular regarding the debugging experience)?

I use PyCharm for my job as well as for personal projects, and it handles large codebases with type annotations very well. I would compare it to Visual Studio (not Code) in the sense that it’s a batteries included deal, which means larger initial size but I use maybe two plugins.

Re type annotations, is there some non-default setting or plugin I am overlooking?

As a long time pycharm user who recently switched to vscode, I have found pycharm's understanding of type annotations to be borderline broken.

  def foo(value: Optional[str]) -> None:
      print(value.replace("bar", "baz"))
mypy and vscode both point out this will fail when value is None, but my pycharm seems to think this is perfectly fine.

Re: PyCharm 2023.1

#58
I’ve been using pycharm pretty much daily for a few years, and switched to the new UI a few weeks ago.

I like it, especially when doing dev work with only one monitor. You might hate it, but it’s worth giving it a shot.

Re: PyCharm 2023.1

#59
post #2

I hope they also worked on removing the many UI bugs from PyCharm remote: laggy scrolling while in the diff view, some editor settings like rulers at 100/120 chars not working properly, some settings panes lagging out until the editor is restarted, etc etc. I need to develop on a remote VM and I’m using VSCode at the moment because it’s remote story is less buggy, but would much rather be using PyCharm.

What issues are you facing? Last time I checked, running headless intellij on a server and editing code on it without ssh latency was a breeze.

There a lots of tiny issues: some UI settings like rulers (or whatever PyCharm calls them, vertical guides that tell you when you’re at 100 chars or something) just don’t work, and don’t show up in the main editor (but they show up in the diffs!). Some editor settings, like the main Python settings pane, just doesn’t load its settings page, and requires restarting the editor. Scrolling diffs with the scroll wheel is so janky and laggy to be unusable, but the main editor scrolls fine. Reconnecting after a short disconnect (open and close laptop lid) takes too long. The git client gets itself into a weird state sometimes where it will create the same 5 files no matter which branch I switch to, and the only way I’ve found to reset that is to delete every trace of IntelliJ off the remote and reconnect.

Re: PyCharm 2023.1

#60

Earlier quoted context omitted.

I use PyCharm for my job as well as for personal projects, and it handles large codebases with type annotations very well. I would compare it to Visual Studio (not Code) in the sense that it’s a batteries included deal, which means larger initial size but I use maybe two plugins.

Re type annotations, is there some non-default setting or plugin I am overlooking? As a long time pycharm user who recently switched to vscode, I have found pycharm's understanding of type annotations to be borderline broken. def foo(value: Optional[str]) -> None: print(value.replace("bar", "baz")) mypy and vscode both point out this will fail when value is None, but my pycharm seems to think this is perfectly fine.

To be honest I don’t use the type annotations given by the IDE that much, and I also only encounter them in my work code base (pymongo), so I can’t comment on that part. I was mainly commenting just on its ability to handle large code bases.
Post reply on HN