131–140 of 169 posts
Which frameworks can you use? This? http://nitrogenproject.com/
Also a recent book using other Erlang web technology: http://www.amazon.com/Building-Web-Applications-Erlang-Worki...
Earlier quoted context omitted.
I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.
What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.
With sufficient effort, you can have the equivalent of no shared mutable data.
What you cannot have is completely separate heaps, so that if one thread crashes for whatever reason it doesn't take your application down.
Also, good luck trying to find a garbage collector that supports completely separate heaps that isn't a direct copy/near-identical implementation of the BEAM[1] VM's GC.
[1] The virtual machine that is the stock VM for Erlang. (In fact I don't know of any others but I have never looked.)
Earlier quoted context omitted.
> Go will share memory, by default, and special attention must be taken preventing or avoiding it. Not really. If you use channels to communicate between goroutines, then the concurrency model is that of sequential processes, even if channels are implemented using shared memory under the hood. That is, the default concurrency model militated by Go is not shared memory, but that of CSP. It's disingenuous to affix Go w…
>What's your point? Purity for purity's sake? If go couldn't even implement its own interpreter in vanilla go, that's a sign that it's going to be a bad language.
Earlier quoted context omitted.
What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.
You can at best implement a mimicry of Erlang's message passing in Java. With sufficient effort, you can have the equivalent of no shared mutable data. What you cannot have is completely separate heaps, so that if one thread crashes for whatever reason it doesn't take your application down. Also, good luck trying to find a garbage collector that supports completely separate heaps that isn't a direct copy/near-identic…
Now it's even easier with ESBs. Write a ten-line grails service to expose a bin-packing facility with Drools and then never touch it again.
Earlier quoted context omitted.
I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.
What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.
It's the expressiveness at the language level that is really the "magic". For example, doing the equivalent of OO is not intuitive in Erlang, but completely possible (actually easy, but it looks...wrong) whereas it's supported by every Java tool. By the same token, pattern-matched message passing, lightweight green threads, and hot code deployment are primary concepts in Erlang.
Earlier quoted context omitted.
What prevents you from implementing an actor/message passing system in Java? Erlang's core concept of concurrency seems like something that'd be better suited as a library and app server than a whole language and runtime. I've yet to hear of any Erlang-specific magic that cannot be implemented inside another language.
How would you get per-actor heaps that cannot be violated by other actors? That is critical to Erlang's ability to recover from processes dying. I spent a lot of time doing Java and can't think how you could (you could in the JVM if you had language constructs for it, but then we are back to a new language). There's a reason Stackless Python's actors aren't just a library on top of Python.
Those are the first two "ghetto" hack solutions I can think of that wouldn't require significant code changes on a going-forward basis.
I worked in Cray's compiler department for seven years. If we couldn't dramatically parallelize someone's code, we couldn't sell a vector supercomputer. Period. Automatic parallelization is very possible. The problem is tends to be less efficient. A decent developer can often do a better job than the compiler by performing manual code restructuring. The compiler cannot always determine which changes are safe without…
We can do some of this now in most languages with hot-spot profiling, basic block analysis, selective inlining, and other innovations. However, you really can't beat low-level languages that explicitly "hint" at their execution paths.
By the same token, Cray's applications were...so...slow if you were foolish enough to run them on the expensive hardware and not the FEPs.
Earlier quoted context omitted.
>> I bet most of these super power languages will watch other pragmatic languages like Perl/Python/Ruby/Php etc eat their lunch over the next decade or so when they figure out more pragmatic means of achieving these goals. You know, Lisp's syntax is weird but it is exactly this what makes it so flexible. It's easy to manipulate code as data, because the syntax is very regular. Try to do that with C's syntax... So, un…
> You know, Lisp's syntax is weird but it is exactly this what makes it so flexible. It's easy to manipulate code as data, because the syntax is very regular. Try to do that with C's syntax... Why you'd "manipulated code as data"? To write macros? A good template system can help with that (if you need it) without homoiconicity. For me, the level of manipulation of "code as data" (and vice versa) you get with JSON/JS…
To write DSLs? You cannot use JSON to create new syntax for your language. The whole idea of DSLs is to extend the language for the problem at hand. How would you do that with JSON? Say... how would you write something like CLOS, for instance, using the alternative mentioned by you?
Maybe your option is good enough for a lot of use cases. But what when it is not good enough? Then you're stuck and there's nothing you can do except waiting for the language desingers to release a new version of your language with, hopefully, the changes you need.
Earlier quoted context omitted.
> Go will share memory, by default, and special attention must be taken preventing or avoiding it. Not really. If you use channels to communicate between goroutines, then the concurrency model is that of sequential processes, even if channels are implemented using shared memory under the hood. That is, the default concurrency model militated by Go is not shared memory, but that of CSP. It's disingenuous to affix Go w…
> Not really. If you use channels to communicate between goroutines, then the concurrency model is that of sequential processes Except since Go has support for neither immutable structures not unique pointers, the objects passed through the channel can be mutable and keep being used by the sender. Go will not help you avoid this. > That is, the default concurrency model militated by Go is not shared memory, but that…
I never claimed otherwise. But I do think you underestimate the utility of idioms.
> you get the exact same model by using queues in C.
No, you don't. C doesn't have lightweight threads, which means it can't support a useful CSP model of concurrency.
Just because Go allows shared memory doesn't mean its main concurrency model isn't CSP. Go doesn't force CSP on you, but that is nevertheless the primary concurrency model of the language.
Earlier quoted context omitted.
> which is just annoying I got that. I'm asking, why ? The decision to use generics or not has nothing to do with purity. It's about trade offs . If a decent balance can be struck with special privileged functions built into the language, I don't see how that is intrinsically bad.
It's not a decision about whether or not to use generics, it's a decision about whether or not to make it possible to use generics. The developers have decided that they should make it possible for themselves to use generics, but impossible for you to use generics. Do you really not see why that's annoying? That's not a matter of tradeoffs, because they've already made generics possible---for themselves. At best they…
Fine. That's what I meant.
> Do you really not see why that's annoying?
I can if you believe in purity over all else.
> That's not a matter of tradeoffs, because they've already made generics possible---for themselves.
Sorry, but what? Are you really trying to claim that adding generics for the entire language has exactly the same trade offs as adding a few built in functions that are generic?
> At best they might be thinking something like "only WE are capable of grokking when generics are appropriate; everyone else would abuse them", which is rather arrogant, no?
I think you've significantly misunderstood the issue. I believe my initial characterization is right: you think this is about purity. It's not.
Please read Russ Cox's short blurb on the "Generic Dilemma." [1] No part of it has anything to do with "we know better than you."
> The official response seems to be "no it isn't, you don't really need them."
No. The official response is "we don't know of an implementation that we're happy with." It's not a philosophical stance. It's a practical stance.