Live data from Hacker News

Scala 3.0

github.com

281–290 of 292 posts

Re: Scala 3.0

#281
post #198

Earlier quoted context omitted.

What's an example of something they made more approachable? One of my first impressions of Scala, which I have barely seen, and do not know, is that there is a lot of syntax. Has anything been done to help with that? I don't think syntax matters much, but it's one of the only impressions I have of the language and wanted to ask about it.

Scala is one of the smallest typed languages in terms of syntax. See slide 13: https://www.slideshare.net/Odersky/preparing-for-scala-3#13 With scala 3, syntax has been simplified even more, e.g.: No more braces necessary. Top level declarations. Extension Methods.

> Scala is one of the smallest typed languages in terms of syntax.

Eh, that slide isn't really worth looking into. None of the languages there have a uniform way to represent the grammar. If you look at the C# and Scala grammars you'll find that the Scala one is highly compacted, whereas the C# grammar is intentionally not compact. They're encoded in different formats.

Re: Scala 3.0

#282
Scala was a unique language a few years ago. I'm very happy I adopt it a few years ago and I owe it a lot. As a lot of other modern languages or features of mainstream ones do.

However, with the existing alternatives nowdays, Scala doesn't hold the same position. I have not coded in Scala for ~2 years and I'm not sure I'll ever need to.

Anyway, all the best for Scala's awesome team and its ecosystem.

Re: Scala 3.0

#283
post #268
post #197

Earlier quoted context omitted.

I've been extremely happy with IntelliJ plugin for Scala. I do use Visual Studio Code for Python,JS,web, etc. What would be advantage of using VS Code over IntelliJ for Scala?

I'm familiar with VS code and have a set up that I'm familiar with (shortcuts & settings) and I've only briefly looked at IntelliJ, so I'm not qualified to answer this question. What is the reason you're using IntelliJ rather than VS code?

Writing Scala with IntelliJ is just so fun - 99% of time I get the right suggestion for Scala and/or Java libraries that I have not imported yet.

Nice style suggestions that do not nag. Instant ScalaDoc generation. Pretty much picks up on all my brain farts.

I imagine it is because of deep integration with JVM - after all IntelliJ started with Java.

By comparison VS Code is just an editor underneath without the I in IDE.

Theoretically VS Code is a bit like emacs or vim, you can set it up to do everything for your language but it takes a lot of tweaking.

Re: Scala 3.0

#284

Earlier quoted context omitted.

How is current Scala not actually a Haskell competitor today? Superficial dislike of a VM isn't a valid reason.

Haskell's runtime is just better for pure FP than the JVM. GHC's optimizations and general TCO go a long way.

‘Just better’ is not a valid argument. Better at what? Better for what use cases?

If we start to treat software like fashion, I don’t think we’re going to make very good decisions in the coming years.

Re: Scala 3.0

#285
post #269

Earlier quoted context omitted.

Not sure what Play Framework is doing at the top of the list, will most likely be many months before a Scala 3 supported version is released. Same for Spark, DB libraries, Akka, etc. Basically everything with large dependency graphs that depend on macros or removed Scala 2 features (e.g. abstract type projections, arghhhh) will take significant time to port over to Scala 3. What has had Scala 3 support from early on…

Is Play Framework still used/developed? Haven't seen any progress from performance in the last years. Happy to get corrected, though.

It probably is still the most used framework, probably by quite a margin. Whilst I mostly use Http4s these days I would guess the majority of new projects still pick Play. I would say 60% but would not be surprised if the actual number is 95%.

The silent majority just need to chuck out another internal app quickly and Play is great for that.

It also looks like it is still heavily developed as 2.9 is released soon.

As for performance, shrug.

Re: Scala 3.0

#286
post #236

Earlier quoted context omitted.

There are almost 3 billion Android devices. I think you underestimate the scope of the primary language on one of the world's most prolific OS's.

There aren't as many mobile developers as you'd think: https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/

That article is from 2019 and only focuses on languages. At that time most of the Android jobs would be hopelessly intertwined with the Java jobs.

It's also important to not be US centric. In many parts of the world Android is the dominant OS.

Re: Scala 3.0

#287
post #257

Earlier quoted context omitted.

To take Loom as an example.. The primary problem with threads isn't their performance, but the way that they encourage bugs and race conditions by decoupling data access from flow control. They're fine as a low-level API for implementing a more usable API, but not as the primary API that you expect application developers to use.

Java/the JVM provides a low-level API for threads on top of which abstractions can be built. How do you think clojure implements their parallelism? And Loom will be absolutely killer feature, it’s not about performance, it’s about blocking. Abstraction built on top of them will be easier to reason about, no callback hell, etc.

> Java/the JVM provides a low-level API for threads on top of which abstractions can be built. How do you think clojure implements their parallelism?

As I already wrote? But doing M:N scheduling at the JVM level (which is ultimately what Loom is) won't help your future (/promise) runtime which already implements a thread pool internally.

> And Loom will be absolutely killer feature, it’s not about performance, it’s about blocking.

If you like the blocking model and don't care about performance then you can go and use native OS threads in the same way right now.

M:N scheduling (including Loom) is ultimately about making threads cheaper to create, which means that theoretically you can have the "best" of both worlds (performance of futures, API of threads). My point is that this is a nonsensical goal, because the API of threads is awful.

> Abstraction built on top of them will be easier to reason about, no callback hell, etc.

Until you try to introduce concurrency, at which point you're back to the hellscape that is manual multithreading.

Re: Scala 3.0

#288

Earlier quoted context omitted.

Haskell's runtime is just better for pure FP than the JVM. GHC's optimizations and general TCO go a long way.

‘Just better’ is not a valid argument. Better at what? Better for what use cases? If we start to treat software like fashion, I don’t think we’re going to make very good decisions in the coming years.

I mean "just better" at every use-case? It eliminates the cost of functions where JVM languages cannot due to its limitations. I really don't think I'm treating software like fashion - I'm speaking from years of practical experience here.

The main thing FP on the JVM does better is be permitted by your employer lol. So if we're talking runtime vs runtime, there's no use-case. In general, it's all soft/social reasons.

Re: Scala 3.0

#289
post #283
post #268

Earlier quoted context omitted.

I'm familiar with VS code and have a set up that I'm familiar with (shortcuts & settings) and I've only briefly looked at IntelliJ, so I'm not qualified to answer this question. What is the reason you're using IntelliJ rather than VS code?

Writing Scala with IntelliJ is just so fun - 99% of time I get the right suggestion for Scala and/or Java libraries that I have not imported yet. Nice style suggestions that do not nag. Instant ScalaDoc generation. Pretty much picks up on all my brain farts. I imagine it is because of deep integration with JVM - after all IntelliJ started with Java. By comparison VS Code is just an editor underneath without the I in…

Sounds nice. I'll try it out!

Re: Scala 3.0

#290

Earlier quoted context omitted.

‘Just better’ is not a valid argument. Better at what? Better for what use cases? If we start to treat software like fashion, I don’t think we’re going to make very good decisions in the coming years.

I mean "just better" at every use-case? It eliminates the cost of functions where JVM languages cannot due to its limitations. I really don't think I'm treating software like fashion - I'm speaking from years of practical experience here. The main thing FP on the JVM does better is be permitted by your employer lol. So if we're talking runtime vs runtime, there's no use-case. In general, it's all soft/social reasons.

Ah yes - you've reduced all of the JVM down to a terrible piece of software that doesn't power a tremendous portion of the software on planet Earth.

This is when I know to not consider a person's comments seriously. When they even wear their bias on their sleeve.

Post reply on HN