Live data from Hacker News

The Road to Scala 3

scala-lang.org

81–90 of 196 posts

Re: The Road to Scala 3

#81

Earlier quoted context omitted.

Go is just barely statically typed though, with its lack of generics. Some day soon, it will tacked onto the language; a language that wasn't designed with that in mind. I don't know about pace, but in absolute terms, Go is far behind even the oldest versions of Scala.

That would be missing the point of Go. It’s not as though the Go team is incapable of introducing genetics they just took a hard line on not putting anything into the language that wasn’t absolutely needed. This built a simpler language and because of that a stronger community, which is why Go has all but entirely eaten scalas lunch

IMO this would be a bet that the Go team does not implement generics in the vague near future. There's a difference between the Go team making a fundamental design judgment against generics vs the Go team feeling that no super-obvious proposition which balances all the values of Go has been put forth. I think it's a matter of time and resource.

Re: The Road to Scala 3

#82
post #32

I love scala, and am very much looking forward to scala 3. For all the complaints about the language that always pop up in these threads: yes, the language lets you shoot yourself in the foot (with great power comes people who don’t apply it responsibly), but it’s precisely that power that makes it so useful and exceptional when judiciously applied. I like to say that scala is as if java and ruby had a love child and…

Java, Ruby, and ML had a wild night that resulted in some massive scrambling of DNA.

The child was then adopted by Haskellites and raised in a fundamentalist commune.

Re: The Road to Scala 3

#83
post #41

Earlier quoted context omitted.

That would be missing the point of Go. It’s not as though the Go team is incapable of introducing genetics they just took a hard line on not putting anything into the language that wasn’t absolutely needed. This built a simpler language and because of that a stronger community, which is why Go has all but entirely eaten scalas lunch

This is all marketing. I've never found a more sophisticated type system anything but helpful. It's easy for beginners to start, but when you don't have a good type system and you have a complicated project things quickly become a nightmare.

eh, there is still a cost to it, don't get me wrong I generally think generics are worth the cost if done right, but they can also go really wrong

Re: The Road to Scala 3

#84

Earlier quoted context omitted.

proof is in the pudding on that one, sorry don't think there are academics studying this but it's an obvious outcome from the war that was Go/Scala/Node. Go is eating Scalas lunch because its easy to understand and communities are stronger than individuals. Sure Scala has more 'features' but Rob Pike would say every feature has a cost and you need to weigh that, didn't see that ever happen in Scala. Go is taking the…

Another commenter points out that Go has Google backing it, which is a significant confounding factor in terms of figuring out how good it is on its own merits. I’ll add to this and say that Go is a language that is very well-suited for Google’s issues. Namely, take a bunch of engineers with a particular area of familiarity (e.g. familiarity with C and/or Java) and throw them at code, scaling up by number-of-engineer…

Practically everything you mentioned is already done better by Java or C#. Not to mention them having advantages that golang isn't even close to solving.

Re: The Road to Scala 3

#85

Earlier quoted context omitted.

That would be missing the point of Go. It’s not as though the Go team is incapable of introducing genetics they just took a hard line on not putting anything into the language that wasn’t absolutely needed. This built a simpler language and because of that a stronger community, which is why Go has all but entirely eaten scalas lunch

IMO this would be a bet that the Go team does not implement generics in the vague near future. There's a difference between the Go team making a fundamental design judgment against generics vs the Go team feeling that no super-obvious proposition which balances all the values of Go has been put forth. I think it's a matter of time and resource.

They are just against features with a high cost to the community, generics are pricey as they can go quite wrong. They are now entertaining ways of adding them while limiting their downsides.

Re: The Road to Scala 3

#86
post #45

The way I look at modern Scala is a mix of Python and Java. Do it badly, and you end up with the unmaintainability of Python and the clunkiness of Java. Awful. Do it well, and you end up with the convenience and interactivity of Python and the typesafety, performance, and toolability of Java. This lets you implement your code quickly the first time, and have it run blazing fast on a hot JVM, with the compiler having…

That's about my experience. The language is maturing very well and the library ecosystem is just amazing. (Looking at you, lihaoyi!).

I really appreciate that I can walk the full gradient from immutable-functional to impure-imperative with one language, depending on the context and the requirements. It takes some discipline for a team (code reviews, regular feedback, discussion on approaches) but I'd say that's true for any language to some degree.

