Java is verbose but library ecosystem is amazing if you filter out the enterprise nonsense. Kotlin fixes the issue of verbosity and either fixes or largely masks most of the nasty legacy mistakes. Kotlin is still missing an option to force handling Java checked exceptions though.
Conversation
> Main reason to use [Python] has been dying
Kinda rejuvenated with machine learning, though.
1
I'd rather use the Java ecosystem via Kotlin though. It's nice not finding endless mistakes at runtime, being able to maintain your code and using multiple cores.
I still use Python a lot as my language of choice for throwing together a script, but I don't think that'll last.
1
2
I think JavaScript is gradually going to turn Python into another Perl and TypeScript is a big part of it.
Python is really bad at async (lack of ecosystem adoption), static typing, performance and scaling to multiple cores. All things that people find increasingly important.
1
1
Replying to
... JavaScript scales to multiple cores now?
I wonder what's going to replace Python as the language of choice in machine learning, then
1
Replying to
It has worker threads and is focused on message passing between them, but you can use a shared array buffers for a relatively low level shared memory API. It evolved that way due to the limitations of the language but it's nicer in a lot of ways than Java-style locking approach.
2
Replying to
... doesn't Python also have non-shared message passing multiprocessing. (I have used neither multiprocessing nor Shared Workers, though, so not sure if they're any similar.)
1
Replying to
Workers are generally implemented as threads rather than processes, but it's abstracted. Main reason it's a lot nicer is that the whole ecosystem is built around concurrency and it works nicely for that style of parallelism too. Python's approach is a very leaky abstraction too.
1
1
Everything in JS was built around async callbacks and got rebuilt around async/await/promises. You'll rarely find a case where I/O blocks a thread. Even stuff like open(), stat(), etc. is done in an async way, unlike stuff like nginx. Waiting for stuff from workers, etc. fits in.
1
1
Rust and C# have similar async support but it feels a lot worse than JS because the whole ecosystem wasn't built around it, and in Rust there are different conflicting approaches. Rust needs to be that way as a low level language but most other languages are just bad at this.
1
1
JS went from forcing endless callbacks on everyone to actually having an ergonomic approach that scales.
Go has an ergonomic approach to concurrency... but in a language that's super verbose and painful. I think Go's death sentence is that it can't scale to multiple cores well.
I think Go’s death sentence is that a lot of people just don’t really want to write it
3