I think it’s pretty simple why you’d want to use Kotlin on the server; full stack Kotlin development: 1 language for both Android and Server(lowers time, costs, and you can share code).
And Kotlin multi-platform is making good progress, so potentially you can also build shared code for iOS and JavaScript. Again, it all comes down to time, cost, simplicity.
Lastly, I have to say, after using futures in Java/Scala, async/await in JS, Kotlin got it right with coroutines, channels and flows. I’m not exactly sure what the roadmap for concurrency looks like in the Java world(even with project loom, etc). While Java is moving fast(finally), I think it’s still weighed down by legacy stuff (nulls, mutable code, lack of expressions and more)
The question isn't really if Kotlin is better or not. It is whether or not people will end up using it. And it doesn't really look like it's going to be a winner in the market.
The simple fact that Kotlin is an officially supported language for Android app development will guarantee people will use it, in my opinion. It will almost definitely do better than Scala in the long run.
Agree completely with everything you said and your observations regarding job market. I’ve been doing Scala for several years and I also would not recommend it to anyone unless they have a deep desire to do pure FP(functional programming) on the JVM. The ecosystem/libraries are unnecessarily complex IMHO.
If you want FP-Lite, I recommend Kotlin, it’s very pragmatic, reasonably functional, and mid way between Java and Scala. I actually converted all my personal projects from Scala to Kotlin, including my framework https://github.com/slatekit/slatekit which took about a 4-6 weeks from the original code base.
What’s your stance on Dual licensing? I honestly have had mixed Opinions on this, but I finally settled on Dual licensing and/or BSL 1.1 as a nice compromise. I think open source developers create a lot of value, and should have the facility to be compensated and have their passion become their job. Plus this whole Re-Licensing trend toward SSPL/BSL/Dual is IMHO the natural evolution of open-source strategies.
Dual licensing (using the GPL and a separate proprietary license) is kind of a hack solution that takes advantage of the fact that business hate the GPL. It can introduce some problems (it effectively bars you from accepting contributions unless you use a CLA, which many contributors won't do). However, while community is an important part of Open Source, the most important part of Open Source is the lack of restrictions on how people use/modify/share the code, so while people can debate whether or not dual licensing is a good idea, that doesn't mean the GPL stops applying.
Any code that is GPL licensed is Open Source. It might be distasteful to some people to force contributors to sign a CLA, you might get some criticism from some segments of the community, but it's not problematic in a way that means it's fundamentally non-FOSS.
BSL on the other hand is not Open Source, but becomes Open Source at the point where the BSL license expires and is replaced by an Open version.
----
Personally, I might get some pushback on this, but I actually kind of like BSL more than dual licensing. Dual licensing relies on the fact that people find the GPL toxic. It feels much more to me like a temporary solution, and one that only works by kind of dragging the GPL through the mud. Even among people who don't hate the GPL, it encourages them to think of it as a tool to enforce 'fairness', rather than as a complicated way to use copyright to push towards a world where every user has the rights guaranteed in the GPL for every program they run.
TBH, I vaguely suspect that some of the movement towards SSPL is an evolution of people's attitude towards dual licensing, where they thought that the un-attractiveness of the GPL was the point of the GPL, and now feel like it's not living up to it's 'promise'. The fact that Amazon is able to use GPL code to provide commercial services is seen by those people as a bug, not a feature.
Many of the downsides and restrictions around community contributions with BSL are also present in dual licensing because of the implicit CLA requirements in dual licensed projects. So it's not clear to me that BSL is more harmful to community-built software than dual licensing, and given the above trend, it seems a bit more honest (for lack of a better word).
Because dual licensing doesn't really affect companies like Amazon, it kind of encourages people into these arm races where people say that the GPL has failed in its job because some companies don't hate it (again, the point of the GPL is not to be impossible for companies to use). BSL on the other hand is very straightforward, and because it's upfront about its goals, it's not subject to the same kinds of weird arm races and escalations. You release software as proprietary, we all recognize that it's proprietary and that you want compensation for it, and then at some point it becomes Open Source. That's a really simple model to think about and build around.
----
But all that being said, code that is licensed under the GPL is Open Source, period, regardless of what other licenses it is simultaneously offered under.
BSL licensed code before it expires is not Open Source or FOSS: it's proprietary code that later is Open Sourced once a certain amount of commercial value has been extracted from it.
I’m working on a Kotlin Framework, more like a collection of small, modular libraries that can be used for both server side and android. https://www.slatekit.com
My goal is a simpler, lighter, modern version of Spring framework (for Java) , but for Kotlin for both server and android. Also, looking into making it cloud provider agnostic.
I’m not too familiar with ruby but I’m curious why they didn’t just add optional types after the variable names. Such as in Kotlin, Scala, Swift like “var x:Int”? I thought this is how Python was adding types to its language. I could see this though fundamentally changing the philosophy/design of the language but I think dynamic languages are heading toward type safety anyway.
Probably because that would break existing Ruby code. Python added optional type annotations to the syntax but they are optional so it (mostly) does not affect old python code. I don't think they added a var keyword though.
These half typed approached are IMHO ultimately disappointing. It gets you some of the advantages of a type system but not the full robustness of a proper type system. Some languages do it better than others e.g. typescript is a bit more strongly typed than python 3. But ultimately you end up with a lot of compromises to allow legacy untyped code to still work. I think of this as a stepping stone for finding your way to a language with a proper type system. Once you get it and like it, you'll crave more and more is readily available in other languages.
I think the trend of type inference has sort of broken the "typing is too verbose for my taste" argument. I've converted a fair bit of javascript to typescript and you generally don't end up with more lines of code or less readable code (rather the opposite I would argue). And you do end up finding and fixing obvious type issues, glaring design flaws, etc. So, it clearly adds value at an arguably very reasonable cost. And that's before you consider IDE tooling and things like auto-complete, which add a lot of value in day to day use. Typescript in strict mode just feels like a better language than Javascript. I'm currently doing frontend development with Kotlin-js and the Fritz2 framework, which is awesome. It does feel like a step up from typescript + react but definitely not for the faint of heart if you are squeamish about early adopter stuff.
This new ruby typing system looks like an attempt to keep the language fresh and relevant in the same way. It looks like it is a necessary step at this point. I guess it's a valuable tool if you manage a large ruby code base none the less. Not one of my problems luckily. I haven't used it in years and at this point it's not an obvious choice for me for anything new.
The Scala language is great but the ecosystem sacrifices simplicity for pure FP. Scala has always suffered from complexity problems due to libraries. For example, using Http/JSON/Database libraries have always been a lot harder than they need to be due to a die hard approach to pure FP.
Scala 3 looks pretty good, but I just can NOT see myself using Scala again, after having worked with it for 4-5 years at work and on personal projects. I write mostly/reasonably FP code without using Cats/Category theory. I’ve recently moved all my code from Scala to Kotlin and I’m loving it, found the perfect balance with Kotlin.
Focus on no-code, low-code approaches and tools to building a product to validate a problem and your solution to it.
For example, use a “no code” approach first and simply use tools to design or build a simple Product, from concept to creation. Use cloud services like Invision to create a prototype, website builders/template to validate need/interest in an idea. These are all things that anyone can pick up reasonably well without coding.
Essentially, what I’m saying is focus on non-technical skills related to ideation, proof of concept, product validation, etc.
Accounts (I believe ) are similar to email addresses. So it's like having an account userX@gmail.com and trying to migrate that to userX@yahoo.com. Essentially the account is tied to the domain/server.
Modular Monoliths would be a healthy middle-ground between monoliths and micro-services.
My comment on the same topic of modular monoliths is here: https://news.ycombinator.com/item?id=21853902
Like many things in life, there are no absolutes. So rather than going to opposite ends of the spectrum, check out modular monoliths.
This approach is a nice balance (IMHO), since you start off with monolith but it is broken down into cleanly separated modules. Each module can potentially become its own micro-service if or when the time comes.
In terms of implementation, this can be easily done, for example we do it JVM/Kotlin where each microservice is its own project that produces a binary/jar. All the projects are part of a multi-project build. Lastly we have a common project for shared code, utils, types, enums, interfaces, etc and an application project that loads/sets up all the microservices from each project. Works great so far. And when you do have break up 1 project into its own service, the effort is fairly manageable.
And Kotlin multi-platform is making good progress, so potentially you can also build shared code for iOS and JavaScript. Again, it all comes down to time, cost, simplicity.
Lastly, I have to say, after using futures in Java/Scala, async/await in JS, Kotlin got it right with coroutines, channels and flows. I’m not exactly sure what the roadmap for concurrency looks like in the Java world(even with project loom, etc). While Java is moving fast(finally), I think it’s still weighed down by legacy stuff (nulls, mutable code, lack of expressions and more)