Live data from Hacker News

The Road to Scala 3

scala-lang.org

181–190 of 196 posts

Re: The Road to Scala 3

#181

Earlier quoted context omitted.

We're writing new apps in Kotlin instead of Java, works fine for us. shrug Vert.x , Ktor apps, Kafka streaming apps. IDEA handles it absolutely fine these days, I suspect you last tried it sometime ago. Can't comment on the Gradle stuff though, I vastly prefer Maven.

Is vertx better than ktor for production?

Vert.x is doing us well for high volume apps, Ktor is early stages but looks alright also. That said, haven't benchmarked identically feature compete implementations of the same app in both, so don't really have the metrics to properly compare, but so far at least, it seems comparable.

Re: The Road to Scala 3

#182
post #29
post #3

I really love Scala, but I worry about its future given Google putting its weight behind Kotlin, and the two offering a lot of the same features and philosophy. Does anyone know if the Scala maintainers have addressed this directly?

Kotlin wins also because it has a stable and usable Native flavor. Scala Native is a third-party project and seems dead, while Kotlin Native is the core part of the Kotlin language and being developed at a fast pace.

Kotlin/Native is not semantic compatible with Kotlin code written for the JVM without any regard for other platform's existence.

Then there is the total lack of access to the huge JVM eco-system, a less performant automatic memory system, and AOT playing catchup with AOT/JIT tooling available for the JVM, some of which with battlefield experience in production since the early 2000's.

And then there is the whole thing that JetBrains gladly sells CLion licenses for the whole development experience with Kotlin/Native.

Re: The Road to Scala 3

#183
post #165

Earlier quoted context omitted.

Scalas insane generic type system would be an example of them going wrong. The current proposed Go method seems fairly reasonable.

I'll give an example of the Scala type system: let's define combining 2 integers as adding them together, then combining 2 lists of integers will give a new list where an element is the result of combining of 2 elements in the given 2 lists. Now we can make it a bit more generic: if a type A has a method combine, then 2 lists of elements of type A can be combined together to give a new list of which each element is f…

It would depend on how generics are implemented in Go, with the current proposed implementation that would be possible. Without generics today you could use an interface, wouldn't be as pretty but would get the job done.

Re: The Road to Scala 3

#184
post #2

When I gave up on Scala in 2016, I did so because its future looked fragmented and uncertain. Fast forward more than three years, and the first release of Scala 3 won’t be out until another year from now. Compare this with the pace of development of Go or Rust: those languages are driven by a vision, and have a dedicated team behind them. Scala is declining because no one could figure out for the longest time what wa…

Love all the Scala fanboys on here downvoting anything to do with Go being better. Run Scala in prod for a couple years then run Go in prod for a couple years and tell me with a straight face what makes more sense. Scala was such a massive waste of time :)

Re: The Road to Scala 3

#185
post #78

Earlier quoted context omitted.

Having led engineering at a startup that developed ~95% of our code in Scala and then moving to a FANG team that developed most of its services in Java (still using Spark Scala to a large degree and beginning to introduce Kotlin), these are the reasons I can use to justify using Java over either: 1) it is already there, 2) most engineers know Java well [enough], 3) other teams predominantly use Java and it makes cert…

> Java is another boring language, but it's also a very verbose one, even when fully utilizing Lombok/G-libraries/etc.. Incidentally, I find golang to be more verbose than Java. The amount of one-off functions you have to write to get around the lack of generics and/or map/filter calls on collections makes the code longer and harder to follow, and harder to debug. Not to mention error handling. I generally agree with…

https://github.com/robpike/filter

Re: The Road to Scala 3

#186
post #57

Earlier quoted context omitted.

What is the story with Scala on Android? Years ago I thought it was a matter of using too much memory. There’s not much talk about it but it does seem to be possible: https://scala-android.org/ Will Scala 3 help?

I don't know the whole story. Perhaps somebody who knows can chime in. But my impression is that Android being stuck basically on pre-Java 8 at the time while Scala relying heavily on Java 8 features was one complication. Scala generating a bunch of class files for lambdas and so on with no SAM types + invokedynamic to reduce all that plus strange DEX limitations might have caused issues. Plus memory limitations like…

> not sure there are any real blockers for Scala on Android anymore. I imagine it's mostly a resource problem now

not really, it's still the problem Android being Java https://github.com/scala-android/sbt-android/issues/334#issu...

Re: The Road to Scala 3

#187
post #79

Earlier quoted context omitted.

F#?

F# is quite nice. I used it a long time ago for a couple of libraries when I was working in a team that mostly used C#. Fable looks really cool too. I remember getting the feeling that C# is holding it back though. F# can't have any feature that it wants because interop in both directions seems to be a priority. If I recall correctly, that's what is holding back higher-kinded types in F#. That, and the last time I tr…

> C# is holding it back though

not as much C# the language, as CLR, the runtime. Because of reified generics, which is the way things are done in the .NET world, and which the runtime needs to support, it would also require explicit support in the runtime for Higher-kinded types or Type classes. And that won't happen without C# having these features (and having them first).

F# is really really great, but it is like an unwanted child of Microsoft :(

https://github.com/fsharp/fslang-suggestions/issues/175

Re: The Road to Scala 3

#188

Earlier quoted context omitted.

Scala’s type system goes far beyond simple generics.

and thats fine in an academic setting, but please don't bring that into the real world unless you have a really good use case.

it's working fine in the real world enterprise setting too ;)

Re: The Road to Scala 3

#189
post #67

Earlier quoted context omitted.

I'll speak for myself. I just jumped ship from a Scala team and took a pay hit to get out because it was so horrible. No one on the team had a strong command of the language, which made it worse. The application was a ball of mud. The week I left, proposals to rewrite everything in Java were heard. I took a position on a Go team and am much happier.

I wouldn't jump ship to a Go project, but I am currently in the situation you fled from. Even the core team who started the project doesn't have command of the language. I have some experience with rust and Haskell (hobby) and JVM experience with Java and clojure so I can get by but it is not pleasant. I think the situation is similar to c++ where too many features have been added over time. While with c++ there is a…

> for scala that doesn't really exist

https://nrinaudo.github.io/scala-best-practices/

Re: The Road to Scala 3

#190

Earlier quoted context omitted.

and thats fine in an academic setting, but please don't bring that into the real world unless you have a really good use case.

it's working fine in the real world enterprise setting too ;)

I've seen nothing but chaos in every org thats adopted it and they all moved to java/kotlin/go, only place I've seen it successful is around Spark. Usage stats back this up
Post reply on HN