3 ms·

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 let

by jacobn 7y ago

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 it all worked out. Unfortunately, that does mean that java people will feel it’s too fast & loose, and the ruby people will feel stymied by its static typing. But I just love that where other statically typed languages generally say “no”, scala says “well, I trust you know what you’re doing...”. The only substantive tool complaint I have these days isn’t with compiler speed - it chugs through the codebase plenty fast - but with tool startup time. Hopefully the more recent java versions and maybe some native packaging will eventually help with that.

asimpletune 7y ago
I appreciate you taking the courage to share your honest thoughts despite how they may conflict with the views of others here. My heart goes out to the people I overhear at work, the ones who are struggling the most, lamenting and complaining that tool X (In this case scala) is “so” embarrassingly awful and, with the implication that it’s to blame for their poor performance. That sentiment resembles some of the comments that I’ve written here and my heart really bleeds for them, because I know these people at work and I know that they’re struggling and I also know that they’re good, smart people, who have just fell into a trap of justification. For what it’s worth, in my own journey learning Scala, I simply didn’t have the luxury to blame, and I just forced myself to try and figure out how other people, like the finagle team for example, could be so productive with such an obviously newfangled invention, until I realized… I was wrong. Scala is actually a wonderful language! People move companies to continue working in Scala! In fact the ideas and lessons that I’ve learned from rethinking how I used to do things are so unfathomably valuable to me that I don’t think I will ever look at code the same way again. And before you downvote me please don’t mistake my words for criticism. I truly empathize with how some of the people here may feel and I’m very happy to go into specifics if anyone requests that. I don’t write on HN a lot because a lot of times I think there is just this therapy - or a version of therapy - that amounts to people reinforcing their need to blame things in order to continue excusing the poor performance, and I don’t want to get caught up in it or be made to feel bad for encouraging others to reconsider their virtues. And by the way we all, at times, have poor performance. (Anyway, I dictated this into my phone, so also excuse any weird words or punctuation. I love you all. Some typos were subsequently edited)
- bcrosby95 7y ago
  Not every language has to be for every person. It's perfectly fine that people enjoy Scala. I think a lot of the negativity about Scala is because lots of companies went in hard on Scala less because of the merits of Scala, and more because Java had such a long period of stagnation.
  - asimpletune 7y ago
    This is very true
- erikpukinskis 7y ago
  > My heart goes out to the people I overhear at work, the ones who are struggling the most, lamenting and complaining that tool X (In this case scala) is “so” embarrassingly awful and, with the implication that it’s to blame Yah, I have noticed lately a division between two types of programmers. The first is the "infrastructure oriented" programmer. They assume that the rank and file programmers will be expected to write bad code. They look at problems in the codebase as a sign that there is a missing piece of infrastructure. They 1) wait for the pain level to get high enough on the team, 2) identify a class of problems that is not getting solved well, 3) install or implement a new service/middleware/library that solves that class of problem elegantly, and 4) port all of the crappy code over to the new reality. The second is the "pattern oriented" programmer. They assume that sloppy code will create areas of rot around it that become cost centers, and that "low hanging fruit" cleanup tasks will generally pay for themselves. When there are problems in the codebase, they go back and refactor. They advocate for team discussions of patterns, establish precedent for the team to follow, and expect other members of the team to learn and apply those patterns correctly. I'm not really sure whether these two types of programmers should work together. Each group's primary assumption: 1) Programmers will inevitably do sloppy things, and' 2) "Low-hanging cleanup" pays for itself ... is correct in practice. The problem is they are somewhat at odds in terms of pointing to a high level strategy. If you are committed to ripping out and replacing large parts of the codebase when they become unworkable, there's not really any point to trying to keep up with tidying. And if you tidy, you won't really need to rip out large parts of the codebase. So maybe we should just each try to find a team that fits with our values, rather than argue about it.
jowiar 7y ago
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.
michaelcampbell 7y ago
> 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?
- kenhwang 7y ago
  Kotlin is more like if Java and Python had a love child. It's clean, simple, quick to pick up, and pretty much retains the behavior of the underlying language.
  - soulnothing 7y ago
    I agree I came from Python/F#. I've also had a lot of success converting python teams to kotlin, and ruby teams to scala.
- raquo 7y ago
  > What part of ruby or java has anything morally or technically even approaching the concept, use case, or meaning of implicits? Dependency injection for implicit params, for one? Also, you can almost see implicit conversions as one take on type safe dynamic typing. Almost. But of course Scala also brings functional programming and its own ideas to the mix.
