Live data from Hacker News

Kotlin 1.1 Released with JavaScript Support, Coroutines and more

blog.jetbrains.com

61–70 of 89 posts

Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more

#61

Earlier quoted context omitted.

I don't think of 'func' as a standard. Off the top of my head, you can see "defun", "fn", "def", "function", and on and on in various languages. I don't see much agreement across the board.

does anyone know of a place that compares syntax like this across languages? I've found myself often wondering if there is consensus for certain features or syntax.

Not exactly, but on rosettacode.org (http://rosettacode.org/wiki/Rosetta_Code) you can see tons of languages implementing the same toy programs, so they will often be using comparable language features in the process.

Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more

#62
post #54
post #18

Earlier quoted context omitted.

Perhaps the bigger issue here is fragmentation. Here you are, a young language with a lot of promise whose primary appeal is Java interop and whose target market is enterprise Java and already you're dividing your efforts to offer something which your target market will likely have zero interest in. Why not wait until you have real market share in the job market and only then worry about native? Kotlin is a very nich…

One of the niches where it's found a lot of popularity is Android development, which naturally leads developers to thinking about sharing code with the iOS version of their app. This is where Kotlin Native fits in, I think. Also (just dreaming here) if Kotlin Native were to use some kind of Swift-like reference counting rather than a traditional GC, it could be really nice for interfacing with COM on Windows, where y…

.NET and .NET Native work perfectly fine with COM, in spite of having a GC.

Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more

#63
post #41
post #29

Earlier quoted context omitted.

I suspect some combination of 1) It's hard for a new language to get traction. Lower odds that a new startup! They see so many ruby and python shops adding Go to their stack and want to compete in that space. Kotlin's biggest market seems to be android devs and competing with Go puts them in the datacenter. 2) IDEA's IDEs have a better value proposition to devs working with statically typed languages. Appealing to cu…

IDEA is pretty awesome with JavaScript too. The best IDE I have seen even for dynamic languages.

Actually Netbeans is also quite good for JS, it is a pity it gets so little love.

Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more

#64
post #30

Earlier quoted context omitted.

I completely agree. Kotlin is close to the ideal language for me because it is just Java done right. If they want to go native and can do it without impairing any of the JVM usability, I guess go for it. But I don't see the point behind it. I don't develop native apps so maybe I just don't know enough, but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages. I feel the s…

In my eyes going native is nice for the distribution of command line apps (if they are static binaries), but also for avoiding the startup time of the jvm. >[...] but it seems like Go and Rust have already satisfied the desire for modern natively compiled languages Not for me. Go's type system is too primitive, and Rust is maybe too low level if you don't need the advantages compared to languages with a GC. So a lang…

> but also for avoiding the startup time of the jvm.

Funny enough, all commercial JDKs do support AOT compilation to native code, and Oracle is slowly adding support for it as well.

Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more

#65
post #52

Earlier quoted context omitted.

It doesn't have compile-time type checking. When many people say functional code they really mean code that can be and is strictly type checked at compile time. Clojure is functional, but it's not what most people want when they say "functional".

Type-checking doesn't really have any bearing on weather a language is functional. Functional languages can be statically or dynamically typed.

It's one of the big differences between the lisp and ml types of functional languages I would say. Other than the parentheses that is of course :)

I've never been comfortable doing big projects - multiple files, more than a few hundred lines of code - in a dynamically typed language. It's the same reason were seeing the big uptake of typescript. Statically typed languages give us so many superpowers when we need to do refactoring or any changes at all to an existing codebase. Just changing a function name in a dynamically typed language can be hell. Rearranging the parameter order is even worse, cause you have such trouble finding all of the function uses and where you need to update. With statically typed languages you get editor support for simple stuff like this and it becomes automatic and a push of a button almost.

Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more

#66
post #65

Earlier quoted context omitted.

Type-checking doesn't really have any bearing on weather a language is functional. Functional languages can be statically or dynamically typed.

It's one of the big differences between the lisp and ml types of functional languages I would say. Other than the parentheses that is of course :) I've never been comfortable doing big projects - multiple files, more than a few hundred lines of code - in a dynamically typed language. It's the same reason were seeing the big uptake of typescript. Statically typed languages give us so many superpowers when we need to d…

Static typing is great. My point is that whether a language is statically or dynamically typed has no bearing on whether it is functional.

Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more

#67
post #62
post #54

Earlier quoted context omitted.

One of the niches where it's found a lot of popularity is Android development, which naturally leads developers to thinking about sharing code with the iOS version of their app. This is where Kotlin Native fits in, I think. Also (just dreaming here) if Kotlin Native were to use some kind of Swift-like reference counting rather than a traditional GC, it could be really nice for interfacing with COM on Windows, where y…

.NET and .NET Native work perfectly fine with COM, in spite of having a GC.

Only if you make sure to call Marshal.ReleaseComObject on all your objects, which requires you to hang on to explicit references to all of them, which is not very convenient for many COM APIs, e.g.

   Application.Database.Classes.Item("MyClass").Refresh()
where you would have to save all the intermediate objects in variables just so you can destroy them.

Python works much better with COM, in my experience, because of its more primitive but more predictable reference counting.

Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more

#69
post #67
post #62

Earlier quoted context omitted.

.NET and .NET Native work perfectly fine with COM, in spite of having a GC.

Only if you make sure to call Marshal.ReleaseComObject on all your objects, which requires you to hang on to explicit references to all of them, which is not very convenient for many COM APIs, e.g. Application.Database.Classes.Item("MyClass").Refresh() where you would have to save all the intermediate objects in variables just so you can destroy them. Python works much better with COM, in my experience, because of it…

I use .NET since pre-alpha days and never used it, RCW and CCW take care of that.

Unless you are talking about manually loading them.

Also, are you aware that UWP and .NET Native are built on COM?

Re: Kotlin 1.1 Released with JavaScript Support, Coroutines and more

#70

I wonder how Kotlin's JavaScript backend compars to Scala.js in Li Haoyi's list of fundamental reasons for betting on Scala.js: http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal... I have a few concerns about Kotlin's JS backend: How much can the complete JS bundle be optimized by an advanced whole-program optimizer like the Google Closure Compiler? Kotlin for JS has no reflection, and I think JetBrains sh…

> How much can the complete JS bundle be optimized by an advanced whole-program optimizer like the Google Closure Compiler?

JavaScript backend generates code understandable by static analyzers so it can be optimized. Anyway, we going to continue works in this area in near future.

> Kotlin for JS has no reflection, and I think JetBrains should not look into that as they said they are. But is there powerful compile-time code generation instead, e.g. through annotation processors?

Why do you think that reflection is a bad idea? Honestly, we don't have a final decision about it, it requires investigations and discussions. Note it's very important for us to have an ability to provide good tools (e.g IDE support) for features.

> Is there, or will there be, a healthy ecosystem of pure-Kotlin libraries that can be used with both the JVM and JS?

We will work on it.

Post reply on HN