[voyager1]

Protip if you have good internet and don't want to configure everything locally: Jetbrains Gateway [1].

At the last company we had Docker, Java 8, Wildfly 10, Gradle 4 and I didn't manage to make it run locally on M1.

I was pleasently surprised with how smooth it was to connect to Ubuntu VM with Jetbrains Gateway. You use native Jetbrains app on your computer (Intellij Idea in my case), but everything is executed and compiled on the remote machine (Ubuntu VM). Another huge upside is that Docker is running on Ubuntu, which is a lot faster than on OSX. Downside is that your are dependant on the Internet ofcourse.

Officially the product is still in Beta, but it worked good enough for me.

[1] https://www.jetbrains.com/remote-development/gateway/

[hbn]

It's good to have the option, but ideally if I buy a really nice new computer, I'd like to actually be taking advantage of that hardware I paid for!

[ChuckNorris89]

Yeah, same. I don't get the point of buying an expensive and benchmark crushing piece of ARM hardware for some development work if it has the utility of a $200 Chromebook where you have to SSH into powerful X86 machines to actually achieve your development goal.

[kikowi]

The biggest performance eye opener for me was when I opened outlook.office.com. On M1 its almost instantaneous where on my old mac (maxed MBP 2015 & Mojave OS) or Ubuntu Desktop machine (32GB RAM & i7 6700) it took 10 seconds or more (all done on the same network).

I noticed I fell out of the "flow" a lot less on M1, because actions that took a few seconds on other machines are now instantaneous.

Regarding the Intellij Idea and Docker, my old 16GB MBP 2015 Mojave was struggling hard and getting very hot with 100K LoC project. I would definitely use the Gateway on old machine aswell.

[ChuckNorris89]

To be fair, both your 2015 MBP and 2015 6th gen Intel desktop are pretty outdated compared to your M1 Macbook, so of course they're slow in comparison, what else did you expect?

For a more apples to apples comparison, Intel 12th gen and AMD Ryzen 6000 series would also give you a lightning fast experience comparable to your M1, especially since modern systems come with faster memory and faster storage than your 2015 machines, contributing to the perception of speed.

[voyager1]

Ofcourse, it was a response to why I dont just use a 200$ Chromebook. Latest AMD or Intel is definetly as fast, albeit at a higher TDP.

[digisign]

Yes, hard to believe but that was seven years ago. In the old days it would have been like comparing a 286 to a 486. Intel has certainly plateaud since then but Apple's ARM kept some of that momentum.

[thebean11]

You are underestimating how much processing power you need for a smooth experience using IntelliJ, even without compiling anything :P

[mopierotti]