Then there is the ecosystem that's getting better and better with every year, with more and more libraries building on and onto each other.

SBT has been a sore point in the past, that has been ameliorated quite a bit in the past three years. SBT 1.3.x together with GraalVM native is a game changer! And then there are lots of other build tools that less ambitious and more approachable than SBT, if SBT simply isn't your cuppa.

Scala.js is also quite amazing. Scala is definitively underrated in that area. Being able to stay in one tool for a full stack application and being able to shift code seamlessly up and down the stack, depending on the current requirements has been an eye opener for me.

Biggest Scala pros - Terse expressive syntax with a strong type system - Welcoming community and creators - Amazing libraries and rich ecosystem - World-class tooling!

I the future I hope that Odersky and the core team will continue to identify "implicits" use cases and provide dedicated syntax for them, just like they did with extension methods in Scala 3.

Re: The Road to Scala 3

#87
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…

Is it declining? Citation needed? I agree that Scala is not the new kid on the block anymore but I don't see it decline. When you look at the language rankings of the last few years, Scala seems to have settled at about ~12th place currently.

Re: The Road to Scala 3

#88

I love Scala, it has a nicely advance static type system, supports functional programming and has even macros, although they are a bit messy. Something I miss in go and python. Go's type system is way to simple and python is dynamic, which I think is unnecessary these days. Static type systems can be as expressive as dynamic ones. It has interesting libraries, like cats, shapeless, breeze. And it is popular in the bi…

Yeah, the thing with macros is that they were never officially supported. They were always kind of a hack.

Scala 3 finally has an answer for that[1].

Besides that; yeah, Scala is amazing. I really see it shine for scientific computing when it moves beyond Python.

[1] https://dotty.epfl.ch/docs/reference/metaprogramming/macros....

Re: The Road to Scala 3

#89

Earlier quoted context omitted.

Another commenter points out that Go has Google backing it, which is a significant confounding factor in terms of figuring out how good it is on its own merits. I’ll add to this and say that Go is a language that is very well-suited for Google’s issues. Namely, take a bunch of engineers with a particular area of familiarity (e.g. familiarity with C and/or Java) and throw them at code, scaling up by number-of-engineer…

Sorry those just aren't legitimate analogies. As I mention before every feature has a cost, Go is highly concerned with how those costs impact the community. In doing so they have created a language thats highly maintainable and efficient. Even at small companies there is turnover and you being 'really smart' with some abstraction has an impact, I've seen this plenty first hand.

Counterpoint, regarding community: the Rust programming language has a much more vocal, cohesive, and engaged community than Go does in my experience, even though it has a fraction of the corporate backing.

Counterpoint, regarding “reducing the cost of features”: Go is spreading a simplified understanding of what garbage collection performance means to a generation of programmers by providing almost no configuration over their GC settings. I’ve had people say that Go’s GC is obviously the best, without any point of reference with which to compare it.

What Go has done here is pick a reasonable set of trade-offs to make in their garbage collector, hard-code most of these settings into the runtime system, and package that into the philosophy of “configuration is bad”.

Re: The Road to Scala 3

#90
post #80

I often see comparisons to Go, Kotlin, Rust, etc, and I agree that it's unlikely for Scala to have a second renaissance and have an steep upward trajectory like those languages, but is that really a death of a language? I'm actually fine with Scala narrowing its scope and focus at being really good at just a couple of things. Such as embracing its FP-side more so than its OO-side. Not to say there is no value in its…

I agree with almost everything you're saying. I'll just add that while Scala missed it's opportunity with Android, the big problem has always been a borderline dogmatic approach to pure FP by the community at the cost of simplicity. Scala libraries are generally complex and difficult to use (sometimes even for Scala engineers with several years experience). Also, core FP principles are not that hard (immutability, ex…

There is that, yeah. There was a lot of translating things from Haskell to Scala 1:1, and that didn't always work out so well. Well, actually it does mostly work on a technical level, but with heavy costs when it comes to ergonomics. The implicit imports and poor type inference was enough to cause frustration within our team.

That's why I specifically mentioned ZIO. Things improved greatly after migrating to it. It feels like it plays to Scala's strength. It infers well and we don't have a single implicit import to make it work. Well, with the 1 exception of the optional Duration syntax so that we can write "5 seconds" instead of "Duration(5, TimeUnit.SECONDS)".

Post reply on HN