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

Explicit term inference with Scala 3

scala-lang.org

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Explicit term inference with Scala 3

#51

Post by lmm »

JackFr wrote: post #36
lmm wrote: post #18

Earlier quoted context omitted.

I very much disagree; the only people I've known to have trouble with Maven are experienced developers who expected their build tool to work in a very specific way (i.e. that they would define a bunch of commands for it to execute and tell it what to do). For a beginner who comes to it with no preconceptions, maven is very easy: you fill in the parts your XML editor tells you to, list your dependencies, and then run…

The things I want to do, are they ‘goals’, ‘tasks’, ‘phases’ or ‘executions’? And do I manage my dependencies in ‘dependencies’ or ‘dependencyManagement’? And how is it that none of the ‘dependency’ goals can tell me the origin of the version - I have to use ‘help:effectivePom’? Maven is powerful and people forget how innovative it was. But it’s not easy.

> The things I want to do, are they ‘goals’, ‘tasks’, ‘phases’ or ‘executions’?

The page I linked to is pretty clear about which is which and what they do.

> And do I manage my dependencies in ‘dependencies’ or ‘dependencyManagement’?

You list your dependencies in dependencies, you manage them in dependencyManagement. But it's clear in the documentation, and if you're looking at a tutorial from 10 years ago then it'll still be accurate.

There are confusing things in maven. But documentation and backward-compatibility go a long way, and I really think the fixed build lifecycle puts it head and shoulders above a lot of alternatives; the cost/benefit of each project having a slightly different set of build commands just doesn't stack up.

Re: Explicit term inference with Scala 3

#52

Post by vvillena »

lmm wrote: post #22
vvillena wrote: post #11

Earlier quoted context omitted.

SBT is easy to use at the beginning, simply because the build files are 1/10 the length of a Maven XML build description, the console output looks better, the build REPL has lots of commands that make things easier, and the simple projects just work fine. Once you start to dig deeper, you find out that setting multimodule projects is still easier in SBT. And if you decide to dig deep and really learn the build tool,…

> SBT is easy to use at the beginning, simply because the build files are 1/10 the length of a Maven XML build description, the console output looks better, the build REPL has lots of commands that make things easier, and the simple projects just work fine. The build REPL has lots of commands that aren't documented, and when you search for tutorials the commands have changed (e.g. runMain is apparently now run-main,…

"runMain" is still "runMain", I don't know where that comes from. There are lots of available commands indeed, due to the nature of SBT, but a basic workflow always uses the same commands: compile, test, run. Any extra tasks used usually come from plugins, just like in Maven. And reading documentation is needed for configuring and running those, just like in Maven. Projects should document why each plugin is included, and how to do things, because every project is indeed different. The difference is the extra configuration needed by each plugin is about 1/10 the size.

Maven multimodule projects are strange. Yes, modules can work without knowledge of what's above them, but that's not usually what we want to do, because it means lots of duplication (e.g. dependencies) which can then lead to inconsistencies. And if the common settings are defined within the parent project, it stops being self-contained. SBT accepts this reality and that's why multimodule projects are a thing. And having multiple subprojects in SBT doesn't mean that suddenly some of them work and some don't. By default, every project has the same settings (save for the obvious ones, like where the sources are). Any extra settings and task definitions just tell SBT to do extra things when certain tasks are run. One quick example: if you enable the integration test configuration just for some subprojects, the ones that don't have them don't start to fail. They correctly report a "successful, 0 tests run, 0 test failed". By the way: creating a separate integration test config in Maven is painful, up to the point that people recommend to just add a new subproject that contains them. Yay, more nesting!

Regarding SBT current shortcomings: that article correctly points out lots of issues, like the lack of tooling. To this day, IntelliJ still has issues downloading the correct SBT sources. And when they work, there's no easy way to find the actual code that does the work. That should be improved, because for lots of plugins, a quick look at the source is just what's needed when working on the build. Namespacing is a problem too. The internal complexity of the core SBT concepts is complained about too, but that's not as solvable as the other two things.

All in all, Maven and SBT are different tools that focus on different issues, and choose different sides in the consistency vs flexibility tradeoff.

Re: Explicit term inference with Scala 3

#53

Post by zug_zug »

maattdd wrote: post #33
Fiahil wrote: post #31

Earlier quoted context omitted.

