Apologies if this question isn’t really appropriate for this community, but Rust and Kotlin are my two favorite programming languages, and currently, I use both for different projects. However, I’m curious as to if people here think Kotlin still has a place when Rust exists? I’m specifically speaking architecturally: disregarding existing legacy code or support, do you think in the future, the Rust platform should replace the Kotlin platforms (JVM, LLVM Native, Android, Web) for everything Kotlin can do, or do you think Kotlin can do some things better than Rust?
I’m more experienced with java, but have used kotlin a bit too. The JVM languages are extremely versatile and capable of doing anything, but kotlin is probably the best of them in terms of syntax.
That said, after dealing with java’s garbage collector, I don’t think garbage-collected languages have a place in the future. Rust showed me that despite claims of garbage collected languages being easier, simple scoping and borrowing don’t really add any complication, and are better in terms of memory in the long run, and a better choice for pretty much every type of application.
But practically of course browsers aren’t going anywhere (so we’ll still need to learn javascript / typescript), and neither is android (so we’ll still need to learn a jvm language). I’ll still use kotlin, but only for android. Rust already has functioning web servers, UI toolkits, CLI toolkits, and everything you need for desktop or server apps.
Circular references and objects shared by multiple scopes (e.g. a lambda that uses the value of an UI element) are still quite annoying to work with and require a lot of boilerplate code because it requires wrapping it with a Rc and RefCell. None of this requires any additional effort when using a GC language like Kotlin or C#.
I have used Rust to write GTK applications but it wasn’t pretty and I ended up using GTKSharp in the end.
GTK has poor compatibility with Rust, due to it’s inheritance/OOP design. Iced-rs is a neat GUI library that works well with Rust’s features, you define view separately from the update loop. In the view you place widgets which send messages, and the update function listens to those and based on pattern matching the message updates the central struct when one is sent.
You can often achieve the same result in a different way if you’re not married to certain features, or in this case frameworks.
I have considered Iced but it does not integrate well with KDE Plasma, I might try it again in the future if the documentation has been improved.
True, but I also find that when you are dealing with circular reference and shared object scopes a bit of extra syntax and wrapping is the least of your problems.
In this case the garbage collector handles the memory for you, but for every other complication arising from these patterns you are still on your own. Keeping track of updates, locks, non-memory resource.
My team uses Clojure with ClojureScript on the frontend and I haven’t had to touch a line of Js in years. It’s simply a compile target from my perspective. Unlike stuff like typescript that builds on Js, ClojureScript has its own semantics that are actually sane.
I’ve also developed a strong preference for s-expression syntax nowadays. It eliminates a whole class of problems you see in Js. Stuff like JSX is completely unnecessary because you can just use regular data structures instead of having yet another transpiler as seen in React. The code is also a lot more regular than in most languages I’ve used. This means that it’s less ambiguous and you have less syntax quirks and edge cases to worry about.
Structuring code as a tree shows how pieces of logic relate to one another. This makes code more easily scannable. If one function is nested in another, you know its output will be used by it and if it’s not then it won’t. Effectively, your code is written as a diagram that you can inspect. These kinds of relations are not explicit in most languages.
The parens also allow for things like ParEdit where the code can be manipulated structurally by the editor. You can select an expression, reparent it, move it around etc. You’re no longer working with lines of code, but with little blocks of logic. Editing code becomes like playing with Lego, where you just snap pieces together to make things.
Using data structures to write code is what allows for a powerful macro system. You can take any piece of code and transform it like any other data structure using the same functions you’d apply to manipulating any other data. A good macro system means that you can express most things in user space instead of having to bake them into the language.
Most new ideas in Clojure are expressed via libraries, and when something new comes along people can just start using new libraries while existing projects keep on working. This greatly reduces mental overhead of working with the language. A concrete example of this is the core.async macro which allowed doing async in ClojureScript before it was even available in Js, and people didn’t have to wait for the language design committee to agree on adding this functionality in.
I would at least disagree on the browser side, look at dioxus-liveview. There is no need for js anymore 😉
I like Scala the best. It has a big learning curve and some very un-C-like symbols, but it writes a lot like Rust and as its name implies, it tries to be scalable, so it gives you tools to extend the language and write DSLs, without resorting to macros. So, yeah, really powerful, albeit you need to be a language enthusiast to fully appreciate it.
Among colleagues, we often joke that Kotlin is a quarter of the way from Java to Scala (and they must’ve taken Scala as an inspiration for a lot of language features).
Here’s some random example code: https://rosettacode.org/wiki/FizzBuzz#Scala
But there are so many…
The good news is that they’ll all clean themselves up 🥁
You can say this about any mainstream language. So it does not really mean much on its own. Technically speaking all mainstream languages are equally powerful (them all being Turing complete), so the only real question is how easy/hard they make particular things that you might want to do and things you should avoid doing. Personally I do find rust strikes this balance best over all the languages I have tried.