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

Towards Scala 3

scala-lang.org

Post reply on HN
Print view View original

141–150 of 383 posts

Re: Towards Scala 3

#141

Post by lmm »

sidlls wrote: post #76
boubiyeah wrote: post #17

Earlier quoted context omitted.

Scala has an insanely productive and efficient streaming ecosystem with the likes of Kafka and Akka streams. You can use those with other languages but it's not nearly as nice.

Why isn't it nearly as nice? Is there something particular about Scala such that Kafka or Akka are best implemented in it? Could you give some concrete examples (e.g. compare it with Java, C, C++, Rust, Haskell)?

(Compared to Java, C or C++ there's all the usual ML-family goodness - first-class functions, algebraic data types with pattern matching, type inference).

Scala has a for/yield construct similar to Haskell's "do notation", which is the perfect way to work with async code - it strikes the right balance of avoiding an unreadable callback pyramid of doom, but still your async yield points visible (the difference between Haskell has all that - the trouble with Haskell is that "there's no way to get to there from here". I was able to go from writing Java on Friday to writing Scala on Monday - not great Scala, but working Scala, and I was just as productive as I was in Java. I couldn't've done that with Haskell.

Re: Towards Scala 3

#142

Post by jowiar »

YorkshireSeason wrote: post #116
jowiar wrote: post #74

Earlier quoted context omitted.

I disagree with that. Haskell is category theory as a language. The Scala community got invaded by Haskellites trying to turn Scala into Haskell, but there’s a particular style of OOP/FP hybrid that requires a language like Scala to use/teach/explore. The problem is that in creating the tool to enable that, we ended up with a language that was too big to have a coherent style, which led to an incredibly fractured com…

Haskell is category theory as a language. I disagree with this. Haskell's creation [1, 2] predates the realisation (by the FP community at large) of the close connection between parts of category theory and parts of pure functional programming, which happened in the 1990s, perhaps driven by Moggi's realisation that monads are a fundamental abstraction in computation that can reconcile effects with pure functional com…

Would love to see a citation re: Odersky (or if he'd chime in here).

My general assumption is that if Scala was intended to be category theory, implemented, something along the lines of scalaz or cats would have been built into the language -- the philosophy of the language does not include a JS-esque philosophy of small stdlib, big library ecosystem.

Re: Towards Scala 3

#143

Post by lmm »

coryfklein wrote: post #114

So many cool things already done and even more to come. Some parts that excite me as a Scala nerd: * One can now use implicit function types to basically build your own table language syntax that is type-safe. [1] * Multiversal Equality: you get to decide whether it makes any sense to compare an Apple and an Orange using "==" or "!=", as opposed to Java's forced requirement of allowing you to compare anything with an…

> * Multiversal Equality: you get to decide whether it makes any sense to compare an Apple and an Orange using "==" or "!=", as opposed to Java's forced requirement of allowing you to compare anything with anything. [2]

Unfortunately it's being introduced in a fail-unsafe way that as far as I can see makes it virtually useless. If I see "x == y" in code, I have no way to be confident that this isn't an old-fashioned universal comparison without going into the details of x and y, so I'm no better off than I was without this feature.

Re: Towards Scala 3

#144

Post by lmm »

coryfklein wrote: post #129
lmm wrote: post #105

Earlier quoted context omitted.

> I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them. Yeah, that's what I was talking about - in Scala operators are just functions, and badly named operators are an issue with some libraries rather than an issue with the language. They're unfortunate, but all one can really do is avoid them -…

What IDEs support this behavior?

Both eclipse and intellij will underline implicit conversions. Showing implicit parameters might be intellij-only.

Re: Towards Scala 3

#145

Post by saosebastiao »

YorkshireSeason wrote: post #116
jowiar wrote: post #74

Earlier quoted context omitted.

I disagree with that. Haskell is category theory as a language. The Scala community got invaded by Haskellites trying to turn Scala into Haskell, but there’s a particular style of OOP/FP hybrid that requires a language like Scala to use/teach/explore. The problem is that in creating the tool to enable that, we ended up with a language that was too big to have a coherent style, which led to an incredibly fractured com…

Haskell is category theory as a language. I disagree with this. Haskell's creation [1, 2] predates the realisation (by the FP community at large) of the close connection between parts of category theory and parts of pure functional programming, which happened in the 1990s, perhaps driven by Moggi's realisation that monads are a fundamental abstraction in computation that can reconcile effects with pure functional com…

> One of Odersky's motives in creating Scala was bringing the power of Haskell into the JVM world, although this is not the only motive (thigh integration of OO and FP being another).

I'm not sure why you would think that. Odersky has long claimed ML as his primary functional programming influence, not Haskell. It does have HKT, so there's that...but that's about it. Typeclasses aren't really a part of the language. They were made possible by implicits. They have since had some language level support (context bounds), but that is more of a nice to have than a primary influence.

Just because Scala can "do" Haskell doesn't mean odersky was inspired by it any more than ML or Java.

Re: Towards Scala 3

#146

Post by lmm »

stephen wrote: post #121
framebit wrote: post #111

I saw a presentation recently on Mill[1] which looks extremely promising and looks poised to remove the giant Scala development headache of working with SBT. [1] https://github.com/lihaoyi/mill

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.

Re: Towards Scala 3

#147

Post by dtech »

virmundi wrote: post #131

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…

> How have people faired with Scala integration with Java libraries?

It's useful because the JVM ecosystem is much larger than the Scala ecosystem. There's almost always a library for your purpose. If it isn't as idiomatic Scala as you'd want you can often easy create a small wrapper.

> Suddenly I have to worry about the Jr Dev doing silly things like introducing mutable Java objects into functional code.

code reviews and education

Re: Towards Scala 3

#148

Post by gaius »

jrq wrote: 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

Re: Towards Scala 3

#149

Post by auvi »

nextos wrote: post #87
jowiar wrote: post #74

Earlier quoted context omitted.

I disagree with that. Haskell is category theory as a language. The Scala community got invaded by Haskellites trying to turn Scala into Haskell, but there’s a particular style of OOP/FP hybrid that requires a language like Scala to use/teach/explore. The problem is that in creating the tool to enable that, we ended up with a language that was too big to have a coherent style, which led to an incredibly fractured com…

Designing good multi-paradigm languages is very hard. I'm a big fan of Mozart-Oz and Common Lisp, and I think Odersky did a really good job with Scala. In fact, given that Common Lisp is languishing and Mozart was never a serious real world contender, Scala fills in a niche where there are not many competitors. C++, just for some use cases, Julia for others, and .NET. The fact that many organizations working on massi…

> Common Lisp is languishing

can you elaborate more on that?

Re: Towards Scala 3

#150

Post by th0raway »

virmundi wrote: post #131

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…

There are many answers, often related to company size and interest in teaching. Some large bay area companies think that training people into a FP style of Scala is too expensive/hard to hire for, and end up using it as a nicer Java. Smaller companies that do not hire 100 people to work in Scala every year just bite the bullet, expect FP, and end up wrapping a large majority of Java libraries with FP abstractions, some thin, some quite big.

I prefer an intermediate solution when I can get away with it: Localize the mutable Java objects as much as possible, and just make sure that I don't leave a team/teammate that has little Scala experience all alone for a while. This often leads to styles that might be frowned upon by both camps of programming, but in my experience, dropping to imperative code when FP solutions are harder to optimize, while making sure that mutability is well contained and doesn't cross interfaces is Scala's happy place. Depending on the work to be done, each codebase can be pretty FP heavy, or be mostly imperative with an FP facade.

The real trick with Scala is really library design though: It's very easy to make a new library that has dozens of new concepts and is hard to learn and use, all while exposing things like Shapeless HLists to the outside world, while libraries that are easier to consume and don't crush compilation times through type magic are often tougher on the author, leading to more code generation and macros. Most library authors know so much Scala that they don't realize that just using their library well incurs in quite the mental cost to new developers.

Post reply on HN