In no particular order: - the JVM - the tooling for writing with VSCode - SBT - NullPointerExceptions bubbling up from Java libs - the split between the functional programming community and the "Scala is just Java without ;" one - everything related to implicits (creation, resolution, etc) and everyone using them - the ability to write the same 0-100 loop with 4 different keywords and 3 different styles - the inabili…

- compilation time

Seriously.

I modify a single line, in a single file, and the scala system takes 2-3 minutes to recompile at work. Apparently it spends over a minute inferring types!

Hello! The types are EXACTLY THE SAME AS ALWAYS. Please cache the whole typing phase as a build artifact based on file/directory hashes. Maybe even make this cache source-control-safe.

Re: Explicit term inference with Scala 3

#54

Post by zug_zug »

zmmmmm wrote: post #12
xyzzy_plugh wrote: post #5

This is a nice write-up, it's beeb some time since I've written Scala and Scala 3 looks promising. Though, I am curious if there is anyone else who shares my mindset on Scala. In a corporate environment, I found it to be an extremely expressive and powerful language but that power comes at a grave price, which I'll try to summarize: - it's difficult to understand other people's code compared to other languages (e.g.…

Agree. It's a shame because I do believe it is very much cultural - it is possible to write very clear, expressive and safe Scala code. But it doesn't seem the community has settled on that as a cultural idiom. Instead they frequently favor maxing out the power of the language and type system at every opportunity and that means you often encounter lines of code that look like a string of hieroglyphics, or functional…

AkkaHttp being the main offender imo. If something as braindead simple as "routing http requests" can't be expressed without magnet-pattern / 5+ nested levels of curly braces / odd-compile-errors / magical punctuation functions / 0-debugging then your library has failed.

If I can't understand the type of a route (or a db-query) because it's a 5-level nested type, how am I going to write a function that takes one as a parameter?

Re: Explicit term inference with Scala 3

#55

Post by hocuspocus »

sabellito wrote: post #50
hocuspocus wrote: post #48

Earlier quoted context omitted.

> How does my editor let me know that function receives that parameter without me going "???" and having to go into its definition? IntelliJ has been able to do that for a while now. > Implicit conversions fall into the same category, of making code pretty to look at, quick to write, and a nightmare to understand when you're new to a codebase. Don't do it, and don't allow it in your codebase.

> IntelliJ has been able to do that for a while now. It has been 4 years since I did Scala everyday, back then it was hit or miss. Good to know things have improved. > Don't do it, and don't allow it in your codebase. I get your point, but that doesn't solve the issue if the community is down for using these features.

Both JetBrains and the Scala center have invested in the tooling experience in the past 2-3 years, you should give it a try again!

And I don't think I've encountered implicit conversions that often in the ecosystem.

Re: Explicit term inference with Scala 3

#56

Post by meowzero »

xyzzy_plugh wrote: post #5

This is a nice write-up, it's beeb some time since I've written Scala and Scala 3 looks promising. Though, I am curious if there is anyone else who shares my mindset on Scala. In a corporate environment, I found it to be an extremely expressive and powerful language but that power comes at a grave price, which I'll try to summarize: - it's difficult to understand other people's code compared to other languages (e.g.…

Scala is my favorite language, even though I don't work with it professionally anymore. And I've seen it all. And yes, bad code in Scala is probably harder to read than bad code in other languages. It can be outright painful. However, good clean code in Scala is easier to read IMO. I think it takes a strong culture and strict standards for an organization to adopt understandable Scala. Unfortunately, those organizations are rare and there will be people who will likely abuse some of the "clever" features of Scala. I've been fortunate to be in those organizations with good clean code (and places with unreadable Scala code).

Re: Explicit term inference with Scala 3

#57

Post by benjaminjackman »

zug_zug wrote: post #53
maattdd wrote: post #33

Earlier quoted context omitted.

- compilation time

Seriously. I modify a single line, in a single file, and the scala system takes 2-3 minutes to recompile at work. Apparently it spends over a minute inferring types! Hello! The types are EXACTLY THE SAME AS ALWAYS. Please cache the whole typing phase as a build artifact based on file/directory hashes. Maybe even make this cache source-control-safe.

I am curious if you are using SBT incremental builds? (putting aside how hard it can be to get and keep SBT working for a project ... I was the guy that had to do that so I know that pain quite well). Because in my experience with really large scala projects that should not be the case, unless you modify a file at the very top of the dependency tree.

