Posted by yett 3 days ago
And, of course, the other reason why I'm so enthusiastic about their products is that they're one of the only companies that has been able to maintain a thoroughly symbiotic relationship with the developer community. They somehow have consistently maintained a healthy balance of giving things away without losing their business—their subscription model is humane (you get to use the last version you paid for indefinitely), they have an open source core, and they lean in more than most to giving their paid products away to students and others who can't pay.
I happily pay this every year myself, but I think it's important to note it's not really a subscription. You pay for software, and you keep that software forever. If you stop paying, you still get to keep what you paid for. What you pay for every year are the updates.
I know it's a subtle distinction, but I think it's an important one to make. Again, I happily pay every where, and it acts very much like a subscription, but it's not like a Creative Suite subscription. If you stop paying, you an always just stay on the software you paid for.
It’s a bit odd. I wish I was paying for 1 year of updates.
Years ago, there was a company that made a refactoring engine for C, I believe I paid >100$ for it in the late 90s or early 2000s. It was a standalone server that could communicate with Emacs (I wasn't an Emacs user). For a consulting engagement, I bought this tool and learned Emacs. I printed out a poster that I put on the wall that show the workflow for the most common tasks I needed to accomplish. I could not have completed it without it.
I discussed this with other programmers at the time, and they were somewhat incredulous that I bought software instead of spending 10x the time to complete the task. Knowing when to buy tools is a skill in and of itself.
No need for a mouse and on-the-fly macro recording and replaying? How many first-born do they want?
I've been paying for the subscription for years, so "first" isn't quite right either, because for me that would be some very old version.
> It’s important to note that, if you’re using a non-commercial license, you cannot opt out of the collection of anonymous usage statistics.
not just anonymous statistics, i presume
"You agree that the product will send usage data to validate your compliance with the license terms and anonymous feature usage statistics..."
"The information collected under Sections 4.1. and 4.2. may include but is not limited to frameworks, file templates used in the Product, actions invoked, and other interactions with the Product’s features."
Source code is never sent under any circumstances.
(1) CoPilot code completion (for open source GitHub users)
(2) devcontainer integration
(3) docker integration
Do the free versions not include plugin support?
OP is correct about Docker integration and Dev Containers: they cannot be added to the free versions. Dev Containers specifically seems to be OP's big sticking point, but it's a weirdly pedantic point. JetBrains can't give everything away for free or they wouldn't be able to fund their development.
Picking a few professional-grade features and asking people to pay if they really need them is a totally reasonable approach.
Apologies. Nevertheless, going by its user reviews, it gets the short end of the stick relative to what's in VSCode. Those who've used it with both PyCharm and VSCode seem to prefer using it in VSCode because they find various functionalities lacking in PyCharm.
If a tool works for them, then it works. I don’t think that’s a lack of understanding on their part.
If the opposing view is « clearly VSCode is objectively the only choice », then I think that camp has a distinct lack of understanding that people’s needs are diverse and no 1 tool solves every problem for all people.
If someone prefers Pycharm CE, it’s quite condescending to say « they just don’t understand ». Different strokes for different folks?
Secondly, the free JetBrains IDEs also lack devcontainer support which is readily present in VSCode. To not use devcontainer is a substantial security hazard.
Actually, there is a significant difference between the community versions (e.g. for PyCharm) and the versions available for non-commercial use. The latter are full versions of the products without any reduced functionality, whereas the community editions have certain features trimmed.
Can you elaborate? Is VS Code making containers for you so you are safe from packages or from random plugins you have to install?
Because some of us have never heard of devcontainers as a named concept with its own spec until now. I've been running my dev servers inside containers for a long time now (using JetBrains IDEs!), but have never heard of this before.
> It is well known that a container offers a sandbox and process isolation.
No, actually, it's well known that containers don't do that. It's one of the first things you learn when you start learning about containers—they are not virtual machines and are not suitable for running untrusted code, because they share a kernel with the host.
I just read through the introduction to devcontainers and there are lots of benefits it discusses but security isn't one of them:
Oh but it is. If there is harmful data-stealing software running in the container, it will remain isolated to the container. And if the kernel is shared with the host, that's a read-only share.
And what protects the production server when you deploy the evil packages?
Assuming the code that implements the containerization is 100% bug free and there are no container escapes. I would not bet my user's safety purely on that assumption.
I have no problem with the paid versions of JetBrains IDEs which I think are great, but to pay, one has to first find value in the free version (which is now lacking).
> And if the kernel is shared with the host, that's a read-only share.
No, it's not, the kernel is reading and writing files constantly for the container. A bug in the kernel could be exploited to break the sandbox, which isn't possible in a true VM.
Only if you don't let down your guard because it's "secure". Again, there's a reason why they don't claim it's secure and everyone says to not treat containers as a sandbox.
It's well known that the comments on HN are great for having discussions. You don't have to participate, despite your belief that you are required to. But, it's well known that having a discussion is a two way street, with people commenting and asking questions, and people replying.
If someone could explain to me how to programmatically perform all lifecycle features with a container (e.g. rebuild etc) without ever having to touch VSC’s special in-IDE command palette that would be incredible.
The current iteration is too much magic at the expense of too little control and visibility.