search

VirtusLab / scala-cli

Scala CLI is a command-line tool to interact with the Scala language. It lets you compile, run, test, and package your Scala code (and more!)
https://scala-cli.virtuslab.org
Apache License 2.0
549 stars 129 forks source link

[Feat] Scripting with instant startup #3127

Closed jatcwang closed 1 month ago

jatcwang commented 2 months ago

Is your feature request related to a problem? Please describe.

I'd like to be able to write a scala-cli script which supports instant startup (via compiling to native binaries).

Currently scala-cli supports compiling to native binaries via scala-native or GraalVM native-image.

However:

  1. There seems to be be a bit of delay in running scripts even if there are no changes (Around 0.3s on my computer). I'm guessing this is due to compilation (even if it's a no-op)
  2. When using GraalVM native-image, there's no currently no single command to compile and run a script. I think we only have scala-cli --power package --native-image my_script.scala -f -o my_bin to generate the binary.

Describe the solution you'd like

  1. Make change-detection faster (if possible)
  2. Provide a single command to execute a script by first compiling it to GraalVM native binary

If we can make no.1 instant then we would've solved the instant start-up issue for scala-native binaries

Additional Context In https://github.com/jatcwang/instant-scala, I have a bare-bones wrapper bash script which compares the cached and current hash of the script file and runs the cached native binary if they're the same.

lbialy commented 2 months ago

This seems quite contradictory - on one hand you'd want instant startup, something that's only possible with either a hot jvm running in the background or a native binary. On the other hand you'd want this to be be free of native compilation overhead (unconstrained by native-image or scala-native) but also not to leave a running jvm behind. While I'd also want something like that, I don't think you can turn Scala into an interpreted language.

jatcwang commented 2 months ago

There were two options I listed

  1. Compile to native binary with faster change detection
  2. Persistent JVM server which executes the scripts a la nailgun

You're right that No.2 contradicts my listed desire to not have a JVM running in the background. I have removed it as it probably makes sense to be its own separate issue. I've updated the OP to focus more on no.1

Gedochao commented 1 month ago

I get the feeling that there's at least 3 different feature requests listed in the discussion above:

For us to discuss those and potentially plan them (or more likely, allow an external contributor to pick them up), those would need to be raised as separate feature requests. The way the requirements are put in this issue, I can't see how we'd start the work on this.

Additionally, we may not be able to consider these things before the package sub-command gets redesigned, as per the discussion in https://github.com/VirtusLab/scala-cli/discussions/1794 (which is not even defined in an issue yet, although has been heavily discussed elsewhere).

I'd advise to start a discussion on your use case before raising subsequent feature requests.

Gedochao commented 1 month ago

Closing this for now, please re-raise the individual points separately (perhaps a discussion thread would be better first)