-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why not Kotlin? #76
Comments
Why not X questions are usually quite fruitless for a few reasons.
By all means, feel free to tell us what you like or dislike in Kotlin, we have a wish-list label for these sort of issues. |
One of the things I like best about it is that it doesn't just target the JVM. But I'm not about to file a ticket to suggest targeting JVM, JS and native as well as .NET because it would be a large undertaking. The original post I saw on Reddit was worded in a way that made it sound a lot like Kotlin only improves on Java, or only targets the JVM, which is obviously not the case. It's its own language with native support for multiple targets. |
Targeting JVM is not completly out of the table, but right now the focus is to get working version of the language targeting .NET. |
Indeed, but it's not an insane idea at all I believe. It would definitely be a very-very long-term goal, but I do think JVM is similar enough to at least try to target it and JS would be really nice for the web ecosystem. |
If we could target JS it would make for very useable scenario, where you would have backend in Fresh as well as frontend. |
I think that language should take most from platform it's targeting. Dotnet was built on mistakes of JVM and supports value types, pointers, keeps generic information at runtime. It doesn't make sense to limit language, so it can run on other platforms.
To my knowledge it's possible to build ordinary .net assembly and run it in browser with Web Assembly, which Blazor does. Compilation into JS doesn't make sense either |
I know this whole thing is well dead, but just to clear up multiple misunderstandings in the above comment by @jl0pd:
Also it's worth noting that Kotlin gets additional features depending on what it's targeting. For example in Kotlin/JS we get to use dynamic types. So any talk about "lowest common denominator" clearly doesn't apply for a programming language. Kotlin has shown how you can have a single language with features which are target-specific. Some day, someone will make a .NET compiler for it, but I'm just not sure who will do it. |
Used Kotlin, and would only use it when the only alternative is Java. |
Depends on your viewpoint. If I were sitting on .NET and only intending to target .NET, then I'd probably go with F#. If I were intending to target multiple platforms and had a language which could do all of them, I would use it. But right now, there isn't one, unless you count some weird mix of Java or Kotlin with IKVM.NET and some toolchain to get native. |
By platform here you mean .NET or Java ? |
It absolutely does make sense. There's extremely important implementation differences between the JVM and the CLR that had large influences on both Java/Kotlin and C#, particularly in the aspect of generics. The erasure of generics means that the way variance works in Java/Kotlin is not implementable in the CLR without reimplementing all of generics via erasure, and similarly the way generics work in C# is not implementable on the JVM.
Kinda. Kotlin has inlineable functions, which can have reified generics, and it has value classes (I can't remember the exact name of the feature, but it's ahead of Valhalla), which it essentially erases to the underlying components. C#'s type system allows for far more expressiveness around these things than the JVM can express (today), and the design of these features in Kotlin reflects that.
This is just foolish, sorry. Even modern safe languages like Rust acknowledge that pointers are an important scenario that need to be usable.
This was not a mistake. |
For an example that's out there today, consider something like Lucene, where it had to be implemented three separate times for three different targets. If a language existed which targeted all three places, it could have been implemented once.
Sounds like a strawman argument to me. If I were writing a Kotlin compiler targeting .NET, why would I limit myself to supporting what the JVM supports? I'd have it support reified generics everywhere, not even just on inline functions, and it would compile to the same thing the equivalent C# would compile to.
I've used multiple languages without pointers by this point, and never found anything I couldn't implement that I wanted to implement. Sure, in C and C++ I was using them, but I haven't missed them in other languages which don't have them. Pointers are only an "important scenario" for people who can't imagine how to refactor their code to avoid needing them. And pointers are a mistake. Even if in your universe they aren't. |
This is the wrong way to think about this. You're not limiting yourself to what the JVM supports. You're implementing Kotlin, as specified. And it's not a limitation: erasure-based generics are not all bad, no good. Kotlin's type and star projections can't be implemented on the CLR with its reified generics.
Then you have clearly never done any type of native interop (remember Java actually has a pointer type in the standard library so JNI can actually work), IoT projects, driver code, or anything else in that general field. Pointers represent the way memory actually works, and sometimes they are truly the best representation of the reality. Yes, I recommend that people avoid them wherever possible and use safer abstractions, such as Span or ref fields. But sometimes abstractions aren't general enough to cover a use case. Pointers, appropriately cordoned off behind unsafe warnings, and supplemented by safer abstractions to cover the 90+% case, are absolutely not a mistake. They are a tool, like every other tool in the toolbox. |
IMO "Porting" manually is a terrible idea and should never be done.
Instead of porting the logic, other solutions are possible.
Like C ? Instead of having the library rewritten in multiple language, you could simply bindings calling the native dll.
A single language that behave differently in majors ways depending of what platform you are targeting, is not a single language. Multitargeting in C# is already a pain, while it's targeting the same language, the same standard library, but with differents versions. |
I've done all of those. For IoT and driver code I've done it in C. I wouldn't try to use something like Java or C# for that. And I've done native interop in Kotlin and Java, but in both cases, I have used a pointer type. Not pointers as a language feature. |
Well, at least for C#, these are absolutely supported scenarios. IoT in particular is a space that .NET has invested and will continue to invest in.
It's not a good idea to regard these as separate concepts. Your types are part of the language, and are features of that language. I would hope that, even if you encode language support for pointers as types like any other, your type system has a mechanism for indicating that usage of these types must be done in some sort of unsafe context (something iirc Kotlin and Java do not have), as users should be directed towards safe abstractions whenever possible. Your arguments came across (at least to me) very differently than you've indicated in your last comment. Encoding pointers as a specific type of type ( |
Well, in the case of Java at least, it comes with the JNA library. So if you don't use that library, it's not part of the language, but then if you use that library, it's now part of the language? So the language includes whatever libraries you happen to use? That's certainly one way to look at the world, but I usually separate the concepts, and usually even separate the standard library from the language. |
No, that is not what I'm saying. There's a fuzzy line here, but I would absolutely say that "what comes in the box when you run the official installer" is part of the language.
Absolutely not. This is part of the experience of using a language.
|
There have been people posting on Kotlin forum from time to time asking why Kotlin itself doesn't also target .NET.
It currently targets JVM, JS and native. .NET would be a fine addition to the collection.
The text was updated successfully, but these errors were encountered: