Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala Native v0.1

scala-lang.org

Post reply on HN
Print view View original

221–230 of 254 posts

Re: Scala Native v0.1

#221

Post by lmm »

bluejekyll wrote: post #186
lmm wrote: post #168

Earlier quoted context omitted.

Does it really need to be a binary? Build executable jars (use the maven shade plugin), run them with java -jar foo.jar, that's about as simple as it gets.

I have never successfully deployed a Java application with defaults on the GC, etc. I'd love it if I could compile those options into a binary.

Yeah you can't do that, and I don't necessarily agree with that design decision. But for the sake of the comparison it's worth saying that these "simple" compile-to-binary languages simply don't let you set those parameters at all - it's ridiculous to argue that Go (say) is better than Java because something that's impossible in Go requires fiddling with parameters in Java.

Re: Scala Native v0.1

#222

Post by lmm »

lacampbell wrote: post #175

Scala is a language I desperately wanted to like - high level, statically typed pure OO language. But in practice I found it almost unusable. The type signatures were unreadable and I distinctly recall writing a 100 line or so program where the type declarations crashed the compiler. And the tools themselves were huge memory hogs - sbt was a particularly bad offender (though otherwise quite pleasant). I also did not…

> The type signatures were unreadable

I think a lot of people see a dense 1-liner and panic when they can't read it as fast as a line of another language, when actually the same operation would be 5 or 10 lines in that other language. It's ok to take a bit longer to read it; in my experience if you take a deep breath and read slowly, breaking it down into pieces, it's all very simple - the combination may be complex, but everything is very modular and compositional so you can understand each piece in isolation and then put them together to make the bigger picture.

> I distinctly recall writing a 100 line or so program where the type declarations crashed the compiler.

