My 2 cents but I believe <https://blog.jetbrains.c...

# scripting

[mbonnin]

My 2 cents but I believe https://blog.jetbrains.com/kotlin/2024/11/state-of-kotlin-scripting-2024/ may hurt Kotlin scripting more than it's helping. In this tldr; era, the post sounds like a deprecation notice while it's actually quite the opposite? It's about focusing the scripting effort where it matters most?

[Piotr Krzemiński]

do you mean it may discourage using scripting more widely? I think we need to see some concrete problems being fixed as a kind of proof that scripting is alive and kicking (I'm aware of one issue fixed in the newest IntelliJ related to scripting). Once the general UX becomes better, it should naturally attract more folks

[mbonnin]

Yea, because people know I'm a big fan of scripting, I got pinged twice already to have my thoughts there 😅

[mbonnin]

And clearly, my thoughts are that main.kts can advantageously replace bash for like 90% of use cases

[Piotr Krzemiński]

yeah, it already does for me

[mbonnin]

The main issue is including scripts from scripts (which I think we discussed already but can't remember where 🙃). But for small scripts and CI especially, the DX is pretty great IMO. In all cases, much superior to shell 😅

[Piotr Krzemiński]

we discussed it under the latest roadmap update here 🙂

[mbonnin]

Ah! I knew it!

[Piotr Krzemiński]

it looks like scripting got to a point where fixing the pain points with multi-file scripts would require a serious redesign of some parts (that's what I learned from the Kotlin developer some time ago, somewhere...)

[Piotr Krzemiński]

and to be honest, I don't think that the current approach with including source code of other Kotlin files (@file:DependsOn("SomeFile.kt") ) is the best one, considering how e.g. Python does it. But with Python, there's a difference that each file is a separate module and effectively a namespace, where in Kotlin one can have .kt files on the same level, and upon importing we don't specify the file, just an arbitrary package. That's true both in the "standard" Kotlin, and scripting inherits this behavior which seems logical

[Piotr Krzemiński]

so there's certainly some design investment needed here to make things work nicely long-term

[mbonnin]

True that part needs polishing but the current language of the post might discourage users from replacing their simple shell scripts.

Case in point: https://x.com/androiddevnotes/status/1859061750567407652

[Piotr Krzemiński]

Yeah, it doesn't look good, I mean - it's taken out of context definitely. Was scripting ever announced to be a replacement for shell/Python?

[Piotr Krzemiński]

The "no longer" part is misleading, and not true

[Eugen Martynov]

What about the plugins support?

[Eugen Martynov]

Sorry for entering discussion

[mbonnin]

I personally don't mind not having plugins support. For an example, I do all my Json parsing using parseToJsonElement() and force casting everything. This for quick scripting. If I need a more robust solution, I can create an amper or gradle project. I'd say the tradeoff is acceptable

[Piotr Krzemiński]

I wish scripting was consistent with what regular Kotlin can do, to facilitate knowledge transfer and the number of "but"s one has to use when introducing someone to scripting. So yeah, I'd like to see compiler plugin support at some point. But first I'd like to see the long-standing bugs fixed

[mbonnin]

Another case: https://www.reddit.com/r/Kotlin/comments/1gv4j8j/state_of_kotlin_scripting_2024/

[mbonnin]

I wrote my thoughts there: https://mbonnin.net/2024-11-21_state-of-kotlin-scripting/

[Jason]

Thanks for sharing your thoughts Martin! I’ve been an advocate for Kotlin scripting at work and especially using custom scripts to make integrations into our stack. Was about to build tooling like live-plugin based on this but now am hesitant. The blogpost was definitely interpreted as “kotlin scripting is dead” where I work 😢

[Marc Downie]

I'm also interested in trying to figure out what the State of Kotlin Scripting means for my particular (peculiar?) use-case --- but maybe in a more precise way. I 'depend' on the kotlin-jupyter repo as basically example code to show my how to embed Kotlin scripting in my custom hosts. The idea of a "Kotlin Kernel" seems blessed by "State of Kotlin 2024", but only insofar as it works in inside the Notebook Plugin which, presumably, has access to all of the JetBrains insides of its host. But Kotlin-Jupyter as currently written depends on scripting-ide-services the deprecation of which is the clearest bit of that document. So ... will we be able to make non-Jetbrains hosts with auto-completion support for Kotlin or not going forward?

[ilya.chernikov]

@Marc Downie, I don't know to what extent the Jupyter Kernel will be available outside of the Kotlin Notebook, maybe @Ilya Muradyan can tell.

But I can tell that scripting-ide-services library is based on the APIs that are not present in the K2 compiler. The K2 infrastructure has a new set of APIs serving the same purpose, named Analysis API. And it differs substantially enough from the old infra, so we cannot simply port the scripting-ide-services to it.
For a moment it looks like we at JB have no resources to implement new REPL code completion services on top of the new API. But all this stuff is open, so theoretically one can take Analysis API and implement autocompletion and other stuff on top of it in a non-Jetbrains host.

[Ilya Muradyan]

Hi! Kotlin kernel for Jupyter is available and will remain available outside of Kotlin Notebook plugin. But simple completion and error reporting that was there before rely heavily on scripting-ide-services so if it's not migrated to K2 infrastructure, kernel will lack this functionality

[Marc Downie]

Thanks all for the replies: the pointer to the Analysis API at least gives a me a target to keep my fate in my own hands. Not sure about the long term viability of Kotlin-Jupyter and the proudly presented statement “Kotlin-Notebook is based on Kotlin-Jupyter” if it doesn’t do autocomplete when people pip install it. Clearly JB will have to find the resources to implement completion services for Kotlin Notebook though? But perhaps that comes for free from closed source parts of the hosts you are still targeting.