mononcqc

25 ms·

181.
by mononcqc 14y ago
Could you point me to such distributed queue algorithms that can handle failure gracefully? I'm interested in reading on the topic.
182.
by mononcqc 14y ago
What I see in that graph's purple line is that with the most basic concurrency you can have that is not nil, you get better times than some statistically optimal load-distributing solution (choice of two). I'd like to see similar graphs wit
183.
by mononcqc 14y ago
If you can add even one worker per dyno, things get much better, faster. See http://rapgenius.com/1504221/James-somers-herokus-ugly-secre... for details. The really big problem there is having dynos that can handle only one request at a t
184.
by mononcqc 14y ago
I'm sure OP could prefer the extra 10ms, but then everyone else who can deal with random dispatching right now has to pay a 10ms penalty because OP built his stuff on a technology that can deal with only one request at a time on a server, w
185.
by mononcqc 14y ago
I'd guess the problem wouldn't be as bad if each instance could handle more connections/requests than one or two. Allow say, 10 of them, and you will reduce the problem by a lot I believe.
186.
by mononcqc 14y ago
Over many requests, both should average to N requests served to each instance assuming a uniform random distribution. The real issue is being able to figure out instances to avoid when some requests end up being slow. To put it another way,
187.
by mononcqc 14y ago
Most of the 'Power of two choices' I've read about assumes the presence of a global queue ( http://www.eecs.harvard.edu/~michaelm/postscripts/handbook20... ) -- there's a parallel variety, but they go light on details in that text. I'm unaw
188.
by mononcqc 14y ago
There's been countless arguments against PMods, mostly about their implementation, not the concept itself. Here's a list of a few I have compiled on the mailing list in the past: http://erlang.org/pipermail/erlang-questions/2012-August/068
189.
by mononcqc 14y ago
That's one hell of a flattering comment, thanks a lot!
190.
by mononcqc 14y ago
Thanks for buying it! I hope you'll enjoy it and that it will be a good source of objective information.
191.
by mononcqc 14y ago
The title is a derivation of 'Learn You a Haskell for Great Good' ( http://learnyouahaskell.com/ ), which was created first by Miran Lipovača, and has also been published by No Starch since then. When he made his version, I found it interes
192.
by mononcqc 14y ago
Hi, I'm the author and submitted a bunch of chapters here before, which were well received. You can buy it directly from No Starch Press with 40% off by going to http://nostar.ch/erlang_promo . Just as a reminder, it's 40% off for one week
193.
Learn You Some Erlang now out in print(learnyousomeerlang.com)
56 points by mononcqc 14y ago|17 comments
194.
by mononcqc 14y ago
I've written Learn You Some Erlang ( http://learnyousomeerlang.com , http://nostarch.com/erlang ) and this is of interest to me as a choice to make as an author. First of all, there are a few main categories of exercises I encounter when I
195.
by mononcqc 14y ago
Weren't all Elixir records using proplists or orddicts? Isn't that slower than your usual data access that doesn't make use of them? Or did you find it had no impact in practice?
196.
Simhashing (hopefully) made simple(ferd.ca)
2 points by mononcqc 14y ago|0 comments
197.
by mononcqc 14y ago
Preemptive scheduling also allows to add some interesting real-time guarantees by knowing some processes will be scheduled when they need to be busy, or to do it based on how much is waiting for them by interrupting others. For example, an
198.
by mononcqc 14y ago
They don't have the same concurrency model. JS uses callback-based stuff, cooperative scheduling, and has a single process to drive everything. Erlang has message-passing to mailboxes, preemptive scheduling, and many fully isolated processe
199.
by mononcqc 14y ago
There is no channel in Erlang. Each process has a mailbox. Each process is stateful. Node has only 1 and it works with callbacks as a way to do cooperative scheduling, Erlang has N of them and they work through message passing, using preemp
200.
by mononcqc 14y ago
What an insulting attitude towards janitors they have!
201.
by mononcqc 14y ago
I now enjoy it, but from my understanding, it depends on the attitude the team and management has towards it. Maintenance during the earlier phases of a product is also very different from doing it in the very late phases, when you know all
202.
by mononcqc 14y ago
'correct' is always only about a given specification, that is right for a limited period of time, assuming needs are well understood. It is very well possible to write satisfactory code one day that becomes inadequate the next. I won't deny
203.
by mononcqc 14y ago
See links and monitors in Erlang as another way to do it, tried and tested for decades in production code.
204.
by mononcqc 14y ago
the timeline C -> C++ -> Java -> Go is ridiculous at best, and this ignores work on exceptions or error handling in countless other languages that could have made it better.
205.
by mononcqc 14y ago
I swear to God if someone ever asks me about political interests related to the way I develop software in an interview I'm going to take a dump on their desk.
206.
by mononcqc 14y ago
I truly fear we'll get into debates of software conservatives vs. software liberals, and at some point some jackass will say "of course but <person x> is a researcher for <liberal/conservative> software engineering" as if it
207.
by mononcqc 14y ago
You could do as jlouis suggested and have each plane or flight manage its own seats/places. The state of different flights or planes isn't necessarily related and can be handled differently, giving you a smaller isolated unit than "everythi
208.
by mononcqc 14y ago
There is not much that is CSP about Erlang.
209.
Like a Hurricane(txt.io)
2 points by mononcqc 14y ago|0 comments
210.
User friendlessness(txt.io)
1 points by mononcqc 14y ago|0 comments

More ›