AheadOfTime295 7y ago
Scala 3 gets lots of discussion recently yet progress on Scala 2 matters too: Spark on Scala 2.13 https://issues.apache.org/jira/browse/SPARK-25075 https://issues.apache.org/jira/browse/SPARK-25075 Scala 2 and the Java 9 Module System https://news.ycombinator.com/item?id=20912258 https://news.ycombinator.com/item?id=20912258

by jacobn 7y ago

asimpletune 7y ago

I appreciate you taking the courage to share your honest thoughts despite how they may conflict with the views of others here. My heart goes out to the people I overhear at work, the ones who are struggling the most, lamenting and complaining that tool X (In this case scala) is “so” embarrassingly awful and, with the implication that it’s to blame for their poor performance. That sentiment resembles some of the comments that I’ve written here and my heart really bleeds for them, because I know these people at work and I know that they’re struggling and I also know that they’re good, smart people, who have just fell into a trap of justification. For what it’s worth, in my own journey learning Scala, I simply didn’t have the luxury to blame, and I just forced myself to try and figure out how other people, like the finagle team for example, could be so productive with such an obviously newfangled invention, until I realized… I was wrong. Scala is actually a wonderful language! People move companies to continue working in Scala! In fact the ideas and lessons that I’ve learned from rethinking how I used to do things are so unfathomably valuable to me that I don’t think I will ever look at code the same way again. And before you downvote me please don’t mistake my words for criticism. I truly empathize with how some of the people here may feel and I’m very happy to go into specifics if anyone requests that. I don’t write on HN a lot because a lot of times I think there is just this therapy - or a version of therapy - that amounts to people reinforcing their need to blame things in order to continue excusing the poor performance, and I don’t want to get caught up in it or be made to feel bad for encouraging others to reconsider their virtues. And by the way we all, at times, have poor performance. (Anyway, I dictated this into my phone, so also excuse any weird words or punctuation. I love you all. Some typos were subsequently edited)

bcrosby95 7y ago
Not every language has to be for every person. It's perfectly fine that people enjoy Scala. I think a lot of the negativity about Scala is because lots of companies went in hard on Scala less because of the merits of Scala, and more because Java had such a long period of stagnation.
- asimpletune 7y ago
  This is very true
erikpukinskis 7y ago
> My heart goes out to the people I overhear at work, the ones who are struggling the most, lamenting and complaining that tool X (In this case scala) is “so” embarrassingly awful and, with the implication that it’s to blame Yah, I have noticed lately a division between two types of programmers. The first is the "infrastructure oriented" programmer. They assume that the rank and file programmers will be expected to write bad code. They look at problems in the codebase as a sign that there is a missing piece of infrastructure. They 1) wait for the pain level to get high enough on the team, 2) identify a class of problems that is not getting solved well, 3) install or implement a new service/middleware/library that solves that class of problem elegantly, and 4) port all of the crappy code over to the new reality. The second is the "pattern oriented" programmer. They assume that sloppy code will create areas of rot around it that become cost centers, and that "low hanging fruit" cleanup tasks will generally pay for themselves. When there are problems in the codebase, they go back and refactor. They advocate for team discussions of patterns, establish precedent for the team to follow, and expect other members of the team to learn and apply those patterns correctly. I'm not really sure whether these two types of programmers should work together. Each group's primary assumption: 1) Programmers will inevitably do sloppy things, and' 2) "Low-hanging cleanup" pays for itself ... is correct in practice. The problem is they are somewhat at odds in terms of pointing to a high level strategy. If you are committed to ripping out and replacing large parts of the codebase when they become unworkable, there's not really any point to trying to keep up with tidying. And if you tidy, you won't really need to rip out large parts of the codebase. So maybe we should just each try to find a team that fits with our values, rather than argue about it.

jowiar 7y ago

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.

michaelcampbell 7y ago

> 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?

kenhwang 7y ago
Kotlin is more like if Java and Python had a love child. It's clean, simple, quick to pick up, and pretty much retains the behavior of the underlying language.
- soulnothing 7y ago
  I agree I came from Python/F#. I've also had a lot of success converting python teams to kotlin, and ruby teams to scala.
raquo 7y ago
> What part of ruby or java has anything morally or technically even approaching the concept, use case, or meaning of implicits? Dependency injection for implicit params, for one? Also, you can almost see implicit conversions as one take on type safe dynamic typing. Almost. But of course Scala also brings functional programming and its own ideas to the mix.

AheadOfTime295 7y ago

Scala 3 gets lots of discussion recently yet progress on Scala 2 matters too: Spark on Scala 2.13 https://issues.apache.org/jira/browse/SPARK-25075 https://issues.apache.org/jira/browse/SPARK-25075 Scala 2 and the Java 9 Module System https://news.ycombinator.com/item?id=20912258 https://news.ycombinator.com/item?id=20912258