Live data from Hacker News

Towards Scala 3

scala-lang.org

121–130 of 383 posts

Re: Towards Scala 3

#121

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.

Re: Towards Scala 3

#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 new learners, especially with just how overwhelming all the different features can seem for someone not coming from both sides. I had ocaml and ruby under my belt when I found scala, so it was an easier curve, but lots of guys struggle with it. I don't mind showing them, and of course I learn a lot from guys with different experiences and different backgrounds, but that's sometimes a complain I hear, also.

It's a language that doesn't compare very well. What is scala like? We don't know, there's only one language like it, it's a departure from many different paradigms.

I'm back to writing ocaml, all said and done. I enjoyed my time with scala, and interacting with my guys on the other side of the office still doing scala is always enjoyable. Smart guys! I'm not academic enough to grasp some of the new DOT stuff, but they are excited about it.

Anyways, I gave up hope a while back on scala getting rid of sbt. There are other build tools that exist, cbt, mill, maybe more, but without the blessing from lightbend or whatever they call themselves this week, it's not feasible, or responsible to deliver a solution to a client with an unofficial build setup. Of course, after five years of doing sbt I decided it's not ok to deliver sbt either.

Someday! Maybe?!

Re: Towards Scala 3

#123
post #102

Earlier quoted context omitted.

About GUI on .NET Framework: - Windows form works but not perfect. The editor works if you install the template for it, but not the auto generation of code, like double click on button -> handler generated. You write code programmatically. but is used a lot. I use it in the repl (fsi), to generate chart, custom data visualization. - WPF the same, works, no editor (but codegen is less needed) - Xamarin support F# ( ht…

GUI development without designer support is just like time traveling to implementing Turbo Vision and Clipper applications on MS-DOS. Never understood the mentality for designing UIs by coding instead of visually. I care for what comes in the box, and is directly supported by Visual Studio and Blend. If someone needs to lose their .NET GUI tooling productivity to embrace F#, then better wait while C# keeps getting F#…

The only time I have ever felt compelled to design a UI visually is when working with iOS or macOS because the framework is so centered around Interface Builder. When I write a WPF or JavaFX view I am not using Blend/Scene Builder to drag and drop controls, but to have a mostly-accurate preview of what crap looks like without having to build and run.

Re: Towards Scala 3

#124
post #100
post #90

Earlier quoted context omitted.

It's trivial to avoid it in data science, with even modest to large (although not "Big") data in the few TB range. My data science team's entire stack is basically Python, with a smidge of Java and Rust for infrastructure (soa, pipelines) development.

I almost added the clarifying statement "on the JVM" but got lazy. Yes, Python is the obvious choice for data science until you hit a certain scale. It's not even clear to me that most companies doing data science in Scala have that scale -- they're just using tools and libraries companies at that scale have open sourced. You could call it cargo culting, but I think it's more nuanced than that. I think engineers can…

I'm in the second camp, actually.

Python is a good choice for data science even at relatively large scale. I'd question it's suitability for stable, scalable deployment in production (not to say it can't be used then, just that I wouldn't necessarily reach for it first, preferring either C++ or Rust for that).

Scala just doesn't figure into the picture at all. I consider that some "Big" data tools were written in it to be a matter of trivia and not essential to the work of data science.

Re: Towards Scala 3

#125
post #76

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

I think the parent comment was talking more about using those libraries with Scala, not necessarily implementing them.

Can't speak too much about the others, but I recently looked into using Akka with Java. Akka itself had a good deal of documentation for Java users. However, other related products (look tools for monitoring Akka, etc) were clearly treating Java as a second class citizen. When there was documentation, it would be outdated, and unmaintained. I ran into this over and over again, which weighted heavily on my decision to not use Akka. I'm not quite sure if there is anything about the language that would have made it particularly challenging (doubt it), but it definitely seems like the community built around it is more Scala centric. And that in itself makes it challenging to use with anything else.

Re: Towards Scala 3

#126
post #23
post #2

Just curious, what companies (or kinds of companies) are betting on Scala nowadays? It seems that the people wanting "better Java" all decided they like Kotlin, and the functional programming people now gravitate more towards either F# (for .NET ecosystem) or OCaml/Reason (for the more unixy world). And the academic/research/learning crowd seems to like Haskell more. Who's still in Scala boat? Are Google or Fb or oth…