One thing I'll throw out there is that I've recently been running IntelliJ using jdk 17 with ZGC as the garbage collector, and it seems snappier. (You can use the 17.0 runtime that jetbrains releases on github, this page has more related info https://mustafaakin.dev/posts/2021-12-08-running-intellij-id... )

[throwaway4good]

Huh - my ten year old mbp runs intellij just fine?!

[theshrike79]

We might have different definitions of "just fine".

On my M1 Max MBP Jetbrains Rider stars in under two seconds. Loading the quite large project takes another two.

On my previous laptop, an i7 MBP, it took in the order of minutes to get Rider to the point where I could actually start writing code with codecompletion. It sounded like a jet taking off while Rider blasted all cores at max to enable the smart completions.

The M1 Max isn't even slightly warm in the same case. Haven't found out a single spot where it would've even slightly stuttered.

[thebean11]

Really? My 2013 high spec'd Mac Pro is feeling the pain on a medium sized typescript project. The coding hints / errors take many seconds to load.

[MockObject]

That's odd. It runs as snappy as ever on my 16G 2013 MacBook Pro.

[sixothree]

Doesn't mean you can't run that Ubuntu instance in a VM on the same machine. Wait does it? Can you run VMs on these guys?

[fallenhitokiri]

Parallels works fine, VMWare Fusion provides a tech preview for M1 - I’m running Debian arm64 VMs this way. Both (AFAIK) don’t support x86 guests and don plan to (virtualization vs emulation). So you’d have the same issues as with as with Docker.

There seems to be a work around with qemu and UTM but I cannot speak to its performance or how viable this solution is.

[rerx]

Gave this a try a few weeks ago (for CLion with Jetbrains Client, IntelliJ for Java might be further of course) and felt it was still quite lacking. Loads of features weren't there yet. Of the top of my head: no way to use my customized keymap, no git blame annotations, fundamental navigation shortcuts missing (jump back, navigate via file structure), no way to attach the debugger to a process, ...

I went back to remote controlling the full-featured IDE via Projector, their earlier approach too remote development. That works extremely well for what it is. Probably the richer Gateway client will catch up in a while, but not quite yet.

[foobarian]

I am able to attach to the remote JVM fine. However the roundtrip makes the QoL features like getting object contents a little slow. But it works!

The main issue I've seen is the gateway/target JVM combo gets wedged in some weird state somehow that persists across retarts and I found myself killing idea processes by hand on the remote server. But hey it's Beta! Works pretty excellent considering.

[gjvc]

looks like Projector is somewhat deprecated and removed from the Toolbox app (internal YouTrack item https://youtrack.jetbrains.com/issue/TBX-7455)

they do state on this page https://lp.jetbrains.com/projector/ "If you're not sure which solution you should choose, please consider using Gateway."

[rerx]

Yeah, that statement prompted me to try Gateway. It felt a bit premature then. The initial setup is a bit more involved with Projector, which may be a good reason to direct new users to the more recent offering.

[pmulv]

> no git blame annotations

Thanks for mentioning this. I was going to give this a try this weekend but that's a dealbreaker for me.

[rerx]

Here's their ticket for that feature: https://youtrack.jetbrains.com/issue/CWM-2913

Sounds like they _are_ making fast progress at least.

[matsemann]

Ah, very cool. For java dev I haven't yet felt the need to containerize anything, normally mvn clean install works and does everything needed. But for Python I've used remote interpreters through docker in PyCharm lately (since getting a python env installed with wheels & stuff properly is sometimes almost impossible).

VSCode have had some more luck with their frontend/backend architecture making it easier to pull off, glad to see jetbrains is on the move, as I prefer them.

[eropple]

YMMV, but I've had very good luck just using asdf for...pretty much everything, Python included. In a normal week I'll probably touch half a dozen environments--Node, PHP, Python, Java, Ruby, Golang, maybe sometimes dotnet-core--and asdf not only Just Works for me, but has done so without thinking about it for going on three years or so, when stuff like rvm/rbenv changed rapidly enough as to necessitate changing it up to stay on the same page as my teammates.

No relation, just a super happy user.

[matsemann]

Our experience is gcloud and some other commands get messed up :/

Probably not asdf's fault, though. I've had multiple issues with gcloud not being compatible with my setup, spamming errors like /tmp/_MEIRZ3igG/libssl.so.1.1

But what asdf doesn't solve, though, is the setup for new devs. Python projects can sometimes take days to get running properly on a machine because of various differences, asdf solves some of it but replaces it with other installation steps instead.

That's what I like about a dockerized setup, if it works one place it works for everyone (almost, nix is probably better).

[eropple]

I can't speak to Python beyond the fairly minimal touch points I have with our projects, but Python anecdotally seems much rougher than it should be in many respects. But pretty much everything I touch (Node, Java, Ruby, dotnet-core) ends up being solved with asdf, a Brewfile for the Mac users and yum-and-xargs for the Fedora folks (me), in very short order. As far as new machines go, I have a shell script that I share with new folks (and my own version for a new machine) that just gets things done. (Used to use chef-zero, but that got really crusty.)

I like Docker for a lot of things. That said, on code inside containers is pretty awful, in my experience, and I'd much rather use docker-compose with something like Traefik to route outside Docker so I can run my service locally and everything works as I expect it. You can always tell a project that I work on because there's a bash script in there that fires up tmux with docker-compose, all services under nodemon, ngrok, etc. all good to go. ;)

[sz4kerto]

We're moving our whole company to this product right now. Instead of buying (and upgrading) more and more powerful laptops for our (fully remote) dev team, we just get them whatever thin&light stuff they want, and a dedicated server with large RAM so that they can run the whole test environment easily. There are some rough edges here and there, but it's a game changer.

[mhitza]

Thin clients are back on the menu.

I wanted to transition to this development model a year ago, but unfortunately X11 forwarding was slow on mobile connections, and as far as I'm aware (if you know a workaround let me know), on Linux, RDP can't be made to just share a single app, only full desktop sessions.

[sz4kerto]

We experimented with X forwarding, but it worked well only on e.g. local networks. Some people still ended up using X forwarding, but JB Gateway or VSC Remote is in a different league.

We have also tried Jetbrains Projector, which is basically a different rendering engine for Java Swing. A remote IDEA instance was rendering the UI through HTML, i.e. you could develop in a browser. It worked relatively well, but there were some issues around copy/paste, etc.

[rerx]

> It worked relatively well, but there were some issues around copy/paste, etc.

They have an electron-based client that improves on some of these issues that stem from running inside a browser:

https://jetbrains.github.io/projector-client/mkdocs/latest/i...

[Yeroc]

The only thing I've found to be half-ways usable is x2go. With it you can have a rootless window session. I still end up using VS Code Remote development tools a lot though.

[beecafe]

Try Xpra, it's like X11 forwarding but much snappier.

[pjmlp]

Welcome back to telnet + X Windows into the UNIX development server.

[olavgg]

Thank you for your suggestion, I just gave this a try, and it's almost there but there are still some rough edges. It needs to mature a little bit more.

Though this got me thinking a little bit, I have ordered a M1 Max 32GB which I have been waiting for over 5 months now. I am actually looking into getting the M1 air with 8GB as I think it will suffice for my Java development. I don't need to run VM's on that machine.

I'm gonna think about this through this weekend. I don't really need the firepower from the M1 Max as it has similar single core performance to the M1 air. And if this product matures, I will really not need that much RAM either.

[vonseel]

You should definitely give the M1 MBA a try and return it if it doesn’t work well. Mine is only 8Gb RAM too, but I haven’t noticed paging slowdowns or any problems.

[vital101]

This is similar to how developing with VSCode is on Windows + WSL.

[jhgb]

Emacs+SLIME has worked like this since the beginning.

[nicolapcweek94]

Same with Emacs + CIDER for Clojure instead of Common Lisp. Fully remote project setup on powerful server, accessed from local Emacs with TRAMP mode. CIDER commands (REPL included) work over the remote connection perfectly fine and run on the remote host, including automatic SSH tunnelling for the nREPL port if needed (for example if the remote host is behind firewall)

[cstrat]

self hosted https://coder.com/ is amazing.

[moron4hire]

WSL does not run remotely. It runs in a VM locally.

[lovingCranberry]

WSL2 is running a VSCode server, exposes a port to the host and the VSC client from the host connects to it. In theory you could also run the VSCode Server on a remote machine.

I think the "Remote-SSH" plugin is a better fit for a comparison though, but @vital101's comment is not wrong.

[rieckpil]

Thanks for sharing this product. It looks really promising.

Testcontainers Cloud (https://www.atomicjar.com/2021/11/announcing-testcontainers-...) may be another tool to use for those that only want to "outsource" the container part of running intgeration tests.

[wccrawford]

I just tried to connect to my Intel OSX with Gateway and it told me that OSX/x86_64 isn't a valid combination and refused to connect.

I was hoping to use it to do most of my stuff remotely, instead of a remote client or a mouse/kb sharing program like Barrier.

[mhoad]

As an alternative I’ve had great experiences so far with GitHub’s Codespaces.

I couldn’t see myself going back to just running everything outside of at least some containerised environment at a minimum even if not fully remote.

I do a bunch of front end web stuff as well and now the thought of just running npm on my local machine gives me the chills. It’s akin to attending an orgy without a condom :)

[pc86]

No it's not

[mhoad]

Let’s just download thousand of pieces of random unaudited code that has some level of updates almost daily from people I’ve never met before and run it on my machine using an account which also probably has root access and where that same code can access any part of my filesystem and has zero meaningful restrictions on what it does with it… yes it is.

[shabazahmed]

VScode remote containers are much more flexible.

[digisign]

Do tell, how so?

[no_circuit]

You can only open one project at once with Gateway: https://youtrack.jetbrains.com/issue/GTW-813. If it was designed this way, how long will it take to be fixed?

[ta988]

Jetbrains Gateway doesn't work on M1. Unless you modify it heavily and you control it from the command line.

[sz4kerto]

It definitely does, without any kind of extra configuration or work.

[ta988]

It does only if you connect to x86 machines. You can't connect to arm machines so no VM on your M1.