Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Kotlin Foundation

kotlinlang.org

Post reply on HN
Print view View original

101–110 of 236 posts

Re: The Kotlin Foundation

#101

Post by yannoninator »

brabel wrote: post #92

This is great for Kotlin! But I need to make an observation about Google... They're also co-founders of the Rust Foundation[1], the major member of the select group of companies at the table at WHATWG[2] (which amongst other things decide on the future of web technologies, including JavaScript) due to their browser's market share, and a "visionary sponsor" of the Python Foundation[3]. They also develop a few programm…

Sure, I do welcome the language getting support however, I can't help but think it may be to do with them being fined by Oracle in that lawsuit costing Google billions.

But who knows, we are not allowed to ask these questions, just like why DRM was allowed into the web standard and W3C kept the votes secret.

I don't like the route we are heading.

Re: The Kotlin Foundation

#102

Post by Erlich_Bachman »

lokedhs wrote: post #99

I started using Java in the 90's and worked for Sun back in the day, so I have a reasonable amount of experience with it. Kotlin is a much better Java, and these days if I need to use the JVM, I will use Kotlin. However, I do feel that there is a huge missed opportunity in making something that is not just a better Java, but a better language. Kotlin has a lot of annoying limitations, almost all of which are there be…

It sounds like you are describing Groovy (which was mature even before Kotlin BTW).

Re: The Kotlin Foundation

#103

Post by shock-value »

BoorishBears wrote: post #71
ta988 wrote: post #62

Earlier quoted context omitted.

It depends on your needs I guess. Not all API can be handled by just a few classes. If your plan is to maake a microservice that expose a single value, yes spring boot is likely overkill. But when you have complex models with runtime configuration and profiles and so on... Maybe we need to specify what we are really talking about when we say API. For some it just means a partial implementation of REST.

Who said anything about a few classes? How does using Ktor preclude one from using anything you just described? Lol just using Koin alone would bring every thing you just described, with the added benefit of not delving into XML files. Really some people are just married to the mentality of "If it's not on the feature list, I guess you can't do it". I believe in using focused tools that excel at specific things. Ktor…

Spring (and particularly Spring Boot) requires no XML for configuration — everything can be done with annotations and plain Java (or Kotlin).

Re: The Kotlin Foundation

#104

Post by dehrmann »

lokedhs wrote: post #99

I started using Java in the 90's and worked for Sun back in the day, so I have a reasonable amount of experience with it. Kotlin is a much better Java, and these days if I need to use the JVM, I will use Kotlin. However, I do feel that there is a huge missed opportunity in making something that is not just a better Java, but a better language. Kotlin has a lot of annoying limitations, almost all of which are there be…

> Another thing I'd like to see changed is better support for DSL's

I keep waiting for a good solution for SQL in Java (or another language) that isn't a builder or a string with templating. I don't like what React does architecturally, but JSX shows how mixing languages in an elegant-ish way can be huge.

Re: The Kotlin Foundation

#105

Post by pjmlp »

ta988 wrote: post #47
pjmlp wrote: post #28

Earlier quoted context omitted.

Almost 10 years ago Pivotal was doing exactly the same with Groovy, Scala and Clojure, where are Spring Groovy/Scala/Clojure 10 years later?

I don't think any of these language efforts went anywhere near the support Kotlin now has in Spring. Doesn't mean it will not fail, but it is already further than any other..

Sure they were, Pivotal was screaming across all winds on Java conferences, just like they are doing nowadays with Kotlin.

They are just betting on a new horse after the old ones failed to win the races they were set off to.

I kept being downvoted when I talked about S4TF going nowhere and the news today prove many of us were right about it.

Similarly I will give about 5 years time for Kotlin fashion to die everywhere outside Android, this assuming that Fuchsia won't eventually become the new darling.

It is quite telling that Google's own business units like Ad Words and Google Pay rather go with Flutter, and write blog posts about it, instead of adopting KMM.

Jetpack Composer is a political answer to Flutter.

Re: The Kotlin Foundation

#106

Post by pjmlp »

balfirevic wrote: post #94
pjmlp wrote: post #88

Earlier quoted context omitted.

Not at all, because Kotlin wants to take it all, so they need to make the choice if they want to expose JVM features, or keep the language portable across all platforms that JetBrains wants to target with Kotlin. A good example is Kotlin/Native, by choosing a memory model incompatible with JVM code they failed, and were forced to go back into the drawing board for Kotlin/Native with a proper tracing GC.