Yeah, I don't think Scala 3 changes anything with regards to perception and/or adoption of Scala. That ship has pretty much sailed. Martin Odersky seems like a really good language designer. I took a look at the Scala 3 languages features, and a more radical departure from historic Scala probably would have helped Scala.

Could you (and perhaps others) say more about this? I was excited to read that key goals were simplification, clarification, and consolidation. But my exact worry is that they didn't go far enough.

I liked the idea of Scala and took Odersky's course. But I built a few things in it and it was never not frustrating. What Bruce Eckels said resonates with me: "I’ve come to view Scala as a landscape of cliffs – you can start feeling pretty comfortable with the language and think that you have a reasonable grasp of it, then suddenly fall off a cliff that makes you realize that no, you still don’t get it."

Then I watched this Paul Phillips talk, which convinced me that the problems were deep, not superficial: https://www.youtube.com/watch?v=4jh94gowim0

My hope with Dotty, etc, was that they had learned a little humility and were pruning back enough to make it a decent developer experience. But I could well believe that it was impossible to do enough and still end up with something that could be fairly called Scala.

Re: Towards Scala 3

#127
post #54

Earlier quoted context omitted.

Neither of those has or intends to have HKT, and they'll never be an acceptable replacement for Scala without it. They're "improving faster" but only in that they're starting from further behind.

The reason why Kotlin is gaining marketshare is specifically because they aren’t chasing after things like HKTs. Kotlin is squarely going after the better Java market and not the advanced FP one.

I think Kotlin's design - adding lots of ad-hoc support for specific use cases but without the underlying general constructs that make them coherent - will come to bite them as and when the language needs to evolve over time. (Indeed to a certain extent it already has, as Java 8+ adopts Options which don't play nice with Kotlin's ?. etc.) I guess we'll see how things look in a few years.

Re: Towards Scala 3

#128
post #14
post #2

Just curious, what companies (or kinds of companies) are betting on Scala nowadays? It seems that the people wanting "better Java" all decided they like Kotlin, and the functional programming people now gravitate more towards either F# (for .NET ecosystem) or OCaml/Reason (for the more unixy world). And the academic/research/learning crowd seems to like Haskell more. Who's still in Scala boat? Are Google or Fb or oth…

F# only has access to a subset of .NET deployment scenarios, where Scala can be used pretty much everywhere there is a JVM. So most companies actually are more keen to bet on Scala than F#. OCaml/Reason world lacks the wealth of Java libraries, which are an import away on Scala. Regarding Kotlin, so far its killer use case is targeting Android, where one is stuck with an ageing Java subset. Outside of Android, it rem…

This is kinda true, but not in the sense that you mean it.

And maybe not across the board, but my clients are very comfortable with the (very few) F# solutions we've done. Ocaml clients generally use it for stability, or correctness, they certainly aren't competing in the same sphere that kotlin, scala, Java really operate in. Prominent in the financial spade especially, but the trend is the same everywhere.

Reason may eventually help ocaml move closer into those spaces, as people are coming to ML with more openness and are more eager to learn and get involved, so that'll be cool to see in the future.

Anyways, don't count F# out either. I'm no expert, only ever used it with other project leads and with smaller clients, but MS is doing impressive work lately, like NET Core and stuff like that. They at least can show that making net more visible and flexible is part of what they're after.

Java won't be killed. Ever. But people may stop writing it eventually.

Re: Towards Scala 3

#129
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. Secondly, the implicit concept makes the code difficult to read. Then I would add that the differentiation between function & variable isn't always clear and sometimes you don't know what you call.

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

Re: Towards Scala 3

#130
post #5

Its fascinating process where if you're a hot new language you attract a lot of people that like shiny new things. When the next hot new language comes along and those people move on - have you attracted enough of the secondary wave to keep alive? Its going to be interesting to watch Scala adoption in the next few years.

I believe they have. There are quite a few mentions of Kotlin in the comments here, but I've personally seen far more Scala in business settings.
Post reply on HN