Choosing the right scripting language about luna HOT 35 CLOSED

Kotlin, for sure.

Apollo has moved to Kotlin. Great tooling, great IDE support, co-routines, scripting, DSLs, fully interoperable with Java AND vice versa.

from luna.

@tlf30 I feel like java is too verbose to use for writing content. I do see the appeal in that as I looked at how Arios did their plugin system but once again, java is too verbose.

I suggest we use Kotlin as it has great IDE support, able to debug scripts, 100% interoperable with Java, JSR-223 compliant and coroutine support which is great for scripting content.

Plus we can even use Kotlin if you do decide to go with Jar based plugins as it would work as well.

from luna.

@nshusa I think depending on what you do to interface Lua with Java (like use LuaJ), coroutines are actually full fledged threads not lightweight fibers.

I think the main downsides of using Lua as a scripting language compared to Kotlin is that Lua doesn't have great tooling, doesn't have great IDE support like Intellij and plus it's not fully interloperable with Java like Kotlin is.

The transition from Java to Kotlin is not a hard one as well so considering how many of the developers who work on RSPS are java developers, it would benefit greatly. Learning other languages though is not a bad thing either but this just speeds things up if the transition is easier.

You can still design a plugin system thanks to Kotlin 1.1 as @ryleykimmel mentioned through the use of JSR-223 so scripts are 'headless' or you can compile them.

Plus Kotlin is fast too as it does compile to java byte code.

That's just my opinion though. Lua is pretty neat but Kotlin fits the majority of the criteria.

from luna.

Why not Javascript?

from luna.

I personally would rather drift away from a scripting language and use a jar based plugin system instead. I would even design it for you if you like.

Advantages of using jar plugins:

• One programming language for entire project
• Everything is compiled, so it runs faster
• Java is easy to work in

Disadvantage of using jar plugins:

• Possibly not supported in Java9 See: https://en.wikipedia.org/wiki/Java_Platform_Module_System

If you do not want to go this route, I would rather stick with scala and wait for it to be fixed. Ruby is unintuitive for java programmers, and the Apollo project has been having issues with it apollo-rsps/apollo#310. I have done my fair share of lua, and I will say that it is one of my least favorite scripting languages, I do not know how it would integrate in with Java, I have never tried to do that. Another one to consider is Groovy, I personally have never worked in it, but I know it has a similar syntax to java and is JVM based: https://en.wikipedia.org/wiki/Groovy_(programming_language)

Again, if you want to do plugins with Jar files written in Java. I would be more than happy to build the system and port over the existing plugins. I would like to implement it by placing each jar file in a common plugins folder and have a common config folder to store configs for plugins.

from luna.

So then, I see no reason why the plugins could not be written in Kotlin and be used directly by the Jar plugin system I wrote. All the Kotlin class needs to do is implement a Plugin interface I wrote and my PluginManager will load the class right from the Jar.

I think this is a great idea then.

I will continue to port over the current plugins to Java, I whould be done by today or tomorrow. Then we can keep them in Java or port them to Kotlin. Then any new plugins we write can be directly written in Kotlin.

Does that sound good?

EDIT: I think this is also good because then we do not limit plugin developers to use just Kotlin, they could also use Java to write their plugins in.

from luna.

I have finished building a Java Jar based plugin system, just in case you want to use it. It is really fast. I have about half the plugins ported over already.

from luna.

I have a working implementation of a jar based plugin system integrated into Luna, See plugin-migration. I like your idea of Kotlin, I have never worked in it, but from what it sounds like if it can be used as a jar with JSR223 then I like it.

A question then:

• Can it implement a java interface?
• With Kotlin packaged in a Jar, would we still need to use the ScriptEngine?

I agree that Java is verbose, but that is actually one of the things I like about it, makes it easy to read. The main reason I wanted to go to entirely Java was to get away from the javax.script.ScriptEngine as it adds a lot of complexity to integrating plugins that would not be necessary using only Java, and it makes a huge performance impact. Like I said, I know next to nothing about Kotlin, but I am not opposed to the idea.

