6 ms·
Kotlin may be growing on GitHub, BUT Java has the "late-mover advantage": it will incorporate all good ideas from Kotlin & others into the language and it will
by pulse7 4y ago
Kotlin may be growing on GitHub, BUT Java has the "late-mover advantage": it will incorporate all good ideas from Kotlin & others into the language and it will skip on all failed ideas (like async/await, etc.). So the Kotlin advantage is shrinking - just like it happened with Groovy and others. The Java ecosystem is huge - you have libraries for just anything. And it is similar to Raspberry Pi vs other competitors: RPI has ecosystem, others are much smaller.
- yen223 4y agoCan Java steal top-level functions already?
- pulse7 4y agoJust use static methods for that. Disadvantage: you are forced to use package and class name spaces. Advantage: everything is inside some namespace.
- jrpelkonen 4y agoAgreed. I also find static imports handy to simplify the code at the call site.
- sshine 4y agoJava has historically been good at catching up when competing languages outran it. C# was a better language than Java for some years until Java caught up again.
- jen20 4y agoC# is still a better language than Java, despite the purported catching up.
- bennysonething 4y agoI primarily write c# for a living. What's wrong with async await in kotlin? I'd struggle to live without it in c#.
- pulse7 4y agoFunction coloring
- andix 4y agoAsync/await doesn’t change anything there. It just makes it easier to deal with.
- justoreply 4y agoWith the new thread model in java (project Loom) you don't need function coloring
- andix 4y agoI don't know the details. But a synchronous function returns a value and an async function returns something promise-like (it completes at some point and returns a value or an error). You can always call something async synchronously (by waiting for finishing). Or something synchronous in an async way (by putting it onto another thread). But there is no way to completely remove this fact from the eyes of the programmer. async/await is one of the ways to make it easier to read or write.
- nlitened 4y agoAsync/await is extra syntax and one more function color which you have to keep in mind, while being just a workaround for expensive threads. Recent Java has just made threads cheap, so async concurrency is much simpler and more consistent with existing libraries and APIs.
- pharmakom 4y ago
- joe_fishfish 4y agoI believe there are no plans to port Kotlin’s null safety to Java, which is possibly the biggest advantage Kotlin has right now. Once you’ve tried it there is no way you would want to live without it.
- pulse7 4y agoIf this is the "biggest advantage Kotlin has right now" then it doesn't have much added value... Would you rewrite existing code base with millions of lines of code just to get null safety? If THIS is the biggest advantage of Kotlin, then Kotlin is on the same path as Groovy was a decade ago... In order to replace Java and it's ecosystem one would need to offer MUCH MORE than just null safety...
- joe_fishfish 4y agoIt would depend on the state of that codebase, really. If it’s well tested and does its job well, I wouldn’t bother rewriting it at all. But certainly if I were to add new features to an existing Java codebase I’d use Kotlin. The interop between the two is fantastic and for me the null safety alone makes it worthwhile.
- kmac_ 4y agoAsync/await with futures/tasks/promises is really useful. Having async build in a language simplifies code and reduces boilerplate. Of course it introduces function "colors" as some say, but that's a good tradeoff imo as it's easy to handle (much easier than not having async/awiat). Java ecosystem is quite behind and won't catch-up because the language itself has some pain points like type erasure, nullable references (even C# got rid of that), etc. and that won't change ever. The most popular libraries and frameworks are stuck in time. Languages are moving forward and developers follow that, Rust, TypeScript show the way.
- Reason077 4y ago> "The most popular libraries and frameworks are stuck in time." When you're building software with a design lifespan of decades or more, this stability is advantagous. You don't want to have to go back and make big code changes (ie: pay increased maintanance costs) every few years because the libraries and frameworks you used are moving targets.
- blagie 4y agoI like async/await, but I haven't seen any language do it well. Doing it well would involve: 1) Not crashing-and-burning on simple "Hello World" level use-cases (e.g. working in a Python terminal, a 3-liner script, etc.) 2) Giving actual performance gains in typical cases 3) Allowing code to change in both directions, quickly and easily 4) Integrate well into other parts of the language (e.g. list comprehensions or iterators / generators in Python, or multiprocessing) I also don't like the amount of verbosity added. I can describe a system which would do all-of-the-above, but I don't think I could have independently invented it. It's based on using JS and Python async / await for a while, and understanding where things were done wrong. On a mile-high level, I'm also ultimately not sure this is the right model. We: - Created cooperative multitasking (e.g. in Windows 3.1 and earlies) - Found pre-emptive multitasking worked better, in part since people were bad at deciding when to release control - Re-invented cooperative multitasking within apps with async / await I think there is a more dynamic, higher-level programming model where I describe what needs to be done. Just-in-time profiling and optimization, decides what to do synchronously versus asynchronously versus in a new process versus e.g. on a GPU. An operation like: [functional_function(x) for x in l] Ought to sit on CPU synchronously if l is small and f is fast, in their own process asynchronously if they are medium, and on a GPU if they are massive and slow.