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

311–320 of 383 posts

Re: Towards Scala 3

#311

Post by threeseed »

eeperson wrote: post #215
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…

What problems did you have with sbt? Depending on how long a go you used it, those problems might have been fixed. In the last couple of years, a lot of simplifications have been made to how sbt build scripts are written.

SBT is the worst build tool I've seen in the 20 years of programming across a dozen languages.

And by a very, very long margin. It has arcane syntax, is slow, is incredibly complex if you want to extend functionality, it has multiple configuration files, the ridiculous Ivy global lock and inability to fetch Ivy artefacts in parallel etc. And that's just the start.

Re: Towards Scala 3

#312

Post by Joeri »

MichaelMoser123 wrote: post #218
lmm wrote: post #192

Earlier quoted context omitted.

The reality is that a language lives or dies by its ecosystem - particularly when it comes to a language like Scala that's in a tightly symbiotic relationship with its IDEs (the next time someone tries to sell you a "visual programming language", look at Scala for a language that makes really effective use of the GUI for programming without compromising the things that make textual programming languages good - see e.…

> if the language is to live, I have to convince other people it's the best Aren't JVM languages interoperable - because they use the same classfile/byte code format? What does it matter if the jar is written in java or scala, as long as it is possible to use the external interface from any of these languages?

The bytecode is the same but not the standard library of classes. Scala uses different collection classes, Option instead of Optional, companion objects instead of static classes, etc...

In my experience mixing scala and java in a single codebase is inelegant, with plenty of conversion code at the boundaries.

Re: Towards Scala 3

#313

Post by catnaroek »

DandyDev wrote: post #174

It's amazing how many people in this thread justify their own language choices by making negative, sweeping statements about another language (Scala in this case) that is successfully used by people other than themselves. Yes, some people who previously used Scala, now use Kotlin. And some people who would've used Scala if Kotlin didn't exist, use Kotlin. Same probably goes for Rust. But there is a big enough market…

> intricate and expressive type system that Scala gives you

Most of the complexity of Scala's type system comes from a desire to be compatible with Java, rather than to actually make it more expressive. For example, nominal subtyping is a nightmare for inference, and Scala's designers designed that they would rather sacrifice inference (which contradicts the assumption that the only raison d'être for Scala's complexity is to maximize expressiveness) than Java compatibility.

> People who don't want to deal with Rust's memory management and/or don't have a use for that.

Rust's memory management actually increases expressiveness in the sense that is usually appreciated by static typing proponents: it expands the space of properties that can be verified by type checking, relative to what other typeful languages offer. It is not immediately clear what Scala offers in this regard, compared to, say, Haskell or OCaml, which are significantly less complex. More easily broken parametricity?

Re: Towards Scala 3

#314

Post by joshlemer »

ionforce wrote: post #285
pacala wrote: post #161

Earlier quoted context omitted.

> If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem. Seconded. Between http://www.lihaoyi.com/mill/ and https://bazel.build/ , there are plenty of alternatives.

Scala enthusiast Jon Pretty just announced `fury` as well!

Do you have a link to that? I can't seem to find it.

Re: Towards Scala 3

#315

Post by setr »

lmm wrote: post #192
DandyDev wrote: post #174

It's amazing how many people in this thread justify their own language choices by making negative, sweeping statements about another language (Scala in this case) that is successfully used by people other than themselves. Yes, some people who previously used Scala, now use Kotlin. And some people who would've used Scala if Kotlin didn't exist, use Kotlin. Same probably goes for Rust. But there is a big enough market…

The reality is that a language lives or dies by its ecosystem - particularly when it comes to a language like Scala that's in a tightly symbiotic relationship with its IDEs (the next time someone tries to sell you a "visual programming language", look at Scala for a language that makes really effective use of the GUI for programming without compromising the things that make textual programming languages good - see e.…

I'm not sure I see anything in that post that's tied to scala in particular, or even really visual programming. Are you referring to the hints? The parameter names hints seem to be result of having functions in general, and type hinting look like a direct result of static typing; I like the idea, but it doesn't appear to me to be tied to Scala the language at all.

It looks like its just tied to the jetbrains ide

Re: Towards Scala 3

#316

Post by setr »

DandyDev wrote: post #210
munificent wrote: post #201

Earlier quoted context omitted.

> Why are people so intent to bash sombody else's language choices?! Partially it's simple tribalism. But part of it is also the rational awareness of the opportunity cost of investing in a language other than the author's preferred one. The more people using language X that I don't like, the fewer people using my preferred language Y. That means fewer libraries I can use, docs I can read, bugs that get fixed, etc. L…

That might be true to some extend, but many languages have completely different target audiences. People whose favourite language is Go, will probably not move to Scala (and vice versa). Kotlin vs Scala is an easier to understand competition. In any case, if people want other people to invest in "their language", they should focus on making that language and its ecosystem compelling to use, not bash other languages..…

>That might be true to some extend, but many languages have completely different target audiences

Thats somewhat by happenstance though isn't it; you take go, build a good enough scientific computing library, and tease out good enough performance, and get enough coworkers on it, and you'll probably have Go advertising itself as a scientific computing language (when talking to the relevant people).

And then you'll probably have go language devs implementing features better targetting the scientific computing community

And as the new people feed in, and implementing their own needs and libraries, suddenly go becomes good at ML...

And eventually we reach an 80s C-like status, advertised for nearly everything, because of its heavyweight ecosystem.

In terms of ecosystem, its really not constant for what they're good at. What might be constant is the flavour of programming the language prefers; you're probably not getting rid of goroutines as a significant language feature no matter how big Go gets.

Re: Towards Scala 3

#317

Post by clhodapp »

