61–70 of 87 posts
Earlier quoted context omitted.
What JVM stops threads for ~20 micros?
http://www.azulsystems.com/products/zing/whatisit 8000$ per machine, though. The G1 collector that will be made default in Java 9 might make some applications effectively pauseless too on some workloads.
Earlier quoted context omitted.
What JVM stops threads for ~20 micros?
http://www.azulsystems.com/products/zing/whatisit 8000$ per machine, though. The G1 collector that will be made default in Java 9 might make some applications effectively pauseless too on some workloads.
Earlier quoted context omitted.
No it's not. The proper way to design systems is breaking them into pieces, implementing each one the best way for that piece, and connecting them together. So, if one can't do DB's with Actors, do it with another tool or model (eg Eiffel/Java w/ SCOOP). Use Erlang/BEAM for what it's good at. There's also tools such as ZeroMQ that make the integration fast & easier. You get the best of both worlds.
All the more reason to use Erlang/JVM alongside other JVM languages. Polyglotism is one of the JVM's greatest strengths, and interlanguage interoperability on the JVM is the best you can get. And Erlang/JVM can be even better than Erlang/BEAM at everything Erlang/BEAM is good at. There is nothing in BEAM that makes it more appropriate for running Erlang than HotSpot (that may have been true in the past, but that's no…
It's not the best you can get but polyglot support is a strength.
"There is nothing in BEAM that makes it more appropriate for running Erlang than HotSpot (that may have been true in the past, but that's no longer the case)."
Still got it beat on latency and security risk per dollar spent: zero for Erlang w/ 5 digits for RT-JVM. If these aren't an issue, then Erlang on JVM may indeed be a superior option. I can imagine many use cases where it would be.
Earlier quoted context omitted.
That's not true for any language. It depends heavily on how that language is interpreted or compiled to machine code. A number of languages support threads but have eg GIL's. We have to judge each on a case-by-case basis. Both the Erlang language and BEAM designed specifically to support this. Here's some details for you in a JVM comparison: http://ds.cs.ut.ee/courses/course-files/To303nis%20Pool%20.p...
Unfortunately, that comparison lacks a lot of pertinent information on the JVM like new GCs, new schedulers, new, better JITs and various lightweight-thread implementations (it does mention Quasar, but doesn't understand that it works just like BEAM. BEAM also instruments your code, and in BEAM you can also accidentally block an entire kernel thread by calling a library not written in Erlang: just as you would if you…
Far as JVM vs BEAM, it's actually orthogonal to my comment as it would only support that implementation decisions matter for scalability on top of language's inherent traits. You've been arguing that yourself except on other side.
Earlier quoted context omitted.
I think the areas that BEAM is lacking in can be tackled and brought up to parity Probably. But why not spend that effort on the language and libraries? instead of homogenizing the VM-field That makes as much sense as saying your language shouldn't run on the kitchen-sink Linux so as not to homogenized the OS field.
> Probably. But why not spend that effort on the language and libraries? Because the best Erlang has to offer isn't really in the Language. Some in the Libraries. Most in its VM. I would pick Haskell or ATS over Erlang - unless I need those few unique features that Erlang/OTP really got right . > That makes as much sense as saying your language shouldn't run on the kitchen-sink Linux so as not to homogenized the OS f…
Earlier quoted context omitted.
It's been done before to varying degrees. The original in automatic programming was one that took input from case tools and autogenerated a lot of COBOL. Sun's DASL language from ACE project was a domain-specific language for specifying a type of web application. Around 9-10kloc of it autogenerated 100+kloc XML, client code, server code, etc. Lots of them in the 4GL category for database manipulation with WINDEV/WEBD…
I definitely agree that we'll always need people who think like programmers. We can develop tools in the vein of those you mention to significantly enhance the productivity of those people though. I haven't seen many tools like that that help in distributed systems or that allow one to easily visualize and understand an entire system.
Earlier quoted context omitted.
> Probably. But why not spend that effort on the language and libraries? Because the best Erlang has to offer isn't really in the Language. Some in the Libraries. Most in its VM. I would pick Haskell or ATS over Erlang - unless I need those few unique features that Erlang/OTP really got right . > That makes as much sense as saying your language shouldn't run on the kitchen-sink Linux so as not to homogenized the OS f…
Good points. Monoculture hurts us. BEAM people could be putting more effort into copying improvements in competition and academia. That would get BEAM performance way up there. Right now, they seem to focus more on other things with BEAM performing good enough for its users. With the diversity benefit on the side.
Earlier quoted context omitted.
Good points. Monoculture hurts us. BEAM people could be putting more effort into copying improvements in competition and academia. That would get BEAM performance way up there. Right now, they seem to focus more on other things with BEAM performing good enough for its users. With the diversity benefit on the side.
You would be surprised, actually. I think there's quite a bit of work going into BEAMJIT, an LLVM based JIT for Erlang that far exceeds HiPE. I won't argue with you though that the VM could use improvements gleaned from the last ten-fifteen years of implementation and research.
True for most stuff out there that's not the No 1 or No 2 choice for mainstream developers. Yet, results such as HipHop and PyPy show vast improvement can be made when even one company puts a lot of effort into something. A combo of academics applying to Erlang/BEAM the best in FP compilation and best in VM architecture might bring similarly dramatic improvements. A good precedent is how I saw the Racket Scheme team knock out significant weaknesses in their compiler practically as they were posted on forums. Not saying it always happens but that sort of thing in Erlang space would be interesting.
Earlier quoted context omitted.
I think the areas that BEAM is lacking in can be tackled and brought up to parity Probably. But why not spend that effort on the language and libraries? instead of homogenizing the VM-field That makes as much sense as saying your language shouldn't run on the kitchen-sink Linux so as not to homogenized the OS field.
> Probably. But why not spend that effort on the language and libraries? Because the best Erlang has to offer isn't really in the Language. Some in the Libraries. Most in its VM. I would pick Haskell or ATS over Erlang - unless I need those few unique features that Erlang/OTP really got right . > That makes as much sense as saying your language shouldn't run on the kitchen-sink Linux so as not to homogenized the OS f…
Earlier quoted context omitted.
> There is absolutely no reason to switch to the JVM when the EVM is a beast of its own. I think there is, if you want to concentrate your limited resources on the language and its phenomenal libraries while letting an enormous team working on the world’s second-largest open-source project take care of the VM for you, while at the same time giving you better performance and a wider reach. There are many more organiza…
Completely ignoring the massive resources it would take to make the switch in the first place. Erjang doesn't cut it. It's an incomplete research project that works on the basis of bytecode translation. Further, the disadvantages with regards to global GC are clearly listed. You say that it'll only keep improving, but that's essentially taking a leap of faith that the JVM developers will eventually get to parity with…
If I'm suggesting it, I obviously believe that the cost/benefit is worthwhile. I don think the effort required is massive.
> You say that it'll only keep improving
I say that it has already improved enough.
> Organizations for whom Erlang is out of reach simply because it doesn't use the JVM are absolutely petty
Not petty, but rational. Those organizations already have millions of lines of code, and lots of knowledge and experience on the JVM, and the reasons for choosing Erlang aren't compelling enough given the adoption cost. But if you lower those costs...
All I'm suggesting is simply lowering the adoption costs of an upcomer, rather niche tech with a small ecosystem (which would also, I'm convinced, considerably improve the tech).