Live data from Hacker News

Towards Scala 3

scala-lang.org

181–190 of 383 posts

Re: Towards Scala 3

#181

Earlier quoted context omitted.

For what it's worth, this isn't just an evolution of the language, but a complete rewrite of the compiler. I appreciate that they're taking the time to do it right. They probably could've pushed new, non-trivial features out faster if they weren't doing a total rewrite.

This does nothing to change my opinion that total rewrites are almost always a horrible idea.

The old saying: "Its bigger and slower, but at least its more expensive!"

My experience says, a rewrite just has different bugs. Combined with delay and cost, its often not worthwhile.

Re: Towards Scala 3

#182
post #140

Earlier quoted context omitted.

When interacting with a Java library, I use scala.collection.JavaConversions to convert any Java structures to the equivalent Scala collection. Once I'm done operating on the collection (map, filter, etc.), I convert it back to Java.

You should be using scala.collection.JavaConverters instead, as it makes the conversion explicit (by adding a ".asScala"/".asJava" method to collections). Implicit conversions (i.e. where a type is silently converted to another type) is dangerous and can lead to very surprising problems.

Whoops, my bad about that. I was on mobile and forgot which of the two provides `.asScala`...

Re: Towards Scala 3

#183
post #148
post #122

Disclaimer : I'm nobody important, but I do have an opinion If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem. I used to write a lot of scala, and working with sbt was enough to eventually get under my skin. I really like some of the OOP aspects of scala, the left-to-right style of thinking matches how my brain works. Scala having a lot to offer can distract n…

The thing with Scala if you’ve come from OCaml is there’s no substitute for real Hindley-Milner, and the Scala object system isn’t good enough to compensate

Does anyone use Scala in cases where OCaml is a viable option? My impression has always been that Scala is "better than OCaml if you need the JVM"

Re: Towards Scala 3

#184

Earlier quoted context omitted.

Not directly, no. You’re probably thinking of ATC.

I thought this RFC was for HKT only: https://github.com/rust-lang/rfcs/issues/324 this is the one I have been paying some attention (not like I use HKT that often in Scala anyway)

That’s not an RFC; it’s just an issue where people talk about things. Actual RFCs are PRs to that repo that contain a design.

You are right that it’s purely about HKT though.

Re: Towards Scala 3

#185

How have people faired with Scala integration with Java libraries? When Scala first came out, I liked the idea. If I wanted to use X library, great, I can. As I pondered it more, this seemed terrible. Say I hug the functional side of Scala. I know what I'm doing. Then I hire a Jr Dev. She comes from the world of Java/Python where functional is no as big of thing (keeping in mind that while Python does support, to a d…

I’ve programmed in Scala most days for the past 3 years, we use plenty of Java libraries, and it works well. Generally it’s as simple as a thin wrapper around the library, that converts mutable data classes to immutable versions (or vice versa), and wraps blocking methods in futures. Sometimes it’s more complex than that, but when I’m reaching for a Java lib, normally it’s just for a few methods that are easily wrapped.

Re: Towards Scala 3

#186
post #23
post #2

Just curious, what companies (or kinds of companies) are betting on Scala nowadays? It seems that the people wanting "better Java" all decided they like Kotlin, and the functional programming people now gravitate more towards either F# (for .NET ecosystem) or OCaml/Reason (for the more unixy world). And the academic/research/learning crowd seems to like Haskell more. Who's still in Scala boat? Are Google or Fb or oth…

Yeah, I don't think Scala 3 changes anything with regards to perception and/or adoption of Scala. That ship has pretty much sailed. Martin Odersky seems like a really good language designer. I took a look at the Scala 3 languages features, and a more radical departure from historic Scala probably would have helped Scala.

> a more radical departure from historic Scala probably would have helped Scala.

Maybe. But high-risk. See Perl 6.

Re: Towards Scala 3

#187
post #146

Earlier quoted context omitted.

sbt is terrible, and I have a lot of respect for Li as "the scala.js guy", but I'm slightly baffled that YABT (yet another build tool) was really necessary vs. just making the existing (say) gradle experience super-polished. Granted, it's probably more fun to start from scratch :-), just seems more realistic for long-term adoption/maintainability to leverage existing tools.

I've never understood what SBT was supposed to solve in the first place. A Maven plugin that supports cross-building, which we're finally now getting with Scalor, seems like what the language actually needed.

https://www.acronymfinder.com/Sucks-Big-Time-(SBT).html

Re: Towards Scala 3

#188
"Scala has pioneered the fusion of object-oriented and functional programming in a typed setting."

What about Ocaml (1996, well before scala) and F# (2005, not too long after scala)?

Re: Towards Scala 3

#189
post #97

Earlier quoted context omitted.

Three or four years ago the biggest criticism of Scala was that releases were breaking backwards compatibility too much. On this very thread you'll find people worrying that Scala 3 will create a Python 2/3-style endless awkward transition. At this stage it's a mature language with a big established ecosystem, it can't afford to break too radically. (Did you have specific breaking changes in mind? The most important…

I wouldn't have called it Scala 3. And if I had the big brain of Martin Odersky, 5 years ago I would've had started thinking about an intermediate step in programming productivity, correctness - instead of doing Doty. I don't follow Scala that much anymore, but it seems that it's mostly a reworking of the internal consistency of Scala from an implementation perspective. At least that was the gist of it I got from wat…

> 5 years ago I would've had started thinking about an intermediate step in programming productivity, correctness - instead of doing Doty.

Wait what? In the last post you were complaining it was too close to existing scala, now you're saying it's too big a step? Again, what is the change you're actually advocating?

Re: Towards Scala 3

#190

Earlier quoted context omitted.

From an abstract PL theory POV, Haskell's key innovation over ML was HKTs. It was an experiment at the time, but one that was successful beyond all expectation: I cannot imagine designing a new PL without HKTs. (Note that Rust is also trying to add HKTs, but has been running into difficulties with type-based lifetime tracking IIRC.) Implicits are a generalisation of default arguments (I don't know where they were pio…

> Implicits are a generalisation of default arguments. There is an extreme semantic difference between an implicit parameter and a default argument. Have you spent any time at all using them? That's like claiming HKT is just a generalization of type constructors. Would you claim that HKT isn't anything new or novel because constructors have been around forever?

> Have you spent any time at all using them?

Sure I have used both.

Default arguments and implicits both have the same key idea: you can omit arguments to functions, and the compiler, guided by type information, synthesises the missing arguments during compilation. In order to understand the difference between both, it is crucial to realise that this compile-time synthesis of missing arguments has two related but different dimensions.

- Declaration that an argument is allowed to be omitted (and hence synthesised automatically).

- Declaration of the missing argument that is used in this synthesis.

Default arguments merge these two into one, e.g. with

   def f ( int x ) ( bool b = false ) = ...
   f (2)
   f (2)
all calls f(2) become f(2)(false). The problem with this is that the devault value to be used in synthesis cannot be context dependent.

Implicit arguments separate these two, enabling the programmer to make default context dependent, e. g.

   def f ( int x ) ( implicit bool b ) = ...
   implicit val c = true
   f (2)
   implicit val c = false
   f (2)
Now the first call f(2) is rewritten to f(2)(true), while the second becomes f(2)(false).

> Would you claim that HKT isn't anything new or novel because constructors have been around forever?

I'm not sure I see the connection: constructors are program constructs, while HKTs are "types for types".

Post reply on HN