Live data from Hacker News

Scala 2.13 is now available

scala-lang.org

71–80 of 87 posts

Re: Scala 2.13 is now available

#71
post #41

Earlier quoted context omitted.

I used Scala five-ish years ago, and I loved it, but I had two qualms: 1. The community was terribly split between FP purists who wanted to write Haskell on the JVM and pragmatists who leaned more towards the "better Java" side of things. Plus the occasional ex-Rubyists who came up with method names consisting solely of interpunction ("embedded DSL!"). Has any side won? It would be nice to have anything resembling "i…

I think there's a sensible middle ground. Using types for side effects (eg Slick does it for DB IO) and error handling (see also Rust's Result type) is great. Scala's for-comprehension (which is Haskell's "do" notation) is a bit awkward (you have to understand that it's a syntactic sugar, and you have to learn about monad transformers, because you have to align the types, so if you started with an Option you have to…

> Going full FP can be ... painful. When all you see is functions, functions getting passed function, that return functions, that can be called with other functions that ...

Exactly. "Functional purists" write code that caters to their aesthetics. It's completely unreadable and a pain in the ass to debug, but it sure looks really nice and clean.

If pure functional programming really is a major benefit, it should show in the number of successful software projects. I don't see it.

Re: Scala 2.13 is now available

#72
post #42

Earlier quoted context omitted.

I don't think any side has won, but from what I gather Odersky thinks pragmatic functional is the way to go, i.e. only mutate when it brings substantial benefits to code clarity over a pure approach. That is, the default should always be functional, but use an imperative style where it makes sense.

This is my engineering org's philosophy as well. New engineers who have a java background tend to have some difficulty getting used to it, but all it takes is a light switch in their head. For example, the other day there was a PR for creating a simple csv report and they wrote something like val buffer = new StringBuffer() buffer.add(header) buffer.add("\n") someList.forEach { item => val values: List[String] = some…

The above version might be more efficient (less allocations, less GC), which certainly matters for some applications.

I actually also find it more readable, but that’s a personal preference

Re: Scala 2.13 is now available

#73
post #42

Earlier quoted context omitted.

I don't think any side has won, but from what I gather Odersky thinks pragmatic functional is the way to go, i.e. only mutate when it brings substantial benefits to code clarity over a pure approach. That is, the default should always be functional, but use an imperative style where it makes sense.

This is my engineering org's philosophy as well. New engineers who have a java background tend to have some difficulty getting used to it, but all it takes is a light switch in their head. For example, the other day there was a PR for creating a simple csv report and they wrote something like val buffer = new StringBuffer() buffer.add(header) buffer.add("\n") someList.forEach { item => val values: List[String] = some…

I like that version A

1) is more readable (fight me)

2) doesn't rely on internal optimizations for string concatenation, in order to be as efficient

3) doesn't create extra garbage (linked lists)

In fact, the only thing I would change is make it a for loop instead.

Re: Scala 2.13 is now available

#74
post #64
post #63

Earlier quoted context omitted.

>Contrary to popular belief, Scala is actually quite a simple language. Interesting. Then why do some people say it is not? Anecdotal, mind you, and don't have links right now.

you are right, should have said "i think it is a simple language". what makes me think it is a simple language (especially if you are writing microservices): - class is a class, and you don't really need to explain the modifier - object is just an object, like if a class is instantiated, and it is a singleton - trait gives you mixin, cake pattern / self type - Future makes async programming simple - for yield -> to a…

Thanks for the answer. I had not heard of the cake pattern, will check it out.

Re: Scala 2.13 is now available

#75
post #42

Earlier quoted context omitted.

I don't think any side has won, but from what I gather Odersky thinks pragmatic functional is the way to go, i.e. only mutate when it brings substantial benefits to code clarity over a pure approach. That is, the default should always be functional, but use an imperative style where it makes sense.

This is my engineering org's philosophy as well. New engineers who have a java background tend to have some difficulty getting used to it, but all it takes is a light switch in their head. For example, the other day there was a PR for creating a simple csv report and they wrote something like val buffer = new StringBuffer() buffer.add(header) buffer.add("\n") someList.forEach { item => val values: List[String] = some…

You can have the line break appended at the end by using the three-arg version of mkString:

    (header :: rows).mkString("", "\n", "\n")
My two cents: I prefer the second solution. Maybe it's because I have never programmed in Java.

Re: Scala 2.13 is now available

#76
post #39

Earlier quoted context omitted.

Maven itself works fine. In nine years of Scala I've never understood what problem SBT is supposed to solve - it seems very complicated to no real benefit.

I loved the incremental compile/watch tests stuff myself. It's been a while, but I do miss having all my tests run every time I save a file. But I do accept that sbt is not everybody's cup of tea.

I had heard that use case mentioned now that I think about it. To my mind it makes much more sense to have the IDE handle that part; the IDE knows which file I've edited and when I've saved it rather than having to scan the filesystem. But I guess some people must find it useful.

Re: Scala 2.13 is now available

#77
post #42

Earlier quoted context omitted.

I don't think any side has won, but from what I gather Odersky thinks pragmatic functional is the way to go, i.e. only mutate when it brings substantial benefits to code clarity over a pure approach. That is, the default should always be functional, but use an imperative style where it makes sense.

This is my engineering org's philosophy as well. New engineers who have a java background tend to have some difficulty getting used to it, but all it takes is a light switch in their head. For example, the other day there was a PR for creating a simple csv report and they wrote something like val buffer = new StringBuffer() buffer.add(header) buffer.add("\n") someList.forEach { item => val values: List[String] = some…

[deleted]

Re: Scala 2.13 is now available

#78

Earlier quoted context omitted.

This is my engineering org's philosophy as well. New engineers who have a java background tend to have some difficulty getting used to it, but all it takes is a light switch in their head. For example, the other day there was a PR for creating a simple csv report and they wrote something like val buffer = new StringBuffer() buffer.add(header) buffer.add("\n") someList.forEach { item => val values: List[String] = some…

You can have the line break appended at the end by using the three-arg version of mkString: (header :: rows).mkString("", "\n", "\n") My two cents: I prefer the second solution. Maybe it's because I have never programmed in Java.

I love how when a person posts a good snippet someone will always chime in with an improvement

Re: Scala 2.13 is now available

#79
post #3

Why is Scala not more popular? It seems like such an awesome language, is it because of it academic origins or because it's not functional enough?

Most of my background is in Python, but I've dabbled in a lot of languages out there from Haskell, lisp, Perl...etc. The point being I don't mind trying new things. I don't know Java and the JVM very well though and a lot of hosted languages like Scala, Clojure, Kotlin...etc seem to assume that you're intimately familiar with it which is a pain. Also, the Scala tooling when I last checked ~2 years ago was complex. I…

Clojure is great for scripting now.

Re: Scala 2.13 is now available

#80
We use Java in our projects and although there is interest in Scala, I fail to see any real benefits from moving to it, especially with new Java features, except for a nice addition to your CV.

Can anyone share their experience where moving from Scala to Java yielded measurable benefits, besides "it's more fun to program in Scala"?

Post reply on HN