jlouis

40 ms·

391.
by jlouis 13y ago
Indeed. Hopefully it can also, finally, be the stab in the back of DirectX. While DX is good and all that, I would much prefer to see an Open Standard prevail in this space.
392.
by jlouis 13y ago
Two points: * Erlang, nor Elixir, has currying. And they can't define their own infix identifiers/operators. This severely limits the way the language works, and you need built in support. * the |> notion is not even a higher-order comb
393.
by jlouis 13y ago
Note that Go is a language where it is well known how to optimize large parts of the runtime. The language design is sane, especially for execution speed. Ruby and JS are very expressive languages, but their design in semantics make a lot o
394.
by jlouis 13y ago
Unicode is a big thing in R16 and R17 where more of the system will use the unicode support we do have. Erlang modules will use utf-8 encoding and so on. As for a built-in bstring() type, it is being discussed, but there are other things
395.
by jlouis 13y ago
We have the equivalent of Haskells (lazy) ByteString in the types binary() and iolist(). We have had that for at least 6 years. Their space efficiency is also on par with Haskells. If you process big amounts of data as a string(), then y
396.
by jlouis 14y ago
The judge giving extensions is key here. It is customary to operate like this in Scandinavian countries. The idea is that the police has to make a case to the judge that it is worthwhile to still hold him and that they are making progress i
397.
by jlouis 14y ago
True, but the Erlang VM is not really written for fast startup. Module loading is serial and not parallel. The key here is that you can scale up in 0.6 seconds, which is awfully much faster than most other solutions, where scaling takes min
398.
by jlouis 14y ago
A task is a future or a promise which can deliver a result later. A Goroutine in go is more general than a task because they don't have to terminate when they deliver a result. The subsume tasks in any way. Goroutines are mapped onto (kerne
399.
by jlouis 14y ago
I really liked your links to mononcqc :) Because that are way better suggestions than just "intelligent routing" I only skimmed the first one, with Join-Idle-Queueing, but that sounds like a way better algorithm to apply.
400.
by jlouis 14y ago
There are still some important points missing from the discussion: 1. Operating at scale with parallel routing. 2. Handle faults while operating at scale with parallel routing 3. Providing correct statistical models for the situation. The o
401.
by jlouis 14y ago
The "you" were addressed to RG, not your experience. I completely agree that scaling is one of the harder problems in computer science. Most people just run a stateless system and hope for the best, but this is a delicate matter and it is a
402.
by jlouis 14y ago
It won't help much for several reasons: Context switches are expensive. Very expensive. So your system runs overhead in the operating system. And you need to spawn a process per request. Pooling processes is a problem as well. If we only ha
403.
by jlouis 14y ago
Overload is as much about establishing a baseline. Even under "perfect" routing, the problem is that you need to know what load your system can cope with. You need queueing to a certain extent since a queue will absorb spikes in the load an
404.
by jlouis 14y ago
It was news to me that Rails operated in this way. It is a very weak concurrency model (to be precise: it is nonexistent ). I knew that Rails was naive, but I had not dawned on me just how naive it is. It is interesting because then a syst
405.
by jlouis 14y ago
The reason I want to stay out of that discussion is that it often just amounts to some mud-slinging from one side upon the other. Intentionally mislead is quite an accusation and I don't think Heroku would indulge in it. Personally, I think
406.
by jlouis 14y ago
Indeed, and this is another point where rapgenius statistical model is wrong compared to the real world behavior of the system.
407.
by jlouis 14y ago
Your razor has a false-dilemma. They may be very competent, but having no intentions of caring for non-concurrent applications. Either because they did not think about the scenario or because the way RoR operates is silly.
408.
by jlouis 14y ago
So to recap: Ruby on Rails is using a default configuration where each process can serve one request at a time. There is no cooperative switch (as in Node.js) or (near) preemptive switch (as in Erlang, Haskell, Go, ...). The routing infrast
409.
by jlouis 14y ago
This reference is full of sound advice for the new Erlang programmer. If you break it, you need to have a good reason to do so. Also the seasoned Erlang programmer will find it useful.
410.
by jlouis 14y ago
I think the community is open to change of the language, given that the idea you propose is a good one. The thing that led tarcieri to write the "Erlang is a Ghetto" post was that he proposed the addition of Ruby-style blocks to the Erlang
411.
by jlouis 14y ago
I think you have it wrong, in my humble opinion. Erlang is not a tinkerers language. If you want to tinker you want Scheme, Clojure or Haskell, which to a far greater extent plays around with new ways of doing things in programming language
412.
by jlouis 14y ago
Your best bet is to grab the README files from http://www.erlang.org/download/ which tells you part of the story.
413.
by jlouis 14y ago
The cool thing is that the shot is in the wrong direction. It is the television that shoots a ray into the gun. Of course, there are no other way to do this, but it is fun to think about. Raytracing is the same. The ray is cast in the "wron
414.
by jlouis 14y ago
I want to make an important point on 3) If you have 600K concurrent connections they are concurrent. You could have them on a single core, limited severely on bandwidth and disk I/O. What you don't have is parallelism, since they are not
415.
by jlouis 14y ago
It is very close to being a TM, but there are differences, because of the way you describe the DFA in Brainfuck in contrast to a TM. Also, TMs are not entirely formal in the sense that there exists multiple TMs which all are equivalent - bu
416.
by jlouis 14y ago
BIFs are written in a better way than what you think. They all manipulate the reduction counter internally, if they run in complex patterns with loops. This in effect means you avoid the problem where a BIF hogs the CPU.
417.
by jlouis 14y ago
It should be pretty obvious that something is amiss here. Erlang is usually not the fastest language for (purely) CPU-bound tasks, of which this is the case. But being 34 times slower than a Javascript engine tells you that something is not
418.
by jlouis 14y ago
(author here) Haskell and Go just take a different approach. For some problems that approach is way better, so it is not a question of what the best way to do this is. In fact, the code I have written in Haskell does not seem to have suffer
419.
by jlouis 14y ago
Sorry, but I am not sure I understand which pitfall you refer to here? Can you elaborate?
420.
by jlouis 14y ago
Go is far more innovative than Dart. Dart is, roughly, "We want to have a Java-clone in the browser". Go actually makes an effort at cleaning up C while adding a structural OO model and building in concurrency.

More ›