Live data from Hacker News

Scala 3.0

github.com

251–260 of 292 posts

Re: Scala 3.0

#251
post #249

Earlier quoted context omitted.

That doesn't read to you like it was intended to be a new language?

I take it to mean a new version of Scala.

For me it sounds like neither.

More of "we make this condensed core, based on Scala - and if we are lucky and it turns out that the current Scala core can be made sound easily, then it will become Scala 3, else it will be a completely separate language".

E.g. if it would have turned out that you can't make implicits sound, then I doubt that dotty would have become Scala 3. With existential types however, they decided to remove this feature (which is a bit sad imho) and sacrifice it to make dotty become Scala 3.

Re: Scala 3.0

#252

Earlier quoted context omitted.

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.)

Because it enables an equivalence between functions and objects. Not a technical one that's hidden deep in the implementation, but a practical one that's apparent to library authors and users.

If you want to make any object `foo` callable with first-class application syntax, i.e. `foo(bar)`, you add an `apply` method to that `foo`. You don't need to bother extending Function, you don't need to come up with a method name and call that. When you call `foo()`, you don't know if `foo` is a function or an object, and you don't care. You can find out easily with a half decent editor of course, but the point is, you're free to mix objects and functions as you wish, the language does not get in your way.

And for all that it provides, it's a complete non-issue in terms of learning curve. It's a basic language feature that you learn once and are never impeded by thereafter.

Re: Scala 3.0

#253

Earlier quoted context omitted.

Can you elaborate on the changes in TS that hint at dependent types? That's interesting.

I'm not referring to some specific changes. It's just there are many type operators already and still not enough to express JavaScript. In the earlier versions of TypeScript, I often stuck with something natural in JavaScript but cannot express the same thing with type annotations - It's like opening a pandora box, once some advanced type operators have been introduced, whenever I played with them I would quickly fou…

Someone claimed the type system of typescript is turning complete. This example shows how to derive types from string based sql statement: https://github.com/codemix/ts-sql

Re: Scala 3.0

#254
I haven’t kept up with Scala but the LLVM target looks pretty interesting. Is anyone deploying it this way?

Re: Scala 3.0

#255
post #103

Earlier quoted context omitted.

I totally agree. I love the direction of Scala 3. This quote says it all I think: "Scala 3 takes a slightly different approach [from Scala 2] and focuses on intent rather than mechanism. Instead of offering one very powerful feature, Scala 3 offers multiple tailored language features, allowing programmers to directly express their intent" So rather than something like implicits, that can be used N different ways, onl…

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

I'm a programming language design geek... Out of curiosity, could you explain some of the ways you've been bitten by implicits?

Re: Scala 3.0

#256
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 :-)

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…

> Some parenthesis are optional: Some(1,2,3) is Some((1,2,3))

There's a compiler warning against this syntax that everyone should really enable.

Re: Scala 3.0

#257
post #182

Earlier quoted context omitted.

Wat? How is the recent trajectory disastrous?

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.

Re: Scala 3.0

#258
Does Scala have a chance to regain popularity?

It was my main language for 5 years, and there was always a variety of Scala jobs in Berlin: companies of different industries, sizes. Recently, I mainly used Python at work. I love Scala and wonder if it makes sense to invest in keeping up my Scala 3 skills.

Re: Scala 3.0

#259

Does Scala have a chance to regain popularity? It was my main language for 5 years, and there was always a variety of Scala jobs in Berlin: companies of different industries, sizes. Recently, I mainly used Python at work. I love Scala and wonder if it makes sense to invest in keeping up my Scala 3 skills.

It looks like it's not the case, at least looking at: https://germantechjobs.de/jobs/Scala/all or https://swissdevjobs.ch/jobs/Scala/all

Re: Scala 3.0

#260

Earlier quoted context omitted.

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

I'm a programming language design geek... Out of curiosity, could you explain some of the ways you've been bitten by implicits?

I will never forget the hours I lost debugging an issue where I had not realised that if you declare any variable in scope that coincidentally has the same name as an implicit that you're relying on, the implicit will be shadowed and unable to resolve. Of course, it 'makes sense' when you consider that you would be unable to refer to it by name explicitly... But if you're not using the name, the fact that it can have an impact on visibility is pretty confusing
Post reply on HN