We used what I would call the package object predef pattern, which basically involved, rolling your own predef to have certain functions / extension classess / objects always in scope through package objects added to each sub-project. And the build would cross-compile both jvm scala and scalajs. It would not take more than a second or two unless one of those predef files were touched (which would fire off effectively a full rebuild).

Re: Explicit term inference with Scala 3

#58

Post by vvillena »

sabellito wrote: post #50
hocuspocus wrote: post #48

Earlier quoted context omitted.

> How does my editor let me know that function receives that parameter without me going "???" and having to go into its definition? IntelliJ has been able to do that for a while now. > Implicit conversions fall into the same category, of making code pretty to look at, quick to write, and a nightmare to understand when you're new to a codebase. Don't do it, and don't allow it in your codebase.

> IntelliJ has been able to do that for a while now. It has been 4 years since I did Scala everyday, back then it was hit or miss. Good to know things have improved. > Don't do it, and don't allow it in your codebase. I get your point, but that doesn't solve the issue if the community is down for using these features.

The community isn't very fond of implicit conversions. That's why you get warnings unless you enable a compiler flag, and why Scala 3 downgrades them from magic keyword definitions to avoidable stdlib types.

Re: Explicit term inference with Scala 3

#59

Post by natchy »

aphexairlines wrote: post #27
lmm wrote: post #7

Earlier quoted context omitted.

> Scala is a beast and the package manager + build tools were giving me headaches. Ignore them and use maven. It's much better documented, consistent, and backwards-compatible. I struggle to understand why SBT ever gained any popularity, and it should certainly have never been recommended to newcomers.

or gradle, or bazel. Scala doesn't require sbt, and the other build tools work well for mixed codebases (scala, java, kotlin, javascript).

One of the reasons I chose F#. Too many choices for a Scala novice. Seems to be a pervasive pattern.

I think Scala was actually a better choice since my company mainly does AI/ML (python) and Scala has some clout in data science. But I’m only migrating the application layer so not a deal breaker.

I was leaning more towards Scala going into the “exploration phase”.

——————————

Side note. Using typescript on front end, f# on back, vscode, and GitHub for repo + CI/CD. Feels nice using a single vendor (Microsoft) for dev, even though each tool is stand-alone.

Re: Explicit term inference with Scala 3

#60

Post by SOLAR_FIELDS »

Fiahil wrote: post #31
aphexairlines wrote: post #25

Earlier quoted context omitted.

what did you resent?

In no particular order: - the JVM - the tooling for writing with VSCode - SBT - NullPointerExceptions bubbling up from Java libs - the split between the functional programming community and the "Scala is just Java without ;" one - everything related to implicits (creation, resolution, etc) and everyone using them - the ability to write the same 0-100 loop with 4 different keywords and 3 different styles - the inabili…

I wrote Scala for three years or so professionally and agree with most of your points. A couple of comments though that haven’t been addressed by the sibling commenter who also addressed some of your points:

- JVM is JVM I guess. You either love it or you don’t. I personally really enjoyed the access to the ecosystem so that was a major boon for me.

- Gradle is just so much better than SBT in almost every way aside from simplicity. I found building Scala projects with Gradle to be quite straightforward and nearly every project that supports SBT also supports Gradle.

- I agree about VSCode tooling but I do want to establish that there are actually really nice tools for writing code in Scala - specifically Jetbrains is quite great. I am not saying your point is any less worthwhile, only that I don’t want someone to read your comment and take away that there are no good code assistance tools for writing Scala.

- Agree with the Java NPE’s. This is annoying

- Entirely agree with implicits. The Scala team either needs to better educate people on how to use them or just tell people not to use them unless it’s a very specific circumstance. I cannot tell you how many times I’ve dived into someone else’s code and spent literally hours trying to coax the compiler to do something that was bizarrely prevented by a poorly thought out usage of implicits.

- it is definitely possible to write “Scava”, and I wouldn’t really recommend a team adopting it without someone having at least a decent background in functional programming. Otherwise you might as well write Java if you are going to write imperatively.

- Yes, I find that the usage of symbols in Scala is a bit excessive, but once you learn what they do it does feel more terse and concise. It doesn’t stray into the illegibility of Perl IMO.

Overall it’s a nice language, fun to write in, but a bit frustrating at times. I wouldn’t use it personally at home but it does fill a nice niche professionally and it’s absolutely great for writing Spark code.

Post reply on HN