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

231–240 of 292 posts

Re: Scala 3.0

#231

Post by maxov »

The_rationalist wrote: post #215
maxov wrote: post #17

Earlier quoted context omitted.

As someone who has spent a lot of time diving deep into Scala (I worked on compiler related semantic tooling for scalameta, worked on a experimental parallelizable Scala compiler, and even have a single commit in this release from almost four years ago LOL), and who more recently has been working with TypeScript, I find this really interesting and agree in some ways. Scala 2.x already had path-dependent types, which…

What does the typewritable type do/allow?

I'll give some brief context first for why it could be useful, then explain what DeepWritable does. AWS Amplify JS has a library called DataStore that takes GraphQL schema and generates ActiveRecord-like model classes (https://github.com/dabit3/amplify-datastore-example/blob/mas...). Then you can create, query, update, and delete these models in your web app client. The generated classes have are immutable and have read-only fields by default. This means none of the model objects will change under you before they've actually been persisted, which is a good guarantee to have IMO.

To make updates, you create a new model object with the same ID and whatever changes you need, and persist it back. DataStore uses an immer-like mechanism where each model object has a copyOf method, to which you pass a function that takes a mutable version of the model and makes whatever mutations. Then the copyOf method returns a copy of the model object that has all the new field values, leaving the original object the same. The DeepWritable type expresses the "mutable version" of the model by making all fields writable, so for example the TypeScript compiler won't yell at you for writing to fields on the mutable version of the model. It also does this recursively for any fields whose type is an object that isn't a primitive.

Re: Scala 3.0

#232

Post by dyadic »

nikitaga wrote: post #223
patrickthebold wrote: post #199

Earlier quoted context omitted.

Scala has a lot of 'sugar': f(...) becomes f.apply(...) matching calls unapply with some various binding. Some parenthesis are optional: Some(1,2,3) is Some((1,2,3)) optional . so a + b is a.+(b) colon changes associativity, so a +: b is b.+:(a) for expressions become, map, flatMap, filter, withFilter and forEach, according to various rules. def f[A: B]() adds an implicit parameter of type B[A] I'm sure there's more…

The fact that you can make any instance callable like a function by adding an `apply` method to it isn't just "syntax sugar", it's a pretty fundamental mechanic of FP-OOP fusion that Scala is built around. Same for `unapply`. At any rate none of this "sugar" was a problem to anyone I know who learned Scala. There are harder things about it than learning basic syntax.

It’s a long time since I used scala and none of this was ever a direct problem, but it was all extra complexity. I think there’s a split between people that appreciate sugar and people that find it not worth the additional complexity.

That problem does lessen with familiarity, but knowing a lot of complexity makes me wary of unknown complexities. It adds an overhead which takes energy that could be better utilised elsewhere.

Re: Scala 3.0

#233

Post by loganhood »

halfmatthalfcat wrote: post #216
RhodesianHunter wrote: post #138

Earlier quoted context omitted.

Most F500's with large Java codebases including Google and Amazon are already betting big on Kotlin for server side development.

Source? Never seen or heard a major F500 pick up Kotlin as their primary backend lang over Java.

I'm an SDE at AWS. Many teams including mine are using Kotlin for backend dev.

Re: Scala 3.0

#234

Post by ovis »

darksaints wrote: post #136
swader999 wrote: post #135

Earlier quoted context omitted.

The days I spent chasing implicits are still lost to me forever.

They should have never been a language feature before IDEs were capable of working with them and exposing them. Luckily they do now...but Scala 3 makes it so that understanding them with a simple text editor is much easier. The fact that they have to be imported in a way that acknowledges their usage is a simple but important way to ease that burden, and the distinction between `given` and `using` is extremely helpfu…

Do you think IDEs would have grown support for them before they were a language feature?

Re: Scala 3.0

#235

Post by lolinder »

xfer wrote: post #79
isbvhodnvemrwvn wrote: post #22

