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

The Road to Scala 3

scala-lang.org

Post reply on HN
Print view View original

91–100 of 196 posts

Re: The Road to Scala 3

#91

Post by solicode »

kev009 wrote: post #79
solicode wrote: post #46

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…

F#?

F# is quite nice. I used it a long time ago for a couple of libraries when I was working in a team that mostly used C#. Fable looks really cool too.

I remember getting the feeling that C# is holding it back though. F# can't have any feature that it wants because interop in both directions seems to be a priority. If I recall correctly, that's what is holding back higher-kinded types in F#.

That, and the last time I tried F# on .NET Core things were still very rough. This was when .NET Core was still fairly new though. It might be fine now.

Re: The Road to Scala 3

#92

Post by didibus »

The_rationalist wrote: post #15
grzm wrote: post #12

Earlier quoted context omitted.

Yes. Very well. https://www.clojure.org/reference/java_interop

Interested but how much as good as with kotlin? Being compatible is one thing, being as idiomatic is another.

Not sure what you mean. It is idiomatic to not rebuild things Java offers in Clojure and to instead just use interop with Java.

Using Java from Clojure I'd say is as good as Kotlin. Using Clojure from Java isn't as good as Kotlin, but it is still pretty good. Only certain things get messy, like in frameworks where you need to extend a class and override methods to set some behavior. Or frameworks that make heavy use of annotations. Since Clojure isn't OO, doing those are a bit trickier.

Re: The Road to Scala 3

#93

Post by didibus »

Scarbutt wrote: post #66
The_rationalist wrote: post #15

Earlier quoted context omitted.

Interested but how much as good as with kotlin? Being compatible is one thing, being as idiomatic is another.

Nowhere near as good or as seamless as Kotlin interop, Kotlin made interop a priority/first class feature. When using a Java library in Clojure, many times its just better to just write some Java for your Clojure program specifically for the purpose of calling it from Clojure.

That hasn't been my experience. I've always been able to make use of Java libraries directly from Clojure in a straightforward way. In fact, sometimes I joke it's easier to do Java in Clojure than in Java

Can you describe the kind of situations that you faced issues in?

P.S.: Also, Clojure has first class interop... It's a part of its fudamental design.

Re: The Road to Scala 3

#94

Post by hocuspocus »

stewbrew wrote: post #77
hocuspocus wrote: post #68

Earlier quoted context omitted.

That's a complete myth, really. The Scala ecosystem has its fair share of problems, but Odersky and his lab's involvement and stewardship have never been one of them.

Just an example: Why wasn't it a priority to make scala run well on dalvik? The place is taken by kotlin and is one of its strongest selling points.

Because there never was a real demand for it? What does that have to do with Scala's academic roots?

And what makes you think Scala needs Android to be successful? Android is completely irrelevant to most Java developers.

Re: The Road to Scala 3

#95

Post by lightbendover »

apta wrote: post #78
lightbendover wrote: post #74

Earlier quoted context omitted.

Having led engineering at a startup that developed ~95% of our code in Scala and then moving to a FANG team that developed most of its services in Java (still using Spark Scala to a large degree and beginning to introduce Kotlin), these are the reasons I can use to justify using Java over either: 1) it is already there, 2) most engineers know Java well [enough], 3) other teams predominantly use Java and it makes cert…

> Java is another boring language, but it's also a very verbose one, even when fully utilizing Lombok/G-libraries/etc.. Incidentally, I find golang to be more verbose than Java. The amount of one-off functions you have to write to get around the lack of generics and/or map/filter calls on collections makes the code longer and harder to follow, and harder to debug. Not to mention error handling. I generally agree with…

> What ended up happening with the startup you worked at out of curiosity?

We made two poorly judged business decisions: 1) build a marketplace without enough proof of demand, 2) treat certain types of financial instruments as securities ahead of a fed decision that never materialized (I call this the bizzaro-Uber play). Outside of the things we could have controlled, the sector we operated in did not meet its expected growth projections in the aftermath of certain participants not playing nicely. We were acquihired as part of the typical VC risk sharing.

The ultimate failure had very little to do with Scala as a tech decision. I was extremely proud of the products we built from an engineering perspective, but I don't credit Scala with that either. The high-performers on the team could have repeated the same technical success with any of the languages I discussed above. Perhaps our hiring was slower than our funding level would have allowed. Perhaps our worse-performing engineers could have contributed more if it was Go or Python. Neither of the alternative realities would have gotten us past the two aforementioned business decisions.

Re: The Road to Scala 3

#96

Post by yahyaheee »

jkachmar wrote: post #89
yahyaheee wrote: post #61

Earlier quoted context omitted.

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…

Rust has a pretty great community, and I don't think you need corporate backing for a community. I'm just stressing it's one of the most (if not the most) important aspects of a language.

I will say Rust it isn't nearly as easy to enter as Go, that should be somewhat expected by their desired feature set. Likewise, they aren't as concerned with the cost of features as Go is.

I would somewhat agree with the GC stuff, I think having a couple more levers there with sensible defaults is probably ideal.

Re: The Road to Scala 3

#97

Post by devit »

The problem of Scala is that it is outclassed by Rust and Kotlin at its two niches of, respectively, "best designed programming language" and "better Java on the JVM".

Scala can't beat Rust because you can't have safe concurrency (and also single-threaded mutation control) without linear types, and you can't have linear types on the JVM; furthermore, a GC and VM-based language is inferior to a native non-GC one providing the same guarantees.

Scala can't beat Kotlin because Kotlin is designed to be just a better Java and Scala also tries to do other things that reduce Java compatibility; pivoting would result in being behind Kotlin with no hope of catching up.

Furthermore, its core features are cute but fundamentally broken: class inheritance is an anti-pattern and functional features need either purity like Haskell or mutability control like Rust to work safely and efficiently; on top of that, the language is also complicated and hard to learn.

Re: The Road to Scala 3

#98

Post by vips7L »

xvilka wrote: post #29
bcherny wrote: post #3

I really love Scala, but I worry about its future given Google putting its weight behind Kotlin, and the two offering a lot of the same features and philosophy. Does anyone know if the Scala maintainers have addressed this directly?

Kotlin wins also because it has a stable and usable Native flavor. Scala Native is a third-party project and seems dead, while Kotlin Native is the core part of the Kotlin language and being developed at a fast pace.

I don't think this is relevant since both languages compile to JVM bytecode and Graal can compile that to native.

Re: The Road to Scala 3

#99

Post by michaelcampbell »

jacobn wrote: 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…

> I like to say that scala is as if java and ruby had a love child and it all worked out.

I feel Kotlin is probably a more accurate result of this mindset, but reasonable people disagree.

What part of ruby or java has anything morally or technically even approaching the concept, use case, or meaning of implicits?

Re: The Road to Scala 3

#100

Post by idclip »

esarbe wrote: post #86
lihaoyi wrote: 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…

This comment and lihao’s are rekindling a flame in my chest.
Post reply on HN