from luna.

@tlf30 Kotlin is very similar to how Scala is but I would say that it's less complex and that it has better tooling support. It provides a lot of syntax sugar that allows someone to write code very quickly while being easy to read. If you would like to see some Kotlin code in action, I suggest you take a look at this: https://github.com/apollo-rsps/apollo/tree/kotlin-experiments/game/src/plugins

To answer your questions:

Can it implement a java interface?

Yes, very easily.

Here's a simple java interface:

public interface MessageReader {

	public abstract void read(Player player, IncomingMessage packet);
}

Here's a simple kotlin class implementing it:

class NpcActionMessageReader : MessageReader {
    
override fun read(player: Player?, packet: IncomingMessage?) {
        // read the stuff here...
    }
}

If you want to read more on Kotlin, here are the documentation: https://kotlinlang.org/docs/reference/

With Kotlin packaged in a Jar, would we still need to use the ScriptEngine?

No need to use the ScriptEngine. Kotlin compiles to bytecode and so it can be used just like any other java class.

from luna.

Yes that sounds good. I could lend a hand in helping with the porting when I have some time. I'm curious on what @lare96's thoughts are regarding this.

from luna.

The next question I have is I currently have the plugins I have ported over into Java inside the io.luna.game.plugin package and am loading them internally as it is slightly faster than if they were inside an external Jar. I was wondering if these plugins should be moved to an external jar or not..? I do not really care one way or another, but it was easier for me to test them as I ported them to place them there.

Another thing: my plugin system builds a JSON config for each plugin, that way any configurable data can be edited outside the code of the plugin. The plugins I have ported look at the config before performing any action that way any changes to the config during runtime are live. This works via the interface implementation, so it would work in both Kotlin and java. I think this is much better than needing to edit code like we currently do with the scala.

EDIT: I'll cleanup my plugin system and commit it to my branch tonight, the cleaned up commit will have the json config system and correct javadocs.

I would also like to know what you are thinking about this @lare96

from luna.

OK, so I have pushed my semi-finalized plugin system to my repo: plugin-migration.

If someone wants to look it over and give some feed back. I built it a little more lightweight than I normal build plugin systems.

It should work with both Java and Kotlin as long as it is packaged as some kind of Jar.

from luna.

I have moved the current plugins to a separate jar and created a project for them luna-core-plugins. I have tested this in the new plugin system, it worked beautifully.

Once I get all the plugins ported over, and we have heard from @lare96, then I will open a merge request if this is how we want to do things. The core plugins provided with the server would then be a separate project.

from luna.

To be completely honest, I'm not a fan of moving towards a JAR based plugin system. I'm also not a fan of writing game content in pure Java, as I've developed servers that way in the past and noticed how cumbersome it can get. I've looked into things a bit more and appreciate the comments about Ruby and Lua (especially the latter, as java interoperability is decent at best) so they won't be considered if we do eventually decide to change languages.