If I were to use Kotlin server-side on JVM and didn't care about portability to other Kotlin platforms, could I not just use JVM green threads?

Depends on how Kotlin decides to expose them at the language level.

For example, you need special syntax to use SAM types and Kotlin cannot use all use cases from interfaces with default methods.

That is the thing with the Java Virtual Machine, the bytecodes and runtime are designed for Java, all guest languages have to pretend to be Java.

Just disassemble the amount of boilerplate generated by the Kolin compiler.

Re: The Kotlin Foundation

#107

Post by brabel »

BoorishBears wrote: post #76
eweise wrote: post #60

Earlier quoted context omitted.

My old team used Spring and Kotlin and it was a really productive combination. Spring isn't standing still. They have first class support for Kotlin and rewriting their framework to support the graalvm.

Spring is not standing still, and I'm not trying to claim it is, but there's still a fair bit of ceremony around a lot of features That's not necessarily a bad thing, but usually people who are giving the JVM a "second chance" via Kotlin were initially turned off by that ceremony - So when someone asks me "What should framework should I try for Kotlin web services?" my answer is usually Ktor. Because if they had to a…

Java developers are spoiled for choice.

There's everything, from the simplest possible https://sparkjava.com/, to the a little bit nicer https://javalin.io/ (which has a Kotlin wrapper), to the high performance and full framework https://vertx.io/ (which always had great multi-lingual support within the JVM), to the newer and GraalVM-friendly https://micronaut.io/ and https://quarkus.io/ ... for the Enterprise-only crowd, you still have the JEE successor, https://jakarta.ee/ and Oracle's own https://helidon.io/#/ (which likes to position itself as microservice focused, like Micronaut and Quarkus). Not to mention lower level libraries you can use, like https://www.eclipse.org/jetty/ and https://netty.io/.

Ktor has a tough fight to become dominant even in the Kotlin world.

Spring Boot is, still, definitely the most popular option, but it's still just one of very very many!

Re: The Kotlin Foundation

#108

Post by _old_dude_ »

lokedhs wrote: post #99

I started using Java in the 90's and worked for Sun back in the day, so I have a reasonable amount of experience with it. Kotlin is a much better Java, and these days if I need to use the JVM, I will use Kotlin. However, I do feel that there is a huge missed opportunity in making something that is not just a better Java, but a better language. Kotlin has a lot of annoying limitations, almost all of which are there be…

> JVM can't do dynamic dispatch on multiple arguments

It can since Java 7, the instruction invokedynamic was added for this kind of stuff.

The implementation for Pattern Matching (the project Amber) [1] will use the very same instruction.

[1] https://cr.openjdk.java.net/~briangoetz/amber/pattern-match-...

Re: The Kotlin Foundation

#109

Post by jpgvm »

Kotlin is my go-to general purpose language these days.

I still use and enjoy a few others, namely Rust but unless I need something specific I don't generally need to look past Kotlin.

You get the full JVM ecosystem, terse language that supports powerful abstractions and JVM runtime performance/features - i.e threads, debugging, prod tooling.

Re: The Kotlin Foundation

#110

Post by dehrmann »

randompwd wrote: post #96
maxpert wrote: post #89

I’ve used Kotlin on Server Side in production at a pretty significant scale and I think it’s the most underrated thing for people using JVM on servers. I recently had a podcast with one of Spring dev advocates (Josh Long) https://spring.io/blog/2021/02/11/a-bootiful-podcast-doordas... (shameless plug) and brought similar discussion to table. I will seriously urge folks to try it and hopefully foundation will bring mo…

Have only used Kotlin with Spring Boot for server side REST api and the resulting code was, a lot of the time, very un-digestable. Quite ugly to the eyes. Looking to give Kotlin another shot for non-Android API consumption and it seems like Ktor is a frontrunner. Looking at Spring WebClient to consume a JSON API makes my eyes hurt compared to other languages.

> Quite ugly to the eyes.

The companion object makes things like loggers ugly. Skipping parentheses for method calls that take lambdas can be nice, but all it does is safe a pair of parentheses, it makes for inconsistent syntax, and is pretty ugly when the method takes an arg. The lack of implicit upcasting is weird. The set/get sugar is nice, but it looks ugly when it's next to places where it doesn't work.

Post reply on HN