Do you still have it? Those are pretty rare (and almost always a type error rather than a correct type, though I appreciate that doesn't help you much at the time) and I'd be interested in minimizing it into an actual bug report.

> And the tools themselves were huge memory hogs

Yeah that does happen. I avoid SBT, but eclipse isn't exactly light. They're putting a lot more focus on performance in recent releases which will hopefully address this up to a point.

> I also did not get on well with the community, which seemed to have a lot of people with the attitude - "they won't let me use haskell at work so I'll make do with this shit". They didn't seem to understand or be interested in OO at all, and were very fanatical about driving application logic with types, purity, and the like.

The community is pretty awful. But I found that as people got more experienced, myself included, they tend more towards the pure, strongly typed side of things and make less and less use of OO. I understand OO but am no longer interested in it, and I think most experienced Scala folk feel the same way, so while the language does have good support for it, you'll struggle to find many people interested in helping you with it. I'm not sure anything can be done about this - you can't expect the experienced users to answer questions they're not interested in.

Re: Scala Native v0.1

#223

Post by usrusr »

SureshG wrote: post #211
Recurecur wrote: post #75

Earlier quoted context omitted.

In general (not for server apps), two major benefits of Scala Native are: - Predictable latency if desired (optional GC) - Very low call overhead for C ABI As to your point about memory use, Java trades memory for convenience, not performance. GC requires substantially more memory for similar performance. I read an IBM blog (which I can't find at the moment) within the last week which showed a Swift web service runni…

The medium post is really a stupid benchmark. Check this for a real JSON serialization benchmark - https://www.techempower.com/benchmarks/#section=data-r13&hw=...

To be fair, in that list, the spring entry didn't exactly run circles around the competition either. It's somewhere between the better PHP contenders and even behind grails (which can be pretty accurately described as spring with layer of slowness added on top). Really looks like there is something unfortunate going on with the idiomatic way to implement those examples on spring.

Re: Scala Native v0.1

#224

Post by geodel »

pjmlp wrote: post #215
taway_1212 wrote: post #214

Earlier quoted context omitted.

As a Scala/Java dev, I'd be willing to explore Go not because it seems like a better language (I have no opinion), but because I'd hope there's less design pattern/enterprise-overengineering approach among devs. Even in Scala, which is super-flexible, people tend to structure code like they do in Java - everything is decomposed into tiny classes to the point of absurd. One of the reasons is that the mocking framework…

If Go ever gets adopted by the enterprise for full stack applications, not only devops related stuff, expect enterprise architects to come up with GoEE .

SwiftEE looks far more probable as IBM has already jumped on Swift on server thing. The no-GUI and no-framework Go is not helping Java style solutions.

Re: Scala Native v0.1

#225

Post by lmm »

twic wrote: post #158
kentosi wrote: post #143

This is extremely exciting. I can't wait to try this out. On the other hand, I wonder why such an effort was never carried out with Java itself? Or maybe it was but just never took off?

It was. Several times. It didn't take off for two reasons. Firstly, it's not really any faster than a good JIT, and Java has very good JITs. The startup time is better, but the startup time of a JVM itself is actually pretty small ('time java -cp . HelloWorld' prints 'real 0m0.112s' on my machine), and for the uses Java is usually put to, irrelevant. I'd be very interested to see some benchmarks for Scala Native. Sec…

> Secondly, there's enough dynamic code in the Java ecosystem - bytecode weaving, dynamic proxy generation, plugin classloading, etc - that in practice, your AOT-compiled application need to have an interpreter along for the ride anyway. That means you don't even save the space overhead and distribution complexity of deploying a JVM.

The key advantage of Scala in general is that these things are rarely necessary - the fancy type system and generally expressive language make it much easier to address the use cases with "vanilla" Scala instead. So Scala Native will hopefully be able to bypass this issue.

Re: Scala Native v0.1

#226

Post by geodel »

q3r3qr3q wrote: post #182
geodel wrote: post #173

Earlier quoted context omitted.

Maybe some apps do not have classpath. Here is what I see of running kafka instance on one of my server. And it does not looks like as simple as it gets. java -Xmx512M -Xms512M -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true -Xloggc:/opt/kafka_2.11-0.10.0.0/bin/../logs/zookeeper-gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateSt…

It's a few lines of code to get sbt to combine everything into a single jar. Do other languages not requiring including libraries?

Statically compiled languages like Go do not.

Re: Scala Native v0.1

#227

Post by pryelluw »

jwdunne wrote: post #199
pryelluw wrote: post #178

Earlier quoted context omitted.

Im one of those. Anytime Python / Django doesnt cut it I use Go. Works very well.

Have you got a few examples where you had to replace the former for the latter? Really interesting.

Sure. Last one was a static asset server that had to perform or the users would notice a delay. Built one in Go in about a week and put it behind nginx on a vps. It was faster than required, stand alone, and used very little memory. Its still running to this day.

Re: Scala Native v0.1

#228

Post by lmm »

geodel wrote: post #226
q3r3qr3q wrote: post #182

Earlier quoted context omitted.

It's a few lines of code to get sbt to combine everything into a single jar. Do other languages not requiring including libraries?

Statically compiled languages like Go do not.

Well, there are two separate questions here:

1. What should the default be? Java build systems default to building dynamically linked, though it's a few lines to change. IMO dynamic is a better default for large projects, as you usually have more library modules than executable modules. On the other hand a large project is likely to already involve a fair bit of build config, so maybe the defaults should be optimized for small projects.

2. Whether you allow dynamic at all. To my mind it's always worth having the option, and I think Go will come to regret not having it if and when it ever gets used for large projects.

Re: Scala Native v0.1

#229

Post by tootie »

jwdunne wrote: post #160
pjmlp wrote: post #139

Earlier quoted context omitted.

> isn't the thing the kids are learning these days Yep, they learn Ruby and then they need to go JRuby when performance becomes relevant. :)

Or they tend to just Go. Interestingly, I've read a lot of Go users come from the Ruby and Python communities.

It's the Never Java crowd who I just don't get. Java is almost always the most practical answer. And if you don't like Java, then use C#.

Re: Scala Native v0.1

#230

Post by taeric »

pjmlp wrote: post #201
taeric wrote: post #169

Earlier quoted context omitted.

Which is ultimately irrelevant here. Consider, C is rock solid safe compared to machine/assembly. (Though, I tend to share the annoyance of javascript...)

C is just as unsafe as Assembly, as the weekly CVE entries prove. The only differences between C and a powerful macro assembler like MASM, is that C is portable across CPU architectures and exposes less internals. Rock solid? With all the UB that Assembly actually doesn't have, and the types of memory corruption issues shared with Assembly programming, not really.

My point is that safety or otherwise of the target language is just not relevant. Even C has compile errors if you use the wrong type for an operation. Assembly largely does not.

Taken to the extreme, any language ultimately goes down to machine code. So if it was a relevant fact, it would be relevant for all languages.

Post reply on HN