Regarding compiling scripts being faster and less complex, JSR-223's only function is to begin the bootstrapping process. The most complicated part of the plugin system is the event portion of it, which will be present whether or not code is compiled or interpreted. Once the server is online, every plugin will have been cached into an EventListener anyway so interpreting the plugins only ever happens when the server is being started. I'm actually unsure if the cached code would still be optimized by the JIT compiler, but regardless the performance differences (if they exist) are probably negligible. One of the main reasons though why I prefer script development is because of how easy it is to test and debug code. If we compile scripts the server has to be restarted whereas now plugin(s) can be asynchronously re-interpreted rather quickly (which will only be exemplified when issue #26 comes to fruition).

I'm definitely open to using Kotlin however the only thing that worries me is the lack of syntactic freedom compared to Scala (which is a marginal issue).

Overall though I'd definitely prefer just sticking with Scala, but if it comes to a point where that can't happen anymore I think we should definitely look towards Kotlin and Groovy. Thoughts on this?

from luna.

I think that using Kotlin in a compiled environment would be the best option. I am not sure how Kotlin can be used uncompiled as I have never worked in it.

As for debugging with compiled plugins, I do not think that restarting the server is an issue, especially when functionality could be configured using an external config.

@ryleykimmel how does Apollo implement their Kotlin plugins?

from luna.

Kotlin offers a scripting system which is essentially 'headless' and has a different file extension than a normal Kotlin file (.kts vs .kt). Kotlin supports JSR-223.

Apollo implements its own plugin "compiler" specifically for .kts files and has its own wrapper and bootstrap to link the World among other things for plugins to use.

You can check it out here: https://github.com/apollo-rsps/apollo/commits/kotlin-experiments

from luna.

I'm going to open a new branch in the coming days and get a basic prototype down of what a Kotlin scripting system could potentially look like.

from luna.

I was thinking of using maybe Lua or Ruby.

Definitely not Ruby, you don't want to go down the same road Apollo did.

I would actually recommend Lua. I recommending Apollo to use Kotlin way back in the day. I've been using Kotlin since 1.0. Kotlin is more of a Java replacement if anything. You don't even have to design a plugin system if you use Kotlin because you can mix Java and Kotlin within the same project without any issues as long as you compile Kotlin first.

Reasons to use Lua

• Lua has semi/asymmetric coroutines as well
• Lua is extremely lightweight
• Lua is super easy to learn
• Lua doesn't stick to 1 paradigm, so you can write code in many different styles
• Lua has been used by many big name games
• Lua like RuneScript is interpreted
• Does have a lot of tooling support (IntelliJ Lua Language Integration, Eclipse LDT, Netbeans Glider
• Andrew Gower has a high interest in Lua and almost used it as the main scripting language in RuneScape From an interview with Gower
• Lua is fast

Why not to use Kotlin

• Users are going to be forced to use IntelliJ IDEA (Eclipse Kotlin plugin is terrible)
• Compilation speed is a lot slower (2x-3x slower than Java)
• Functional types could be significantly improved. Functional types that use "Unit" must return something and occasionally have to return null. (I don't like this at all)
• Kotlin JSR-223 support sucks (Overly complicated to setup)
• Not as lightweight as Lua
• More syntax than Lua
• Unlike RuneScript, Kotlin is compiled.

I'm adopting Lua for content and Kotlin as a Java replacement.

from luna.

@abyssalen

I think the main downsides of using Lua as a scripting language compared to Kotlin is that Lua doesn't have great tooling

This isn't true at all. IntelliJ has an excellent plugin for Lua that works great. Also eclipse has solid tools as well. Eclipse LDT

You can still design a plugin system thanks to Kotlin 1.1 as @ryleykimmel mentioned through the use of JSR-223 so scripts are 'headless'.

I think I would rather prefer an interpreted language over a compiled language like Kotlin for more flexibility. Unless you really need that static type checking but Lua is so simple that's not even needed. RuneScript is interpreted and seems to be working great for RuneScape.

from luna.

@abyssalen NetBeans also has awesome Kotlin support.
@nshusa I agree entirely.

Once upon a time in my younger days I wrote an entire Lua base system library for a proprietary embeded system that the owner of which decided would run an "os" written in Lua. Yes, you laugh. I have never been so frustrated in my life trying to build a bare metal Lua interpreter and environment. Because of this I now have a great dislike for Lua.

from luna.

@tlf30
Well that's your problem haha Rust Oxide got me into Lua. It's fun making scripts for Rust.

from luna.

@nshusa RuneScript is compiled to byte code.

Kotlin has fantastic tooling for all IDE's, dunno when you've last checked but since 1.1.x everything in Kotlin is significantly better.

• Users are going to be forced to use IntelliJ IDEA (Eclipse Kotlin plugin is terrible)

  • Answered above

• Compilation speed is a lot slower (2x-3x slower than Java)

  • Benchmarks, please? And who cares? You build once before you run. I doubt build speed vs interpretation speed is all that different, tbh.

• Functional types could be significantly improved. Functional types that use "Unit" must return something and occasionally have to return null. (I don't like this at all)

  • You're using them wrong, then.

• Kotlin JSR-223 support sucks (Overly complicated to setup)

  • Ever since 1.1.x Kotlin script support works nearly out-of-box with the exception of testing (which is trivial to setup anyway if you're using gradle)

• Not as lightweight as Lua

  • Static language, of course it's not (but why does this matter?)

• More syntax than Lua

  • Static language, of course it's not (but why does this matter?)

• Unlike RuneScript, Kotlin is compiled.

  • Answered above

from luna.

@ryleykimmel I agree, as I have said, this is my first time using Kotlin. But I have NOT noticed any large performance decrease once it is compiled. I also agree that being a static language is fine. And for syntax, in my opinion Kotlin's syntax is easier to read and write than Lua, mainly because I have seen a LOT of hack jobs in lua syntax to try to get the desired result.

from luna.

@ryleykimmel

Kotlin has fantastic tooling for all IDE's

I've used Kotlin extensively on both Eclipse and Intellij IDE's I can't speak for Netbeans but eclipse plugin is far behind Intellij's. Occasionally you get intellisense issues and mixing Kotlin and Java in the same project isn't as easy as IntelliJ. Users are going to have to use Gradle to compile them separately. Pretty sure majority of the users aren't going to even know how to use Gradle. If you're going to use a JVM language as your scripting language you mise well allow users to write content in other JVM languages as well since they all run on the same bytecode.

RuneScript is compiled to byte code.

Not sure what your argument is here because many languages if not most languages are compiled into some sort of bytecode. Even interpreted languages such as Lua is compiled into bytecode. Is RuneScript compiled into bytecode? Probably. Is RuneScript compiled into java bytecode? Probably not.

According to Andrew Gower in an interview.

Me: "So does RuneScript compile down into Java Byte-Code like other languages such as Ruby, Groovy, etc?", Andrew: "No actually, it's compiled into it's own RuneScript stack code which is then interpreted in Java" See here

More syntax than Lua
Static language, of course it's not (but why does this matter?)

Syntax does matter but this is more of a personal preference.

Kotlin JSR-223 support sucks (Overly complicated to setup)
Ever since 1.1.x Kotlin script support works nearly out-of-box with the exception of testing (which is trivial to setup anyway if you're using gradle)

I had to use Kotlin Script Utils Lib, Kotlin Stb Lib, and Kotlin Compiler
to even use JSR-223 support.

from luna.

Another good reason to use kotlin is that is sounds like the Apollo guys are moving to it, so Apollo would make a good reference as to how to do the implementation.

The netbeans plugin for Kotlin is up-to-par as far as I am concerned, it does the job and understands interpolation between java and kotlin. I personally use netbeans for everything. If a plugin does not exist for what I want I just write one :D

from luna.

@tlf30 What's the point of creating a project like this then if you're going to copy Apollo?? If that's the case you're better off contributing to Apollo instead.

How is netbeans compared to intellij? I only use intellij and eclipse but intellij is my favorite. its just so smooth and its intellisense is really good.

from luna.

@nshusa my entire company does all of its development in NetBeans, we love it. NetBeans is 100% free with no licensing restrictions. It directly integrates into our development and production j2ee and db servers. Works nicely with git, maven, ant, and gradle. Netbeans is way less glitchy, and has better code analysis, and better integrations than eclipse. I cannot compare Netbeans to Intellij all that much because I have not worked in Intellij all that much, but I do know that Intellij has license restrictions for doing commercial stuff, and for doing javaee/j2ee stuff, which is why I do not us it much.

This project and Apollo are vastly different. My understanding is that Apollo is a huge implementation of a rsps that is based on reading the cache from what ever version of osrs you want, then hosting the server as that version. Default support includes rs317 and rs377. This causes a huge, hard to maintain code base, and a really 'heavy' server.

My understanding of what @lare96 is trying to do here is to build a light weight rs317 server that is not based on reading the cache. And to allow for a much more configurable environment that is easier to maintain.

I just think that when implementing integration of a scripting language into an environment like Java, it is nice to have a reference to see what others have done.

from luna.

@tlf30 Apollo should have allowed its users to implement a lot of that stuff instead of Apollo providing all of the implementation for it. If Apollo is extensible enough people should be able to copy and paste snippets and add new functionality to Apollo. Also Apollo should be imported into your project as a library reference like an api for you to build off of. This would hide the huge code base behind it that scares people away from using it in the first place. (A well designed api you shouldn't have to modify any of the core code but extend the application through plugins). (Which was one of Apollo's primary goals)

Regardless of the codebase I still think this project is doing the same thing as Apollo when it instead should be used only as a library.

from luna.

@nshusa The goal of this project is to fix those kind of problems. I do not think that a server should be a library. I think that Luna is being implemented correctly by providing a thin environment that functionality can be added to with plugins. If you are looking for a rsps library, others have been written, that is not the goal here.

I do not think that this is the place to discuss if Luna should be built, if that is the debate that you would like to make, I think that it could be argued that Apollo should also not have been built because other rsps have already been built in the past. That is not what I believe, but that seems to be your stand point.

But, Luna is being developed to try to fix the issues that have been present in monolithic rsps by using a light plugin based environment. No platform is going to conform to everyone's view of how an rsps should be implemented.

from luna.

@tlf30 If the whole point of plugins is so you don't have to modify and of the core code. Then users shouldn't have access to modify it. The only access they should have is to use it as an API as originally intended.

from luna.

If anyone can point me in the direction of a Lua implementation that has good Java interoperability and is still being maintained I'll gladly look into it but until then it doesn't make much sense to use it over Kotlin.

Despite being heavily inspired by (and learning a lot from) Apollo, @tlf30 is right in saying that the two projects are definitely not the same. The goal of Luna is to provide a lightweight, maintainable, and easy to use alternative 317 server for Runescape private server community. Even if (when?) the plugin system is changed over to Kotlin, not much will be different. Scala and Kotlin are actually very similar and the writing of Kotlin code for planning out the design of a potential new system has been pretty seamless.

I still think this project is doing the same thing as Apollo

How so? Sure there are some similarly designed things (event based plugin model, networking model, etc.) but that isn't because Luna is trying to be Apollo, it's written with the intent that it's the best and most efficient way of doing things. It wouldn't make sense to write code you know is subpar just because another project is doing something the same way. The vast majority of servers out there still have code (Cryption) and/or flawed design models (Client extends Player) in them virtually unchanged from like 2007 or whenever the first "real" servers were released.

@AshotN I'm not necessarily opposed to this actually... good Java interoperability, JSR-223 support, decent metaprogramming capabilities. @ryleykimmel Thoughts on JavaScript?

from luna.

@nshusa As much as I respect you, I must disagree on your opinion in mixing Apollo and Luna. Apollo is potentially the masterpiece of RSPS scene when they finally have a "stable release", but it'll scare away all the newbies. The documentation is far from being newbie friendly.

@lare96 You're awesome. Been working on Asteria 3.0 for few weeks now(just got back to RSPS scene after 5 years break), it's great.

Luna looks even better, but the reason why I registered up on github is that I felt like I had to drop an opinion here:

I converted Asteria plugin system straight away to Kotlin as it is the scripting language to use.

Btw, I'm hopping into Luna bandwagon. ^_^

from luna.

@Spirithill, hello!
I agree, I have been learning Kotlin over the last couple of weeks, and as far as a scripting language goes, it is nice.

Welcome to GitHub!

from luna.

Has a decision been made?

from luna.

#44 has been solved so this can be closed now.

from luna.