Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala 3.0

github.com

Post reply on HN
Print view View original

201–210 of 292 posts

Re: Scala 3.0

#201

Post by adamgordonbell »

valenterry wrote: post #175
agbell wrote: post #141

Earlier quoted context omitted.

Rumor has it Kotlin was inspired by frustrations getting Scala edge cases to work in IntelliJ.

I don't believe that this is true. Because, one can just write simple Scala and has pretty much everything that Kotlin has (minus its nullability magic) and never deal with these edgecases. Even compiletimes are decent then. But with Kotlin, it is actually enforced that the more advanced features of Scala are not available, so it makes sure that compiletimes etc. stay short. It also simply reduces the burden of the I…

I love Scala.

The thing is as an IDE author you can't just "write simple scala" because you aren't the author, you are the IDE. You have to be able to offer your refactoring tools and other tooling for all of it and cover all the edge cases.

LSPs do remove this problem to a large extent though.

Re: Scala 3.0

#202

Post by AtlasBarfed »

killingtime74 wrote: post #9

Scala is not perfect but it’s very good. It’s competitive pressure arguably improved Java (streams, pattern matching, data classes).

Most new Java language features seem to chase groovy features more than others, but then again many of the jvm langs do similar features to extend ahead of java's limitations.

Re: Scala 3.0

#203

Post by peq »

sesm wrote: post #119

So, they removed implicits and introduced a number of other tools to replace common usecases for implicits. Can we take a step back now, and reflect on what was the original problem implicits were designed to solve and how it is solved now in Scala 3? I've heard the original problem was that they wanted a chain of functional transformations to return the same type of collection (unlike, say, Clojure or Java 9 which r…

I think implicit conversions were added originally to support Java compatibility without boilerplate code.

It then turned out that they could be used to simulate extension methods, which is probably the main use case for implicit classes in Scala2.

And implicit parameters were probably just the result of trying to make type classes modular.

The CanBuildFrom approach came later than implicit parameters (https://stackoverflow.com/questions/1722726/is-the-scala-2-8...).

Re: Scala 3.0

#204

Post by RhodesianHunter »

kaba0 wrote: post #190
RhodesianHunter wrote: post #188

Earlier quoted context omitted.

You keep claiming that the language team's knowledge of a feature drives that feature's adoption. That's not accurate. Popularity of a feature and enterprise demand drive it's adoption. It doesn't really matter what the language team knows, it matters what the average developer knows since their collective wants are in large part what drives the language team. There are hundreds of thousands of Java devs who only eve…

I would agree with you, Java routinely uses the "last-mover's advantage" tactic, but I think you overestimate the relative sizes of the two languages. These are all very basic FP "features"/language primitives, and Java is steering strongly towards becoming an ML-inspired FP-enhanced language. If anything, the acceptance of more parts of the FP paradigm into all major languages (like C#, JS/TS, C++) starting with lam…

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.

Re: Scala 3.0

#205

Post by stock_toaster »

peq wrote: post #198
Buttons840 wrote: post #168

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.

> No more braces necessary

Optional braces seems like a weird feature to me. I would prefer consistently. I think a language should either be "bracey" or not. Just pick one!

Re: Scala 3.0

#206

Post by jmfldn »

A big moment for Scala. I've used it professionally for 5 years and am still in love with it. The expressiveness, the power, everything about it is a joy. This just takes it to another level by removing a few warts and simplifying it whilst adding some amazingly useful new features. A really tricky balance needed to be struck.

I think they've pulled off an unlikely and amazing feat with this release.

Re: Scala 3.0

#207

Post by oxnrtr »

peq wrote: post #198
Buttons840 wrote: post #168

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.

Joking? Scala 3 added 20 keywords (14 of them contextual), many of them with entirely new syntactic constructs behind it.

Re: Scala 3.0

#208

Post by hocuspocus »

neysofu wrote: post #192
mnd999 wrote: post #184

Earlier quoted context omitted.

It’s a shame it’s got less opinionated in other ways. Scala developers must be really looking forward to the endless debates over curly brackets vs white space.

I still can't believe they went for that. I wouldn't really care if the team wanted to switch to significant indentation, but it's absurd to provide two altogether different syntaxes just for the sake of it.

It isn't for the sake of it, breaking source compatibility would have been a major annoyance.

Re: Scala 3.0

#209

Post by pron »

RhodesianHunter wrote: post #188
kaba0 wrote: post #169

Earlier quoted context omitted.

That’s irrelevant. It’s not like the language team didn’t know about these features. The change to the shorter release cycle and increased funding is much more behind the speed up of updates regarding Java.

You keep claiming that the language team's knowledge of a feature drives that feature's adoption. That's not accurate. Popularity of a feature and enterprise demand drive it's adoption. It doesn't really matter what the language team knows, it matters what the average developer knows since their collective wants are in large part what drives the language team. There are hundreds of thousands of Java devs who only eve…

1. That's not really right. You're correct that "readiness" is important, but Python and JS are much bigger forces than Kotlin, and the main reason Java is getting features faster is because the investment in the platform has grown (and Kotlin was created when it was at an ebb). But so far, almost all linguistic features added after 1.0 -- generics, lambdas, type inference, ADTs, patterns -- are inspired by ML.

2. Java addresses those topics (where relevant) pretty much in the opposite way from Kotlin. Java rejected coroutines and is going down a completely different path with virtual threads; Java rejected data classes and chose to go down algebraic data types. So if you think Java gets inspiration from Kotlin, then it is in the form of what not to do.

Re: Scala 3.0

#210

Post by The_rationalist »

zeec123 wrote: post #195
emergentorder wrote: post #181

Earlier quoted context omitted.

Check out my project NDScala ( https://github.com/SciScala/NDScala ). N-dimensional arrays in Scala 3. Think NumPy ndarray, but with compile-time type-checking/inference over shapes, ndarray/axis labels & numeric data types.

Thanks. Does it map to native routines like numpy? If yes, what about the copy overhead from JVM to native memory?

Nd4j (another project) enable to use cuda/MKL sota backends. It does native calls but I don't think the overhead is high. Besides some of those overhead are being optimized in the JNI successor.
Post reply on HN