Kotlin/JS is also a really interesting concept and I'd love to see it get more momentum. Unfortunately, I'm thinking that Kotlin is just too strongly tied to the JVM for it to really get much more use than in multiplatform projects (sharing same data models between front and back end).
Kotlin/Native is an LLVM backend for the Kotlin compiler, runtime
implementation, and native code generation facility using the LLVM toolchain.
Kotlin/Native is primarily designed to allow compilation for platforms where
virtual machines are not desirable or possible (such as iOS or embedded targets)
or where a developer is willing to produce a reasonably-sized self-contained program
without the need to ship an additional execution runtime.
Prerequisites:
install JDK for your platform, instead of JRE. The build requires tools.jar, which is not included in JRE;
on macOS install Xcode 9.3
on Fedora 26+ yum install ncurses-compat-libs may be needed
To compile from sources use following steps:
First, download dependencies:
./gradlew dependencies:update
Then, build the compiler and libraries:
./gradlew bundle
The build can take about an hour on a Macbook Pro
To run a shorter build with only the host compiler and libraries, run:
I'm expecting this to catch on more than Kotlin/JS because of Kotlin's relationship with Android. More likely for people to want to share Kotlin code between Android/iOS than backend/frontend. In my (quite limited) experience, Java-based backends seem to be used more for microservices and APIs, as opposed to full stacks like with Rails or PHP backends, leaving less incentive to introduce Kotlin into a JS codebase.
That being said, I think the popularity of Typescript and Flow show that web developers do want static typing, I'm just not sure how likely it will be for Kotlin to become a popular option.
I feel like any attempt to move Kotlin away from the JVM is a step towards compiling to all sorts of places because the big hiccup when moving off is that you can no longer dip into the Java ecosystem to fill the gaps. It forces certain problems to be solved which could than make the next thing easier.
"That being said, I think the popularity of Typescript and Flow show that web developers do want static typing, I'm just not sure how likely it will be for Kotlin to become a popular option."
Well... Some do. And a lot of web developers really like JS and don't feel like it being a static language adds any real value. I think both sides of the argument make sense. I definitely understand peoples reasons for loving typescript. I work on a huge app built with angular 2+. And I honestly hate typescript. I have yet to see "static typing" solve any problems that arise from bad coding practices that slip through the cracks when you have 200+ devs working on the same app. (which is the promise of typescript). In my real world working experience, typescript is just an extra-bloated superset of javascript that doesn't actually fix any problems. I think the real strength of typescript is it makes people who are very familiar with static languages happier with JS...
I don't like WASM as the end all of the next step in Web performance because it ruins a big part of the openness of the Web. If WASM really takes off, then gone are the days of being able to view-source on a Web page and see how it works. Even a text based bytecode would be better than the current format. Though my real ideal situation is just for JavaScript to become statically typed.
I really did like WebAssembly in concept. Something I've been reading about recently which I will eventually do a full post on is a project by Oracle called GraalVM. In it's core, is basically a framework to create programming languages in such a way that they are interoperable with all other languages made with the framework as well as being immediately compatible to be run on the JVM. Making a JVM is really hard so I really loved this idea. ((the refernce Ruby implementation they made is ~400x faster than real Ruby iirc))
This is what I imagined WebAssembly to be when I first heard about it. A base open format that multiple languages could target to gain the speed benefits that JS engines have already built. Kinda like .NET
It's a good point, but I'd assert that we lost that a while ago. Minification, obfuscation, optimization, etc, mean JS is often as unaccessable as WASM. On the bright side, the WASM tooling is looking pretty good and could help devs make sense of it. Of course, if you're at that point, you're probably past "view source" to make sense of things. I suspect that the way this learning will manifest, going forward, is via OSS (meaning access to the uncompiled source). But it is definitely a good point, and it's the same sentiment that causes me ambivalence around HTTP/2's TLS everywhere (I know there are ways to get around that, too, but they're cumbersome and require you to really know what's going on).
Anyway, I'm a fan of it, b/c I think the browser should be treated like a platform (due to watching a lot of Alan Kay, esp The Computer Revolution Hasn't Happened Yet), so my POV is that it should have always been a bytecode interpreter, and WASM corrects that problem.
I'd love to read your post on GrallVM, btw! I read their paper on Truffle, a while back and what I understood of it sounded astoundingly cool! Also, they've been really kicking ass on the optcarrot benchmark (I don't think it was 400x, but it was impressive enough that I stopped and took note).
Sasa is a highly driven full stack software developer with background in finance and accounting. A relentless problem solver who is passionate about finding elegant solutions to problems at hand.
Elm could be something, looks like they're doing their own thing, unlike Dart which tried to improve upon Javascript which in my opinion is the reason it hadn't caught up, but I'm not sure about WASM, aren't we kinda making a full circle and going back to nineties with C/C++ for web?
I doubt C/C++ would catch on for the web necessarily, but maybe Rust. It seems like that's the high-perf language that has the most momentum due to novelty/excitement and stewardship from Mozilla.
I agree. JS isn't going anywhere but there is always going to be people who want something very different. I think Elm qualifies as quite different from JS.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think competition is coming. Elm and languages that could target WebAssembly should bring some variety to front end web development.
Kotlin/JS is also a really interesting concept and I'd love to see it get more momentum. Unfortunately, I'm thinking that Kotlin is just too strongly tied to the JVM for it to really get much more use than in multiplatform projects (sharing same data models between front and back end).
Thoughts on this?
Kotlin/Native infrastructure
Kotlin/Native
Kotlin/Native is an LLVM backend for the Kotlin compiler, runtime implementation, and native code generation facility using the LLVM toolchain.
Kotlin/Native is primarily designed to allow compilation for platforms where virtual machines are not desirable or possible (such as iOS or embedded targets) or where a developer is willing to produce a reasonably-sized self-contained program without the need to ship an additional execution runtime.
Prerequisites:
tools.jar, which is not included in JRE;yum install ncurses-compat-libsmay be neededTo compile from sources use following steps:
First, download dependencies:
Then, build the compiler and libraries:
The build can take about an hour on a Macbook Pro To run a shorter build with only the host compiler and libraries, run:
To include Kotlin compiler…
I'm expecting this to catch on more than Kotlin/JS because of Kotlin's relationship with Android. More likely for people to want to share Kotlin code between Android/iOS than backend/frontend. In my (quite limited) experience, Java-based backends seem to be used more for microservices and APIs, as opposed to full stacks like with Rails or PHP backends, leaving less incentive to introduce Kotlin into a JS codebase.
That being said, I think the popularity of Typescript and Flow show that web developers do want static typing, I'm just not sure how likely it will be for Kotlin to become a popular option.
I feel like any attempt to move Kotlin away from the JVM is a step towards compiling to all sorts of places because the big hiccup when moving off is that you can no longer dip into the Java ecosystem to fill the gaps. It forces certain problems to be solved which could than make the next thing easier.
"That being said, I think the popularity of Typescript and Flow show that web developers do want static typing, I'm just not sure how likely it will be for Kotlin to become a popular option."
Well... Some do. And a lot of web developers really like JS and don't feel like it being a static language adds any real value. I think both sides of the argument make sense. I definitely understand peoples reasons for loving typescript. I work on a huge app built with angular 2+. And I honestly hate typescript. I have yet to see "static typing" solve any problems that arise from bad coding practices that slip through the cracks when you have 200+ devs working on the same app. (which is the promise of typescript). In my real world working experience, typescript is just an extra-bloated superset of javascript that doesn't actually fix any problems. I think the real strength of typescript is it makes people who are very familiar with static languages happier with JS...
I don't like WASM as the end all of the next step in Web performance because it ruins a big part of the openness of the Web. If WASM really takes off, then gone are the days of being able to view-source on a Web page and see how it works. Even a text based bytecode would be better than the current format. Though my real ideal situation is just for JavaScript to become statically typed.
I really did like WebAssembly in concept. Something I've been reading about recently which I will eventually do a full post on is a project by Oracle called GraalVM. In it's core, is basically a framework to create programming languages in such a way that they are interoperable with all other languages made with the framework as well as being immediately compatible to be run on the JVM. Making a JVM is really hard so I really loved this idea. ((the refernce Ruby implementation they made is ~400x faster than real Ruby iirc))
This is what I imagined WebAssembly to be when I first heard about it. A base open format that multiple languages could target to gain the speed benefits that JS engines have already built. Kinda like .NET
It's a good point, but I'd assert that we lost that a while ago. Minification, obfuscation, optimization, etc, mean JS is often as unaccessable as WASM. On the bright side, the WASM tooling is looking pretty good and could help devs make sense of it. Of course, if you're at that point, you're probably past "view source" to make sense of things. I suspect that the way this learning will manifest, going forward, is via OSS (meaning access to the uncompiled source). But it is definitely a good point, and it's the same sentiment that causes me ambivalence around HTTP/2's TLS everywhere (I know there are ways to get around that, too, but they're cumbersome and require you to really know what's going on).
Anyway, I'm a fan of it, b/c I think the browser should be treated like a platform (due to watching a lot of Alan Kay, esp The Computer Revolution Hasn't Happened Yet), so my POV is that it should have always been a bytecode interpreter, and WASM corrects that problem.
I'd love to read your post on GrallVM, btw! I read their paper on Truffle, a while back and what I understood of it sounded astoundingly cool! Also, they've been really kicking ass on the optcarrot benchmark (I don't think it was 400x, but it was impressive enough that I stopped and took note).
Elm could be something, looks like they're doing their own thing, unlike Dart which tried to improve upon Javascript which in my opinion is the reason it hadn't caught up, but I'm not sure about WASM, aren't we kinda making a full circle and going back to nineties with C/C++ for web?
I doubt C/C++ would catch on for the web necessarily, but maybe Rust. It seems like that's the high-perf language that has the most momentum due to novelty/excitement and stewardship from Mozilla.
But JavaScript engines are improved so much always bet on JavaScript .
I agree. JS isn't going anywhere but there is always going to be people who want something very different. I think Elm qualifies as quite different from JS.