4 ms·
Yes but then your code isn’t idiomatic/multi platform/whatever. It’s a trade off (and one where I would always chose Java).
by vips7L 5y ago
Yes but then your code isn’t idiomatic/multi platform/whatever. It’s a trade off (and one where I would always chose Java).
- pjmlp 5y agoI learned an hard lesson in the Borland ecosystem. Always go with the platforms languages, and the IDEs from the platform owners, even if others are more shinny. Long term it always pays off to be the turtle, as the platforms move into directions not forseen by the shinny objects, and 3rd party IDEs keep playing catching up with SDK features.
- pkulak 5y agoWhat if the company that makes Kotlin is the one that makes the Java IDE?
- Twisol 5y agoEclipse and NetBeans do exist, and... ehhhhh. I used NetBeans for a long time; couldn't stand Eclipse; and these days I only use IntelliJ. But the others absolutely exist, and it'd be hard to say that Apache and the Eclipse Foundation aren't deeply embedded in the Java ecosystem.
- vips7L 5y agoEclipse is fine. Especially from VsCode where it uses the Eclipse language server. It boots fast, and when you run it with a modern JVM and GC the memory usage is leagues lower than IntelliJ.
- Twisol 5y ago> Especially from VsCode where it uses the Eclipse language server. Sure, but my particular complaint isn't with the functionality; it's with the UI. Yes, VS Code absolutely improves the experience.
- tadfisher 5y agoEclipse tried their own language: https://www.eclipse.org/xtend/ https://www.eclipse.org/xtend/
- pjmlp 5y agoThey make one Java IDE, zero contributions to the JVM, and are all cozy with "screw you Java devs" Google godfather. IBM does Java and the IDE (Eclipse). Red-Hat and Microsoft do Java and the IDE (VSCode).
- native_samples 5y agoThey contribute to the JDK, mostly via the Swing project. For instance they're a major contributor to Project Lanai.
- pjmlp 5y agoI missed that. Most likely because they are a long way to reboot InteliJ on Compose for Desktop.
- Skinney 5y agoIf you need multi-platform then coroutines is still your best bet. But many people don't use Kotlin in a multi-platform way, and lightweight threads will be an easier migration path (and more compatible with Java libraries if you cant avoid one) compared to coroutines.