111–120 of 254 posts
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.
Actually, there are people using Scala.js to run Scala on AWS lambda, precisely for that reason. * https://github.com/tptodorov/aws-lambda-scalajs * http://underscore.io/blog/posts/2016/03/21/serverless-scale-...
Earlier quoted context omitted.
> For errors where we say lose connection to the database, or rabbitmq, we much rather have the nodejs-process die and restart, than try to construct reconnect logic. This sounds like a very Erlang-ish way to handle the problem. Another advantage is that if the server/process is in some weird state that's causing problems, killing and restarting it lets you clear out the broken state, and get back into the state that…
Yes. We're almost now risking it going the other way, that some bad programming goes unchecked for a long time, because overall, the process sort of does what it should. Even if it restarts like 10 times a day.
Earlier quoted context omitted.
> the cold startup time of the JVM itself (which is not relevant on a server in comparison to desktop Java apps). I disagree somewhat with this. We found that when we started writing microservices in languages that are not java, the short startup time changed how we did some error handling. For errors where we say lose connection to the database, or rabbitmq, we much rather have the nodejs-process die and restart, th…
I guess I don't see the difference here if your VM startup time is 3 seconds or 15-30 seconds. If that's the difference between the site remaining stable and the whole thing collapsing then it seems like you're setting yourself up for a big outage one day when the nodejs process isn't able to come back in three seconds for whatever reason.
Lost connectivity to RabbitMQ or Elasticsearch would mean our site is dead anyhow (you can't do anything). So either of those errors should arguably result in some static 500 pardon-our-appearance page.
But say someone messes up the network connection or we get a brief problem.
Why wouldn't the nodejs process start quickly?
Earlier quoted context omitted.
Sure, but it'd be nice not to have everything in the known universe depend on JavaScript.
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.
Earlier quoted context omitted.
Never touch a running system ;) Scala on JVM is much more tested than the new shiny thing. Also don't expect improved performance... many people think that the JVM is bloated and makes programs slower (this is mostly not true). The downsides of the JVM are more memory consumption/footprint (when you have e.g. small servers or micro instances) and the cold startup time of the JVM itself (which is not relevant on a ser…
Long time Java lover here. I agree with all your points, but in the context of Java at least (does Scala support this?) there is no simple static binary that can be built and released, which includes the JVM. I think 1.9 will have this option, but this is something I didn't realize I missed until I started work with Rust and Go. It makes deployment so much simpler.
That most don't want to pay for them is another matter.
The goal was to create JVM suitable for standalone GUI applications. Project was abandoned when Sun/MS Java wars started in favor of the Sciter (https://sciter.com).
As of NativeScala ... I think that approach (binary with nano JVM + attached class files) may work better and with less effort. Scala needs JVM infrastructure, GC, etc. as far as I understand.
Earlier quoted context omitted.
Sure, but it'd be nice not to have everything in the known universe depend on JavaScript.
Absolutely! I'm just pointing out that this need is so strong that people have reached for the slow throughput of Scala.js just to get its fast startup time. If we can have both, that's even better!