131–140 of 254 posts
Earlier quoted context omitted.
I disagree. Having a common language in many places has led to huge improvements over the board in the JS ecosystem, it's become the "C" of the modern era, and you can build a lot of stuff on the foundations that others have laid. I still hate JS though.
Which is anything but positive, as it also shares C's style of unsafety due to its semantics.
Earlier quoted context omitted.
The large memory footprint of the JVM is memory for classes, profiles, things like that. Those are used to create optimised code and to recover when optimisations were too optimistic. When your program is optimised and running in steady state, this memory isn't actively used and so doesn't contend with your application memory and so has no impact on cache efficiency.
This sounds like a plausible explanation, but is this verified/verifiable? Are there memory profilers that can show me the relative sizes of the young/old/permanent generation segments of the GC? I'm always blown away at the memory usage of JVM apps. Part of it is the fact that java has encouraged insanity-inducing inheritance hierarchies...but also it is incredibly hard to do dead code optimization on for such a sta…
Earlier quoted context omitted.
The JVM itself doesn't add a huge memory footprint. I remember Charles Nutter of JRuby fame calling it the "20-30 MB memory tax" (see http://blog.headius.com/2008/11/noise-cancelling.html ). A lot of the extra memory usage of Java apps comes from sloppy programming and from depending on lots of heavyweight libraries and frameworks.
If you include idiomatic Java programing as part of sloppy programming I also agree with that. https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/me...
I do like the slide though showing that people tend to assemble abstractions together and completely lose sight of the performance costs of what they are doing. There's also the fallacy commonly held by many that because someone took the time to write a framework or library, they must have also taken the time to ensure it's optimized well.
Earlier quoted context omitted.
Which is anything but positive, as it also shares C's style of unsafety due to its semantics.
Javascript performs unchecked memory accesses? Or are you alluding to their both being weakly typed?
The amount of page differences between "JavaScript the good parts" and the actual language reference speaks for itself.
Earlier quoted context omitted.
When you are writing that full-blown HTTP REST server with DB access you would probably be served better on the JVM. Scala native is just as garbage collected as Scala JVM and garbage collection is where the JVM shines brightly. In my eyes, the main value proposition of Scala native will be "you don't have to learn a new language if you need to write an echo or a grep", with "you don't need to learn a new language if…
A major value proposition is also "I want to run my code with predictable latency". This opens Scala to embedded and realtime development. The LLVM AOT optimizations are also likely to be a lot stronger than JVM JIT optimizations - granted it's good to compile on the exact target architecture. Also granted that sometimes dynamic optimization helps a lot. Nice handle BTW. lol
Earlier quoted context omitted.
When you are writing that full-blown HTTP REST server with DB access you would probably be served better on the JVM. Scala native is just as garbage collected as Scala JVM and garbage collection is where the JVM shines brightly. In my eyes, the main value proposition of Scala native will be "you don't have to learn a new language if you need to write an echo or a grep", with "you don't need to learn a new language if…
A major value proposition is also "I want to run my code with predictable latency". This opens Scala to embedded and realtime development. The LLVM AOT optimizations are also likely to be a lot stronger than JVM JIT optimizations - granted it's good to compile on the exact target architecture. Also granted that sometimes dynamic optimization helps a lot. Nice handle BTW. lol
For both you need:
* An understanding of what kind of code will be generated
* Predictable, and hopefully verified, GC
* Reasonable binary sizes
* Very good tree shaking
If Scala Native could deliver on small binary sizes, "0 runtime" like Rust, and a way embed inline assembly like instructions then it would be a winner.
This will be huge for getting Scala running on AWS Lambda. The cold-start times for JVM apps is just ridiculous and makes Lambda/API gateway essentially unusable for anything written on the JVM.
Earlier quoted context omitted.
Javascript performs unchecked memory accesses? Or are you alluding to their both being weakly typed?
No,but implicit conversions, including from operators into numeric values isn't much better. The amount of page differences between "JavaScript the good parts" and the actual language reference speaks for itself.
I would love for there to be a similarly thorough project with Clojure. It really bothers me there's no good native compiler. Apart from anything else, it means that Clojure lives and dies by the languages it compiles to, and while Java is used everywhere still, it probably isn't the thing the kids are learning these days. Besides, without going into any further rational arguments for why using the JVM (or another VM…
Yep, they learn Ruby and then they need to go JRuby when performance becomes relevant. :)