Earlier quoted context omitted.

I think apart from streams it was Kotlin that did the trick.

Kotlin doesn't sound like a good language to bet on since most suitable(for jvm) features it has will be integrated by Java now that it has picked up pace. I guess it only has decent marketshare because of google's android support(they are throwing stuff on the wall to move away from Oracle IP i guess) and Jetbrains being very popular among java devs.

I'll be sticking with Kotlin at least until Java can do better at killing null pointers than @NotNull. Optional is good, but not widely used enough to handle most cases.

Re: Scala 3.0

#236

Post by pron »

RhodesianHunter wrote: post #204
kaba0 wrote: post #190

Earlier quoted context omitted.

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.

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

Re: Scala 3.0

#237

Post by tormeh »

valenterry wrote: post #177
OOPMan wrote: post #170

Earlier quoted context omitted.

That's an interesting take, as someone that's used Scala for a while I feel like there actually isn't that much syntax. I guess my perception is warped :-)

I agree. But Scala still does certain things different, so to a Java or python dev it _looks_ as if there is a lot of syntax. Just like Haskell looks strange when you look at it for the first time.

I don't think people object to the language syntax itself, but rather the unfamiliarity and randomness of language conventions. Haskell/Perl/K/Scalaz is full of line noise I can't be bothered to learn, for example

Re: Scala 3.0

#238

Post by kag0 »

flurdy wrote: post #117
haolez wrote: post #111

I'm in need of a functional language for a small part of my system and I'm considering Scala and Purescript[0] (mostly because of their ecosystems). Maybe Scala 3 is a good time to be boarding Scala's ship. I'd appreciate if anyone has any advices of one vs the other. [0] https://www.purescript.org/

I wouldn't jump on the Scala 3 ship just yet. Maybe if mostly a learning project but not for an important part. Whilst it was not a surprise release there will be long time until a majority of the libraries and frameworks will also work with it. The big ones are mostly there, but there are lots of smaller ones that are not and there will be teething problems, even after a long alpha-beta-rc train. Scala 2.13 is still…

I agree. But would note that scala 3 is compatible with 2.13 libraries, so long as they don't use scala 2 macros.

I think scala 3 is ready to go for production use, but it did come out yesterday. So waiting a tick would be prudent.

Re: Scala 3.0

#239

Post by kag0 »

Barrin92 wrote: post #19

Always wanted to look into Scala but it seemed very intimidating. Is there a good intermediate 'How to' for Scala 3 anyone can recommend?

You could check out Scala for

JavaScript Developers https://docs.scala-lang.org/scala3/book/scala-for-javascript...

Python Developers https://docs.scala-lang.org/scala3/book/scala-for-python-dev...

Java Developers https://docs.scala-lang.org/scala3/book/scala-for-java-devs....

for a quick introduction

Re: Scala 3.0

#240

Post by patrickthebold »

nikitaga wrote: post #223
patrickthebold wrote: post #199

Earlier quoted context omitted.

Scala has a lot of 'sugar': f(...) becomes f.apply(...) matching calls unapply with some various binding. Some parenthesis are optional: Some(1,2,3) is Some((1,2,3)) optional . so a + b is a.+(b) colon changes associativity, so a +: b is b.+:(a) for expressions become, map, flatMap, filter, withFilter and forEach, according to various rules. def f[A: B]() adds an implicit parameter of type B[A] I'm sure there's more…

The fact that you can make any instance callable like a function by adding an `apply` method to it isn't just "syntax sugar", it's a pretty fundamental mechanic of FP-OOP fusion that Scala is built around. Same for `unapply`. At any rate none of this "sugar" was a problem to anyone I know who learned Scala. There are harder things about it than learning basic syntax.

Why do you consider it fundamental? Are there examples where it fundamentally does more than saving you from typing out the canonical method name? (This is for `apply`, I agree that match with unapply is actually language syntax and not sugar.)
Post reply on HN