Earlier quoted context omitted.
Erlang scheduler time share each processes. So if you have an infinite forloop, it while stop for several ms for other processes to run. Preemptive scheduler, I doubt Go have this, then again Go doesn't have a VM/OS system.
go 1.2 has preemptive scheduling http://golang.org/doc/go1.2#preemption
Ask HN: Why isn't Erlang more popular?
211–220 of 244 posts
Re: Ask HN: Why isn't Erlang more popular?
#212Earlier quoted context omitted.
You can recover a substantial portion, but there's a few things you can't quite get back. Since Go is a mutable-state language, and also a shared-state language (isolation is by convention, not by language design), you have to live with the consequences of that. In my supervisor tree implementation, the restart of a monitored goroutine is just to fire off a new goroutine on the exact same object again; if you still h…
I'd have to say your idea of supervisors misses the point. Supervised processes provide guarantees in their initialization phase, not a best effort. This means that they are always restarted to a known stable state. It's not just a question of retrying, it's a question of returning to a piece of data and environment that is reliable. I wrote on this more in details at http://ferd.ca/it-s-about-the-guarantees.html If…
I think it's unfair to explain how I "missed the point" to me when I'm the one who brought it to your attention in the first place, when I called it out explicitly as a weakness, in the context of a post explaining how OTP can not be completely ported into Go without loss. I did after all explain in a parenthetical that I tried to fix it, realized the fix wasn't really a fix, and decided just to go simple and idiomatic after that.
The thing is, while it is sad that we lose that characteristic of supervisors, there are still other useful characteristics: Sensible restarts; naive restart code has a lot of pathological cases. I rather expect my library to ship with a couple at first too, but we (yay open source) can fix it in one place, once. Composition of supervisors is a great way to build applications, with self-contained pieces; the whole "hierarchy" still applies, though I find with the elimination of the restart strategies it gets a lot simpler, for better and for worse. It's still nice to be able to build code and easily slot it into a management system, even if it can't quite be as powerful.
A complete translation is impossible, but an idiomatic one may be, and I'm already finding it useful even in my little coding efforts.
As for the REPL... yes, that is an unmitigated loss, no question. I'm mitigating it in my personal app with a lot more flexible logging and some more external controls, but there is no true replacement for a REPL. Though... we may get a REPL someday, it just may be either a mere subdialect of Go or a separate scripting language. I've resisted putting a dependency on one of the very young Go scripting languages in my project, but theoretically in another year or two this might at least be mitigated.
Re: Ask HN: Why isn't Erlang more popular?
#213That having been said, anybody who is serious about concurrent network programming knows about Erlang. The problem is that those people are far outnumbered by the people doing CRUD all the time.
Re: Ask HN: Why isn't Erlang more popular?
#214But
1) I don't currently do much that requires any of that.
2) I don't want to learn a completely different 'kind' of language just to hit one pain point.
3) Resources are quite limited (re the website, training, books)
4) and this is the biggee: I just don't want to do functional programming. Our Erlang booster? Want to know how much time he sometimes spent on mailing lists and such asking "how do you do X"? I mean for pretty basic stuff. I get the value of functional programming and immutability ("oh no you don't" you'll respond, but bear with me), but in the end it is too high a price to pay FOR ME. I work in imperative languages, I am comfortable in them, I can't get away from them (I need C++ for speed, for example), I'm just not going to take on a language that kicks my legs out from under me like that. Y'all can argue about the finer points of functional vs whatever, but I'll abstain. I'm interested in solving my problems, and the imperative model works very well for my brain and needs.
So, for me, an interesting toy. I'm 47 and don't have time to chase 'yet another language' which is all this is for me.
Now, if I was trying to solve issues like the ones that got Armstrong to write Erlang in the first place, perhaps I'd revisit it. But as it is? No. No time. Not enough return on the investment.
Re: Ask HN: Why isn't Erlang more popular?
#215Earlier quoted context omitted.
I'd have to say your idea of supervisors misses the point. Supervised processes provide guarantees in their initialization phase, not a best effort. This means that they are always restarted to a known stable state. It's not just a question of retrying, it's a question of returning to a piece of data and environment that is reliable. I wrote on this more in details at http://ferd.ca/it-s-about-the-guarantees.html If…
"I'd have to say your idea of supervisors misses the point." I think it's unfair to explain how I "missed the point" to me when I'm the one who brought it to your attention in the first place, when I called it out explicitly as a weakness, in the context of a post explaining how OTP can not be completely ported into Go without loss. I did after all explain in a parenthetical that I tried to fix it, realized the fix w…
Re: Ask HN: Why isn't Erlang more popular?
#216My theory: writing network servers that are not web servers is a relatively uncommon problem to have these days. One of the hardest parts about learning a new language is coming up with a learning project that showcases the unique strengths of the language without being intimidating to a newcomer or too contrived to actually be useful. This is difficult in any language, but it's especially so in Erlang. Obviously "it…
Re: Ask HN: Why isn't Erlang more popular?
#217Earlier quoted context omitted.
> I wouldn't be surprised by this. Go's concurrency pattern is fantastic Only for those not versed in java.util.concurrent, TPL, PPL, TBB, Cilk Plus.
java.util.concurrent doesn't have a convenient mechanism for "selecting" across available channels/queues without blocking. This is a key feature of erlang and go. There are ways to simulate it, but it's not the same thing. (I'd love to be wrong about this).
But then, one can use something like Akka, which I forgot to mention, and still be on the JVM.
Re: Ask HN: Why isn't Erlang more popular?
#218I haven't used or looked at Erlang, but bear with me. * no package manager This is _huge_. For example: I currently work very heavily with node.js. I understand all of the many, many problems with javascript. NPM single-handedly makes up for all of them put together, in my eyes. Which is to say - an amazing package manager can make a poor language. A decent package manager (pip, for example) allows a nice language to…
Re: Ask HN: Why isn't Erlang more popular?
#219Earlier quoted context omitted.
That'll be Robert Virding (see comment below) lol
Yes, that's me. Where is the "comment below"? Couldn't find it. I just want to point out that I don't dislike Lua at all, it is a small neat language with some very nice features. It just isn't something on which I would base a parallel system as it has too much sharing and other things which don't go parallel easily. Using it as plugin to erlang for doing "business" logic works quite well, either by communicating wi…
Re: Ask HN: Why isn't Erlang more popular?
#220It's just not suited for what I do. At work, I do number crunching. Essentially a bunch of simple calculations in a for loop. C++ is excellent for this. I use a lot of Python for rapid prototyping, and as glue code. When I need to do concurrency, it's usually the easiest thing to run multiple instances in parallel, or to submit jobs to a cluster. There is already a well-tested infrastructure in place, and I don't nee…
(It's not "C++ fast", of course.)