jlouis

84 ms·

361.
by jlouis 13y ago
This limitation is only true if you can't utilize multiple small cores. Erlang would absolutely rock on a 1024 core machine, where you almost need no scheduler.
362.
by jlouis 13y ago
Google thought of this. Their Chrome browser probes for WebP server-side support through content negotiation. So you can still serve JPEGs to browsers, but those which are modern can get WebP images.
363.
by jlouis 13y ago
To me, the major difference is that the Java solution gives you one solution. The Go solutions gives you the building blocks. The latter has the advantage you get to recompose the system in new ways, yielding greater flexibility. In Java, a
364.
by jlouis 13y ago
I would contend Go does around 50% of what Erlang does. Node.js does around 10% of what Erlang does. You are right that both Go and Node.js has a lot of mass and a lot of acceleration right now. But Erlang has inertia in the projects where
365.
by jlouis 13y ago
Depends on how much the data is going to be altered. Changing columns is not a free operation in data stores. They require you to rewrite all the rows in many cases. This can be more dynamic short term.
366.
by jlouis 13y ago
Tracing and Refcounting are each others duals, www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf
367.
by jlouis 13y ago
The reason the TLB is so fast is also that it is fairly small and thus misses fairly often. Moving the TLB so it sits before the DRAM means that you can have a 3-4 cycle TLB with thousands of entries.
368.
by jlouis 13y ago
They don't translate. Rather, they compile code to their instruction set.
369.
by jlouis 13y ago
Off my head: Support the runtime, support the syntax and semantics, change the pattern matcher, write extensive tests, add it to the term_to_binary/binary_to_term protocol, add it to distribution, enable reading of maps in various func
370.
by jlouis 13y ago
Yes, and passed via distribution
371.
by jlouis 13y ago
https://wiki.theory.org/BitTorrentSpecification is by far the best starting point for the base protocol. Roughly, you can make certain short-cuts to get running quickly: Don't cache anything. Write data directly to dis
372.
by jlouis 13y ago
The bias is also that I work professionally with Erlang.
373.
by jlouis 13y ago
GHC has a very nice memory profiler in the runtime. You just enable that one and then it has rules to constrain views of allocation data. Profiling by "anything of type X" usually helps to narrow down a specific place in the code
374.
by jlouis 13y ago
Idris was not on my radar in 2010 :)
375.
by jlouis 13y ago
There is no total order on type systems. ATS is quite advanced yes, and as of late, I would put Scala in the same group of languages with highly complex and powerful type systems. But I have a hunch that the type system of Haskell allows fo
376.
by jlouis 13y ago
Lately though, I've been blogging at medium.com as well: https://medium.com/@jlouis666 since I prefer the platform to blogger.
377.
by jlouis 13y ago
There is no clear winner. Haskell wins on having a powerful type system and producing generally efficient code. Erlang wins the maintenance-race by far since you can trace on the running system and deploy code while it is running. And the f
378.
by jlouis 13y ago
The memory leaks I had to work around in combinatorrent were extremely subtle: loop = forever x and loop = do {x; loop} had different laziness semantics in the Process monad. The former leaked, the latter did not. I wrote all of the code in
379.
by jlouis 13y ago
The problem with kernel threads are they require kernel context. This is usually at least 4-8 kilobytes of memory. Which is about 8-16 times as much as an Erlang process...
380.
by jlouis 13y ago
I don't think so. If Rust has a single large shared heap for all proceses, then the approach is different. Rust can avoid GC and it can also implement proper incremental GC. But none of those things are as trivial as in Erlang, where y
381.
by jlouis 13y ago
This is why the R17 release of Erlang might get "dirty schedulers" for this kind of work. Essentially it gives you background thread pools where such work can be carried out. Currently, you can call C functions directly, but it is
382.
by jlouis 13y ago
Go links static executables only.
383.
by jlouis 13y ago
670 gigabytes is a puny database size. You should be able to press so much power through a system with a disk system like the one you have. I would seriously consider a Postgres setup on a data set of that size. Additionally, I would probab
384.
by jlouis 13y ago
For what it is worth, I would think people actually try different things in the existing setup before they decide on doing a switch like this. It is not easy to pull off at all. My guess would be that if you have way more Postgres knowledge
385.
by jlouis 13y ago
OpenBSD on some older hardware is probably even better!
386.
by jlouis 13y ago
DSLs are not the antithesis of static typing. Beware of using the word strong when discussing type classification. That word is highly muddled and doesn't mean the same thing to everyone. Haskell, for instance, is statically typed
387.
by jlouis 13y ago
No, it is not a joke. iMessage is not a secure communications channel. With this app in the wild, it is pretty clear it is not a secure communications channel. You should not post CC information along an insecure communications channel. You
388.
by jlouis 13y ago
The reason is four-fold: * Performance doesn't matter for a large set of systems we write. * Performance is far more a product of the programmer than the language you use (within reason, naturally. Don't do Video decoders in Pytho
389.
by jlouis 13y ago
It depends how much time is spent doing computation and how much time is spent doing lookups from disk. If the latter is clearly dominating, then a switch to Go will not help much.
390.
by jlouis 13y ago
Just for the record, this will not help. There are a lot of foreigners who will still be under surveillance and I am pretty sure they will start seeking ways to pull their data away from US soil.

More ›