4 ms·
In my opinion, one killer feature of VSCode is the ability to connect to WSL, remote server and Docker container. As someone mainly developing on WSL2, I use th
by maple3142 6y ago
In my opinion, one killer feature of VSCode is the ability to connect to WSL, remote server and Docker container. As someone mainly developing on WSL2, I use this feature everyday. I only use Idea when I need to use Java or Kotlin, because its language support is really good.
- vbsteven 6y agoWSL support is in IntelliJ now. Makes it super easy to use jdk/node and other toolchains on the WSL side from IntelliJ running on the windows side
- The_rationalist 6y agoIntellij 2021.1 has the feature called run targets, which enable to run your code on a docker environment or on a remote server. It also bring WSL support. https://blog.jetbrains.com/idea/2021/03/intellij-idea-2021-1-beta/ https://blog.jetbrains.com/idea/2021/03/intellij-idea-2021-1...
- dalai 6y agoThere is also projector and "code with me", but they still have some work to do before they reach feature parity in that regard. At least they are working on it. https://youtrack.jetbrains.com/issue/IDEA-226455#focus=Comments-27-4683103.0-0 https://youtrack.jetbrains.com/issue/IDEA-226455#focus=Comme...
- dsissitka 6y agoIt looks like JetBrains' Projector went 1.0 last month.
- mellosouls 6y agoI agree with this; I bought the professional license of PyCharm on the basis of its "remote development" functionality which I assumed would meet the (admitted) easy "it just works" standards of everything else in Idea. It never worked, not even close and I ended up dumping it and returning to VS Code because the remote stuff (particularly to linux VMs and containers) was a deal-breaker. Real missed opportunity I thought, it had been a long-standing bug when I looked into it, and very very oversold as functionality present in the professional version.
- salex89 6y agoI've seen this being mentioned in other comments, and besides WSL2, I've used PyCharm (a close relative to IDEA) connected to containers, Vagrant and plain VMs for years. I suppose the rest of the IntelliJ products have the same support, and WSL2 being rolled out, obviously?
- whateveracct 6y ago> or Kotlin, because its language support is really good. I've been using Kotlin for about a year now at work. I feel that "IDEA has good Kotlin support" isn't quite the right way to say it. It's become clear to me that the language is explicitly designed to be read and written in IDEA. Receivers (changing `this` per-scope) and `it` (to a lesser degree) are really poor syntax features to read in plaintext. But IDEA automatically adds the plaintext for you so you don't notice. Genius business move by JetBrains. Get some corporations hooked on some sugar on top of Java, and now they have to pay that fat license forever.
- iudqnolq 6y agoOr, less cynically, it's time we moved beyond designing languages for the lowest common denominator in editors. Sure I should be able to make tweaks in notepad, but I'm totally fine with that being the less happy path. This is a direction jetbrains has been going in for a while. Have a look at the failed https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/
- whateveracct 6y agoThat's not exactly what I'm complaining about though. The syntax features I mention only make any sense period within IDEA. But it's just a syntax feature. The value-add is very low! But it's pervasive in Kotlin. That creates the lock-in. In fact, pumping IDEA's seeming value is those features' biggest impact on the average Kotlin developer. The majority of the valuable code I've written in my life has been Haskell. I do just use emacs, but I heavily use ghci (free and flexible) to aid my understanding. But most of that Haskell was conceived while I was doing the dishes. So far, my Kotlin has been too tbh. So IDEA isn't solving the actual critical path of software problem solving. Kotlin and IDEA are sugar for the masses. Nothing more. And I'm pretty sure they know what they're doing when they aren't drunk on their kool-aid.
- iudqnolq 6y agoI happen to disagree with you both that syntax is irrelevant and that receiver scopes are "just syntax". I think whether you care strongly about syntax is just personal preference. For example, I prefer Elixir to Erlang, TypeScript to JavaScript, and Kotlin to Java even though they could be/are implemented by transforming source code to source code. On receiver scopes specifically, they make simple DSLs very easy to implement. Arguably needing a DSl is a symptom of design flaws, but Android has a lot of those so receiver scopes makes Android programming a lot nicer. Edit: I would call this more than syntactic sugar: interface MyScope { fun frob() } fun foobar(content: MyScope.() -> Unit) { let scope = MyScopeImpl() scope.apply(content) scope.getResultInternal() } fun user() { foobar { frob() } }