I read the Big Nerd Ranch guide to Kotlin and it talked in several places about Kotlin/Java interop, but never JS or native. I already had a solid background in Java, so I have gotten used to using Java classes in my Kotlin code. I am trying to write a Kotlin program which will be run on a site where most - if not all - functionality is written in JavaScript, and I am trying to understand how to write my code to make sure that it is interoperable. Will I be able to continue using Java classes in my Kotlin/JS code? What are the differences between writing Kotlin/JVM code and Kotlin/JS code? What should a (ex-) java programmer know when learning to interop with JS using Kotlin? If there are a few chapters on this in any good books written in the recent past, that would be helpful also.
As Steve already mentioned, you can't utilise java classes in Kotlin/JS.
Think of Kotlin/JS as Typescript.
It provides a different syntax to write code that ultimately compiles to JS.
Here are the notable differences of writing Kotlin/JS code vs Kotlin/JVM code
Kotlin/JS internally uses yarn for dependency management. This enables you to depend on any javascript module available on npmjs etc (see note below)
In addition to standard library, you can also leverage other kotlin-first frameworks such as kotlinx-serialization, ktor etc
Testing libraries will be JS specific. So instead of mockito / mockk / junit family, you'll need to get familiar with karma / mocha family.
There will be a difference in Coroutine capabilities - both in terms of the way one writes code and performance expectations.
I found reading about Kotlin Multiplatform helped clarify a lot about the capabilities of kotlin.
I know this was not specifically asked, but giving my 2cents to people considering Kotlin/JS (as of Sep'20)
Great if you're familiar with Kotlin and don't foresee too many third party dependencies apart from http i/o (ktor) , React ( kotlin-react) and basic html / css (covered by kotlin-styled).
Using JS modules as dependencies is not as straight forward as using JVM dependencies since there is no ready-made interop. One has to define javascript functions/classes in kotlin before using them (see here). So if you foresee leveraging a lot of existing javascript modules, it won't be an ideal way forward.
Great if you have a typical backend-frontend model where backend compiles to JVM and Frontend compiles to JS. You can leverage a common data model and http i/o framework across Backend and Frontend code (via Kotlin Multiplatform). I've found this to be a tremendous productivity boost!
Kotlin/JS compiles Kotlin code, including its own standard library, into Javascript code. At the end, that's all you have is Javascript. What you don't have is any connection to the Java Virtual Machine. Kotlin's standard library provides no magic to bridge Javascript code to the JVM so that it can utilize Java classes. So NO, you can't utilize Java classes in standard Kotlin/JS.
Related
React Native recently introduced experimental support for Turbo Modules, which allow developers to write code in C++ and call it directly from Javascript.
Is it possible to write a Turbo Module in Rust instead of C++? Generally Rust has good interoperability with C / C++ so I expect it is possible, but I couldn't find any examples of it after searching Google, StackOverflow, GitHub, etc.
If it is possible, are there any downsides to doing so? Do you losing typing information for instance?
You can use bridge between C++ and Rust https://cxx.rs/
Follow this thread to get an example of Rust integration https://twitter.com/_va_run/status/1493699146552803329
I want to bind a different programming language to the Godot game engine. Is there an instructional document or video on this topic? For example, how was this project done: godot-rust. If I can learn the basics, I can succeed in working in a different language. Thanks.
In this answer I show you the different approaches to add language support in Godot 3.x (the situation will be somewhat different with Godot 4.0 and GDExtension - which replaces GDNative and hopefully means less custom builds), and I mention some languages that are supported by each of these approaches. However, this is not an exhaustive list of the languages.
First of all, Godot has official build-in support for GDScript and Godot's VisualScript (and Godot's shading language and its visual counterpart if those counts for you).
There are a few ways to use C++:
You can use it to create GDNative scripts (which are basically a wrapper around native calls that allow you to use them as scripts in Godot).
Or you can create modules (which are static libraries you can add in a custom Godot build).
And since Godot source is in C++, you don't have to restrict yourself to making modules if you are making custom builds.
In web builds Godot can interface with JavaScript via the JavaScript class. However, this approach does not allow you to add JavaScript scripts to Nodes, and so on.
Then there are languages that can only be added in custom builds of Godot, which is currently the official support for C#.
There are other non-official custom builds that offer language binding for languages such as Lua, Kotlin, TypeScript and JavaScript (this time allowing you to make scripts).
If you need to add a runtime, you would probably do this.
Some language take advantage of the fact that Godot's has official Mono support in order to support C#. This way you can, for example, use F# and Clojure.
They start by adding a C# project and then modify it so it uses another language. This is viable if your language already compiles to .NET.
Some other languages can be added as plugins that implement the PluginScript class via GDNative. This is the case of Python and Lua (again) which you can get from the asset library.
This is the most user friendly way to add language support to Godot, but it is limited to what you can do with PluginScript.
Addendum: Gil Barbosa Reis, author of the aforementioned Lua bindings, has an article series about its implementation stuffed away in the repository (in English and Portugueses): godot-lua-pluginscript/extras/articles/. It is probably the most comprehensive tutorial to date.
Other languages are added by means of taking advantage of GDNative (They basically mimic what you would do with C++). This is the case of Nim, Rust, D, Haskell, Go, Swift…
So that's how godot-rust works: make native libraries using rust and the godot-rust create and add them as if they were made in C++. For any language for which there are the means to make native libraries already, this is a good option.
Finally there is another way to add support for a language: a transpiler from that language to GDScript, which can be automated with an addon that might also be written in GDScript. This is the case of Lisp.
This last approach is mostly used for domain specific languages.
The official docs here provide your answer:
Godot officially supports GDScript, C/C++, C#.
Some 3rd party languages that can be used are: Rust, D, Python, Nim, and Go.
While reading Kotlin to JavaScript tutorial, I'm just wondered what's the benefits of writing JavaScript code using Kotlin?
Beside,
there are already great tools for Javascript developing, like package-manager, Webpack, Gulp...
The benefit is similar to using javascript for server and client. A common language with shared code.
Kotlin can be used for server and client, and aspects of code can be shared. Can use JVM for back-end, and JS tools/frameworks for front-end.
I'm not necessarily recommending this approach, but can see value in it. If you already know Kotlin, it means you don't have to learn JS.
Kotlin is also officially supported for creating Android apps, and Jetbrains are in the process of allowing for development of iOS apps in Kotlin.
So, can use one language across all platforms.
Is it possible to use js generated from Kotlin sources in JVM to manipulate java objects and its own js objects?
Kinda create dynamic environment for development in distributed environment.
So new versions of classes can be dynamically loaded/modified on running remote servers while development. And then after it's done release versions to be compiled statically for max performance.
How hard would it be to implement?
The current implementation of Kotlin does not have any support for invoking Java methods from JS-generated code. This could in theory be accomplished using Nashorn, but we (the Kotlin team) do not currently have any plans to work on that. If you're interested, you're welcome to contribute, but this would be a fairly long and difficult project.
This answer to a question about C++ unit test frameworks suggests a possibility that had not occurred to me before: using C++/CLI and NUnit to create unit tests for native C++ code.
We use NUnit for our C# tests, so the possibility of using it for C++ as well seems enticing.
I've never used managed C++, so my concern is are there any practical limitations to this approach? Are many of you doing this? If so, what was your experience like?
We do this all of the time. We have many assemblies written with C++/CLI and use C# and NUnit to test them. Actually, since our goal is to provide assemblies that work well with C#, doing this makes sure that we have accomplished that.
You can also write NUnit tests in C++/CLI and call unmanaged C++. Probably the best way is the keep your pure unmanaged C++ in a lib, and then make a test assembly that uses NUnit and links to the lib.
It works very well and gives you the benefit of having parameterised tests as well as a common test runner and framework if you're in a mixed environment.
There are two downsides, neither of which is serious for most cases:
If you're being really picky, the tests are no longer being run in a purely native environment so there's an outside possibility that something may work under test but fail at runtime. I think you'd have to be doing something fairly exotic for this to matter.
You rely on your C++ code being able to be included into a C++/CLI program. Sometimes this can have clashes with headers and it forces your code to build OK with UNICODE. In general, this is a good thing as it uncovers crufty bits of code (like inconsistent use of Ansi variants of Win32 calls). Bear in mind that it's only the headers being included so what it may well show is that you are exposing headers at too high a level - some of your includes should probably be within your cpp implementation files.
My experience is that it is not possible to use NUnit to test C++ native code through C++/CLI because you will have trouble loading and using native code.
I have tried using nunit to load a basic c++/cli test dll linked against "just thread" which is an implementation of the c++ standard thread library.
Test dlls won't even load with the latest version of NUnit (2.6.2).
So definitely not the way to go!
I never used one, but isn't there a port? Perhaps http://cunit.sourceforge.net/documentation.html would work for you.
The biggest concern is the learning curve of the C++/CLI language (formerly Managed C++) itself, if the tests need to be understood or maintained by non-C++ developers.
It takes a minimum of 1-2 years of C++ OOP experience in order to be able to make contributions into a C++CLI/NUnit test project and to solve the various issues that arise between the managed-native code interfaces. (By contribution, I mean being able to work standalone and able to make mock objects, implement and consume native interfaces in C++/CLI, etc. to meet all testing needs.)
Some people may just never grasp C++/CLI good enough to be able to contribute.
For certain types of native software libraries with very demanding test needs, C++/CLI/NUnit is the only combination that will meet all of the unit testing needs while keeping the test code agile and able to respond to changes. I recommend the book xUnit Test Patterns: Refactoring Test Code to go along this direction.