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

71–77 of 77 posts

Re: Explicit term inference with Scala 3

#71

Post by funcDropShadow »

zug_zug wrote: post #69
benjaminjackman wrote: post #57

Earlier quoted context omitted.

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…

Well, neither I, nor anybody at the startup I work at apparently (it would seem) has been able to figure it out. Out of curiosity, how many hours do you think it would take to get the compile time down? I wonder if we could find somebody to help us with that.

At first I would try sbt-tmpfs, and then the largest factor in compile time imho are dependencies. Make sure that you split your project in submodules of semantically valid units. That reduce the amount of code that has to be analyzed. And then make sure that you don't have many unused imports.

In every project I've been are some former Eclipse users that are accustomed to collapsing all imports and adding new ones automatically. They never look at their ever growing list of unused files that are searched, loaded, and parsed.

Re: Explicit term inference with Scala 3

#72

Post by vvillena »

lmm wrote: post #65
vvillena wrote: post #52

Earlier quoted context omitted.

"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…

> "runMain" is still "runMain", I don't know where that comes from. Ah, I got it backwards: old tutorials say to use "run-main", and if you do run-main now you get "Expected ';'". > 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 i…

Although the silly "Expected ':'" is still there, the newer SBT versions show better output, there's even a "did you mean" feature.

Regarding "discovering which submodule you're supposed to run commands in": this is a non-issue. Commands are either run under the obvious subproject (e.g. "api/run", "business-logic/test"), or are run as top-level commands. This is true 99% of the time. I have a fairly complex project open right now, and I just run "docker:publishLocal" to create two separate Docker images, one for each subproject that includes the appropriate plugin. I think this is better than overloading a single command. SBT projects usually have a small readme describing what is the command for any specific task you're supposed to do. In Maven, you know the commands, but you need to read to ensure what they do (does "deploy" push to an artifact repository, does it create a container image, does it create a deb package, or does it create a standalone jar?).

The use case where a multimodule project becomes multiple projects is more gradual in Maven, I fully agree on this. The problem, as I said, lies in that child Maven projects are not self-contained. They usually depend on information declared in the parent builds. This breaks the assumption that people can work on a project without worrying about the parent project.

Finally, source dependencies are explicit in SBT save for the base case "test depends on main". Everything else must be specified, so it's either there in the build file, or added as part of a build plugin. It can also be checked from the REPL. And building from the IDE is a dumb mistake if the IDE doesn't use the correct build tool underneath: the build is there for a reason and the IDE shouldn't bypass it.

Re: Explicit term inference with Scala 3

#73

Post by SOLAR_FIELDS »

Fiahil wrote: post #62
SOLAR_FIELDS wrote: post #60

Earlier quoted context omitted.

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 f…

> Gradle is just so much better than SBT in almost every way aside from simplicity. I picking this up, because it was also mentioned in a sibling comment. Let's continue this discussion. It doesn't matter if we have multiple alternative to SBT, some more usable than other. Rust has one package manager (+build tool +distribution tool): Cargo. That's it. Whatever the project you just cloned and whatever the platform yo…

The canonicalization does happen with Gradle like with Rust, only at a higher (JVM) level. If you work somewhere that has Java, Groovy, Scala and Clojure projects being able to canonically clone any of them and build them with ./gradlew clean build is amazing. That forces your org to completely adopt Gradle but that’s not terribly difficult for a technically minded leader to enforce. Of course, that only applies in certain circumstances, and as you imply using the right tool for the job is the most important thing.

Re: Explicit term inference with Scala 3

#74

Post by SOLAR_FIELDS »

tasuki wrote: post #61
SOLAR_FIELDS wrote: post #60

Earlier quoted context omitted.

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 f…

We have recently switched from SBT to Gradle and I'm finding Gradle a lot more painful than SBT. For starters, SBT had a nice interactive shell, while Gradle takes quarter minute just to list the available tasks, after which it's another quarter minute to get anything else done...

Gradle is undoubtedly slower. However it’s at least 10x more capable of doing various things around building your app like testing, building images, publishing, etc. Like if I needed to build, fat jar, test and publish a multiproject repository I would almost certainly want to use Gradle over SBT.

But Gradle is probably a bit overkill for a single entry point small app that does one thing and has minimal testing needs (though it can certainly do that!). You wouldn’t bring in a dump truck whenever a pickup would work just fine.

Re: Explicit term inference with Scala 3

#75

Post by benjaminjackman »

zug_zug wrote: post #69
benjaminjackman wrote: post #57