ionforce wrote: post #282
lmm wrote: post #263

Earlier quoted context omitted.

I mean if you write something like: (for { x the answer will be rather surprising, because in Scala for/yield is not necessarily monadic.

It's only surprising if you ascribe monadic properties to that syntax versus understanding it as literal syntactic sugar and absolutely nothing else.

I would say: it is `Set` and `List` that are wrong in that example, not `for`. That said, `for` really does have some issues (enter https://github.com/oleg-py/better-monadic-for/blob/master/RE...)

Re: Towards Scala 3

#318

Post by nradov »

DandyDev wrote: post #174

It's amazing how many people in this thread justify their own language choices by making negative, sweeping statements about another language (Scala in this case) that is successfully used by people other than themselves. Yes, some people who previously used Scala, now use Kotlin. And some people who would've used Scala if Kotlin didn't exist, use Kotlin. Same probably goes for Rust. But there is a big enough market…

Part of the issue with alternative JVM languages is that there isn't a good standard way to mix them within a single application. There are various compatibility layers for calling foreign functions but nothing baked into the lower-level platform. So that forces a degree of competition and mutual exclusion.

Whereas with Microsoft's .NET CLR there's a standard calling convention supported by all the languages. So it's easy to mix and match C#, F#, VB.NET, etc within a single application or reuse libraries. So developers have more freedom to pick the best language for each problem domain.

(It looks like Hacker News filters out the Unicode sharp symbol. Why?)

Re: Towards Scala 3

#319

Post by eeperson »

threeseed wrote: post #311
eeperson wrote: post #215

Earlier quoted context omitted.

What problems did you have with sbt? Depending on how long a go you used it, those problems might have been fixed. In the last couple of years, a lot of simplifications have been made to how sbt build scripts are written.

SBT is the worst build tool I've seen in the 20 years of programming across a dozen languages. And by a very, very long margin. It has arcane syntax, is slow, is incredibly complex if you want to extend functionality, it has multiple configuration files, the ridiculous Ivy global lock and inability to fetch Ivy artefacts in parallel etc. And that's just the start.

> SBT is the worst build tool I've seen in the 20 years of programming across a dozen languages. > > And by a very, very long margin. It has arcane syntax, is slow, is incredibly complex if you want to extend functionality

This seems a bit hyperbolic and a little vague. So, I can't really address it directly. Interestingly, I find sbt much easier to extend than most build tools because sbt tasks generally don't rely on side effects to communicate. Obviously YMMV.

> it has multiple configuration files

Doesn't every build tool have this? Or do you mean multiple config file formats? If that is the case, newer version of sbt have moved a single file format.

> the ridiculous Ivy global lock and inability to fetch Ivy artefacts in parallel etc

I can understand this concern. Ivy is kind of annoying. Fortunately, a new artifact resolver called Coursier[1] has been written and it solves this problem. You can use it now and it is currently in the process of being integrated as part of the default SBT install[2].

[1] https://github.com/coursier/coursier [2] https://github.com/sbt/sbt/issues/2997

Re: Towards Scala 3

#320

Post by eeperson »

jrq wrote: post #258
eeperson wrote: post #215

Earlier quoted context omitted.

What problems did you have with sbt? Depending on how long a go you used it, those problems might have been fixed. In the last couple of years, a lot of simplifications have been made to how sbt build scripts are written.

Macros going wrong with complicated builds, implicits galore all over the place, just the usual complaints. The thing that makes sbt difficult in practice for me is twofold. I don't want to deliver hackedy shit to a client that I then have to defend if their quality control comes back complaining about it. Being able to use regular scala in sbt definitions is convenient but at the cost of making things expressable th…

> Macros going wrong with complicated builds, implicits galore all over the place, just the usual complaints.

I'm not sure I totally understand this. What do you mean by "macros going wrong"? It doesn't seem like there are that many implicits used. The mostly to add methods to strings to make expressing things more concise. Do you think implicits shouldn't be used at all?

> The thing that makes sbt difficult in practice for me is twofold. I don't want to deliver hackedy shit to a client that I then have to defend if their quality control comes back complaining about it. Being able to use regular scala in sbt definitions is convenient but at the cost of making things expressable that should wisely be done another way.

> Which brings me to the second point which is getting a sbt definition from a client and then they don't want to change it, or they don't have quality control so it's just awful, or its so bad that someone has to rewrite it for the solution. The latter being the easiest to deal with, but that also costs time.

This seems contradictory. It seems like in the first paragraph is at odds with the second. In the first paragraph, it sounds like you are saying that you want to be able to write messy builds and not have anyone complain. In the second paragraph, it sounds like you are saying you don't want deal with other people's messy builds. Am I understanding correctly? If so, do you want messy builds or not? How is this related to the build tool? What build tool prevents people from writing messy builds? Are you thinking of something like maven that is very rigid?

> For those looking, what things do you feel have most improved the sbt experience?

Some things that may (since I don't know when you last looked) have improved:

* SBT 0.13 greatly improved the .sbt build file syntax (no more line breaks between settings, multi project in one file)

* SBT 0.13 also cleaned up the symbol soup. Now to define tasks/settings you only need to know 3 symbols that are fairly self explanatory ':=', '+=', and '++='. If you want to depend on another task/setting output you just have do `taskName.value` in your task/setting definition.

* A new artifact resolver has been written[1] that fixes all of the issues with ivy. It can be used today and is currently in the process of being integrated in the default SBT install.

* SBT 1 introduced a build server concept with language server protocol support that is starting to improve IDE/editor integration

* This isn't strictly SBT but IntelliJ now natively understands .sbt files so you can autocompletion and code navigation.

[1] https://github.com/coursier/coursier

Post reply on HN