2 ms·

What's Kotlin going to do about that? Will they adopt their syntax or make it use the same API internally? This seems just like another feature of the JVM moth

by nikeee 3y ago

What's Kotlin going to do about that? Will they adopt their syntax or make it use the same API internally? This seems just like another feature of the JVM mother language that diverges from the implementation of other often-used JVM languages like Kotlin (thinking of nullability, type reification and structured concurrency and record types). It will be interesting to see what happens when Kotlin is continued to be pushed as the language for Android etc. while Java is being used by the majority of JVM devs.

djha-skin 3y ago
> often used It's certainly a very visible language and one often talked about, but if you look at Google trends for Java versus kotlin you're looking at about 10% of the adoption that Java has or less.
- usrusr 3y ago
  The languages don't have much surface area of features to search about. Far more google queries will be about API than about syntax. I wouldn't be surprised if the browser histories of kotlin developers, on average, contained far more occurrences of "google.+java" than of "google.+kotlin".
usrusr 3y ago
Inability to reasonably operate an API that has that StringTemplate type somewhere in a method signature would be a dramatic change of direction for kotlin. I'd be surprised if they didn't already have something in the pipeline to support \{it} strings on the syntax level, it's not like they pretend java-side progress didn't exist. The existing ${it} syntax is tied to string on the output, so it can't be repurposed. The java approach on the other hand keeps the output generic, so that it would also keep the door open for similar not-string compatibilities in off-JVM kotlin implementations. Whereas the ${it} the syntax kotlin already has couldn't do that. An approach like changing its semantics to define something that isn't a string when it exists at a StringTemplate.Processor call site would be terrible I think, php-grade terrible. At least as long as they don't also introduce that formatter-dot-template syntax which I'd consider a pointless redundancy with what kotlin already has: formatter{template} is already possible, expect for a way to write a template literal that resolves to something other than string. What I certainly wouldn't expect is anything reminiscent of "automatically imported into every Java source file".

by nikeee 3y ago

djha-skin 3y ago

> often used It's certainly a very visible language and one often talked about, but if you look at Google trends for Java versus kotlin you're looking at about 10% of the adoption that Java has or less.

usrusr 3y ago
The languages don't have much surface area of features to search about. Far more google queries will be about API than about syntax. I wouldn't be surprised if the browser histories of kotlin developers, on average, contained far more occurrences of "google.+java" than of "google.+kotlin".

usrusr 3y ago

Inability to reasonably operate an API that has that StringTemplate type somewhere in a method signature would be a dramatic change of direction for kotlin. I'd be surprised if they didn't already have something in the pipeline to support \{it} strings on the syntax level, it's not like they pretend java-side progress didn't exist. The existing ${it} syntax is tied to string on the output, so it can't be repurposed. The java approach on the other hand keeps the output generic, so that it would also keep the door open for similar not-string compatibilities in off-JVM kotlin implementations. Whereas the ${it} the syntax kotlin already has couldn't do that. An approach like changing its semantics to define something that isn't a string when it exists at a StringTemplate.Processor call site would be terrible I think, php-grade terrible. At least as long as they don't also introduce that formatter-dot-template syntax which I'd consider a pointless redundancy with what kotlin already has: formatter{template} is already possible, expect for a way to write a template literal that resolves to something other than string. What I certainly wouldn't expect is anything reminiscent of "automatically imported into every Java source file".