Earlier quoted context omitted.

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…

Well, neither I, nor anybody at the startup I work at apparently (it would seem) has been able to figure it out. Out of curiosity, how many hours do you think it would take to get the compile time down? I wonder if we could find somebody to help us with that.

It kind of depends on what you are looking for. It sounds like it's improving compilation times while you develop so you can get errors messages from the compiler and so on faster which SBT incremental compilation should help with.

Are you guys currently using SBT? If so, is incremental compilation not working for some reason (or are you not aware of it?).

In terms of time, it would really depend on the size of the project and what is currently in place. It could be a couple of hours to a few days.

BTW my email is in my hn profile you want to discuss more privately.

Re: Explicit term inference with Scala 3

#76

Post by zug_zug »

benjaminjackman wrote: post #75
zug_zug wrote: post #69

Earlier quoted context omitted.

Well, neither I, nor anybody at the startup I work at apparently (it would seem) has been able to figure it out. Out of curiosity, how many hours do you think it would take to get the compile time down? I wonder if we could find somebody to help us with that.

It kind of depends on what you are looking for. It sounds like it's improving compilation times while you develop so you can get errors messages from the compiler and so on faster which SBT incremental compilation should help with. Are you guys currently using SBT? If so, is incremental compilation not working for some reason (or are you not aware of it?). In terms of time, it would really depend on the size of the p…

Yeah we are using SBT. I'm off this week, but next week I can try to see if this has legs. I checked your profile but didn't see an email.

Re: Explicit term inference with Scala 3

#77

Post by lmm »

vvillena wrote: post #72
lmm wrote: post #65

Earlier quoted context omitted.

> "runMain" is still "runMain", I don't know where that comes from. Ah, I got it backwards: old tutorials say to use "run-main", and if you do run-main now you get "Expected ';'". > 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 i…

Although the silly "Expected ':'" is still there, the newer SBT versions show better output, there's even a "did you mean" feature. Regarding "discovering which submodule you're supposed to run commands in": this is a non-issue. Commands are either run under the obvious subproject (e.g. "api/run", "business-logic/test"), or are run as top-level commands. This is true 99% of the time. I have a fairly complex project o…

> does "deploy" push to an artifact repository, does it create a container image, does it create a deb package, or does it create a standalone jar?

"package" creates some kind of package, "deploy" pushes it to some kind of artifact repository. The details of what kind of package and what kind of repository will vary from project to project, but you don't need to know them to start work on the project. In theory there could be projects out there that do surprising things (after all, nothing actually stops you from configuring your build to push a container image to a repository when someone runs "mvn test"), but the overwhelming majority of projects find a way to fit themselves into the maven lifecycle, and it really reduces the "where do I start" effect when you check out a new project: I don't have to read the build file or hunt for documentation, I can run "mvn install" and see what it does, and be confident that that's "how you build this project".

> The problem, as I said, lies in that child Maven projects are not self-contained. They usually depend on information declared in the parent builds. This breaks the assumption that people can work on a project without worrying about the parent project.

Well, SBT projects also come with a bunch of default tasks that aren't defined explicitly in their project definition; some of them are defined by plugins and some of them are defined... somewhere (I genuinely don't know where the tasks that are available by default come from, or how to see a list of all of them except by using the interactive commands). So an SBT project is not self-contained in that sense either. In maven anything that's not explicitly defined in the project is coming from its parent pom, which is either the default parent pom or an explicitly specified one, and the default parent pom is a real pom that you can look at that follows the normal rules.

So you do have to understand the concept of a parent pom, but it's not an extra thing that you have to understand, because the default parent and any parent pom you're using in a multi-module project work exactly the same way.

> And building from the IDE is a dumb mistake if the IDE doesn't use the correct build tool underneath: the build is there for a reason and the IDE shouldn't bypass it.

Yes and no: the IDE has a bunch of knowledge of its own that the build tool doesn't, such as which files the user has changed, or which specific test the user has asked to run, or which import the user wants to add a dependency for. So I don't think the idea of the IDE dumbly invoking the build tool and letting it do its thing works (particularly in a language like Scala where you have to rely heavily on incremental compilation if you don't want enormous build times); instead there needs to be a deeper integration where the build tool and the IDE share a structured model of the project, and the IDE can perform a build via that model (effectively embedding part of the build tool as a library, if you like). Likewise I don't want to invoke a separate build REPL to understand the project definition, I want to be able to explore it within the IDE.

Post reply on HN