Live data from Hacker News

Kotlin/Native Tech Preview: Kotlin without a VM

blog.jetbrains.com

61–70 of 79 posts

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#61
post #57
post #53

Earlier quoted context omitted.

> Good luck getting an entire team onboard with a single IDE. Actually that is how many enterprise companies work. I usually get to use what the IT department from our customers has decided as IDE for a specific project. Anything else usually requires a change request with the necessary approvals at all levels, which means very few people ever bother to go through that pain, assuming that it will be approved in the e…

> assuming that it will be approved in the end, because "I don't like X" won't work as reason. How well does "else I quit, my code, my tools" works as a reason?

Good luck when you have a family and don't happen to live in places like Silicon Valley.

We are talking about enterprise here, there are plenty of people for that position, specially external consultants, no one would be stopping you from leaving.

In fact they might even help you taking your things out.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#62
post #61
post #57

Earlier quoted context omitted.

> assuming that it will be approved in the end, because "I don't like X" won't work as reason. How well does "else I quit, my code, my tools" works as a reason?

Good luck when you have a family and don't happen to live in places like Silicon Valley. We are talking about enterprise here, there are plenty of people for that position, specially external consultants, no one would be stopping you from leaving. In fact they might even help you taking your things out.

>We are talking about enterprise here, there are plenty of people for that position, specially external consultants, no one would be stopping you from leaving.

Well, if you're an external consultant, it's they that called you to get them out of some mess in the first place.

You didn't knock on their door to ask for work.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#63
post #62
post #61

Earlier quoted context omitted.

Good luck when you have a family and don't happen to live in places like Silicon Valley. We are talking about enterprise here, there are plenty of people for that position, specially external consultants, no one would be stopping you from leaving. In fact they might even help you taking your things out.

> We are talking about enterprise here, there are plenty of people for that position, specially external consultants, no one would be stopping you from leaving. Well, if you're an external consultant, it's they that called you to get them out of some mess in the first place. You didn't knock on their door to ask for work.

I always had this kind of experience even as internal dev.

The only time I had some kind of freedom, away from what IT says how things should be, was at a few startups.

Once those startups grew, the big boys from IT started to create a standard development environment.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#64
post #58
post #35

Earlier quoted context omitted.

Typescript is nice but its type system is not the strongest selling point. For example this compiles without warnings: const foo: Promise = Promise.resolve(null); const bar: Promise = foo; bar.then((value) => value.toString()); // runtime null error

That's because null is an acceptable value for a string object. Which is the same thing as in Java and plenty of other languages.

Not in Kotlin, though. You have to make it explicitly nullable if you want it to be null.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#65
post #59

Jetbrains is trying to chew to much, from Kotlin for the JVM, Kotling for javascript and Kotling native, soon or later, it will implode and it won't be nice.

> it will implode and it won't be nice. Hyperbolic much? At worst, it will fail to gain much traction.

We disagree, "it won't be nice" is not a hyperbolic statement.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#66
post #59

Earlier quoted context omitted.

> it will implode and it won't be nice. Hyperbolic much? At worst, it will fail to gain much traction.

We disagree, "it won't be nice" is not a hyperbolic statement.

The whole phrase "it will implode and it won't be nice" implies some kind of big mess or even the company collapsing or whatever...

Whereas it's just one of the things the company does, not even a profitable one, and at worst it will just fail to catch.

Sure, that "wont be nice either". But hardly the kind of "not nice" to be really concerned with...

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#67
post #23

Earlier quoted context omitted.

kotlin is backed by a tooling company. This is a very strong argument. The ones that are doing the best IDE for java (for a lot of people) are the ones that decided to create kotlin. Swift also has the tooling support of Apple, but I only read complains about tooling around Swift. Go and Rust are very niche compare to java or swift, while kotlin can replace java completely and now it is aiming for native backend proj…

I'm skeptical of the strategic advantage of being backed by a tooling company, because of the fact that tooling is often a preference that comes with holy wars attached. If Emacs sponsored a language, how many Vim users would jump ship? I know plenty of Java devs that actually prefer Eclipse (WTF?!?!?). Good luck getting an entire team onboard with a single IDE. Throw in the fact that their IDE software is open sourc…

>If Emacs sponsored a language

Emacs does sponsor a language (elisp), and it's most people's reason for using it.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#68
post #66

Earlier quoted context omitted.

We disagree, "it won't be nice" is not a hyperbolic statement.

The whole phrase "it will implode and it won't be nice" implies some kind of big mess or even the company collapsing or whatever... Whereas it's just one of the things the company does, not even a profitable one, and at worst it will just fail to catch. Sure, that "wont be nice either". But hardly the kind of "not nice" to be really concerned with...

That's your opinion, not mine.

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#69
post #43
post #23

Earlier quoted context omitted.

kotlin is backed by a tooling company. This is a very strong argument. The ones that are doing the best IDE for java (for a lot of people) are the ones that decided to create kotlin. Swift also has the tooling support of Apple, but I only read complains about tooling around Swift. Go and Rust are very niche compare to java or swift, while kotlin can replace java completely and now it is aiming for native backend proj…

> while kotlin can replace java completely I am not sure it can be be concluded from any data. They have come up with just a tech preview. Doing better job than Rust/Swift/Java or Go to have high perf on native platforms is going to be a huge effort. Just having a binding via LLVM is a small start. Hope they do better but for now it seems to me that hype around it is about 2-3 magnitudes higher than the actual amount…

kotlin can replace java completely because it compiles to bytecode (as java does). And then it is the bytecode what is compiled/interpreted in the JVM.

The tech preview is about kotlin compiling directly to machine code. They already said they haven't done any optimization into that code. I guess they use some intermediate language for the compiler to translate it to machine code. (note that all the compilers translate the original input file into this intermediate language before compiling it to the final code, so they can do a lot of optimization and checks in this code which are shared among all languages)

Re: Kotlin/Native Tech Preview: Kotlin without a VM

#70
post #23

Earlier quoted context omitted.

kotlin is backed by a tooling company. This is a very strong argument. The ones that are doing the best IDE for java (for a lot of people) are the ones that decided to create kotlin. Swift also has the tooling support of Apple, but I only read complains about tooling around Swift. Go and Rust are very niche compare to java or swift, while kotlin can replace java completely and now it is aiming for native backend proj…

I'm skeptical of the strategic advantage of being backed by a tooling company, because of the fact that tooling is often a preference that comes with holy wars attached. If Emacs sponsored a language, how many Vim users would jump ship? I know plenty of Java devs that actually prefer Eclipse (WTF?!?!?). Good luck getting an entire team onboard with a single IDE. Throw in the fact that their IDE software is open sourc…

backed by a tooling company means that the language was designed with tooling in mind and that there are going to be quality tools for the language. It doesn't mean there is only going to be one alternative.

Intellij Idea as IDE is a great choice. Android developers were forced to move from Eclipse to Idea and I haven't seen any resistance to avoid it. I have heard iOS developers complaning about tooling around swift. So, I think it is a strong point.

Post reply on HN