ericmj

We do build for subpatch versions: https://hub.docker.com/repository/docker/hexpm/erlang/tags?p...

What made your test runner faster? We would be very interested in porting those optimizations to ex_unit.

And I remember seeing a lot of forum posts around the dangers of using GenServers (unless you know what you're doing).

The danger is using a single process of the GenServer instead of multiple, so you can get single process bottleneck that won’t use multiple cores. You don’t have to know any intricacies of BEAM or OTP to know and design around using multiple process instances of the GenServer.

I know you can do distributed state in Elixir too, but it doesn't seem as easy as it is in other languages.

You can use Redis in Elixir as well. Saying that Elixir is worse at distribution than Python/Ruby because ETS isn’t distributed is a bit like saying Python is bad at distribution because objects are not distributed. It’s especially strange since Elixir ships with a distribution system (so you can access ETS from other machines) while your other example languages do not.

As a simple example, I think Plug.Parser is wrong to raise an exception when invalid json is given to it (shitty user data is hardly "exceptional" and I don't need error logs with poor signal to noise). Plug sets the status code for parser errors to 400: https://github.com/elixir-plug/plug/blob/v1.10.4/lib/plug/pa...

You should check the `:plug_status` field of the exception and only log/report the error if it's in the 5xx range.

Elixir hasn’t done away with behaviours. They exist in the language and are used to implement features in the standard library itself and many libraries in the ecosystem.

You don’t have to go to Erlang documentation to learn about them since they are documented in Elixir as well [1] [2].

[1] https://elixir-lang.org/getting-started/typespecs-and-behavi... [2] https://elixir-lang.org/getting-started/typespecs-and-behavi...

Gun starts a process for each connection. The main idea for Mint was to not do this so that users can choose their own process structure.

Search on hex.pm is not great and can definitely be improved, but we are currently at the limit of postgres full text search afaik, unless there are some magic things to tweak. This means we need to switch to other technologies to improve the search which is a bigger task.

But regardless of how good search is it wouldn't find ryal_core when searching for "commerce" if that word or any similar is nowhere in the metadata. The description for the package ryal_core is "The core of Ryal." which doesn't do the search any favours.

There seems to be confusion here about the language semantics. There is no mutability in the expressions you have shown. buffer.copy() would not make sense since the language is immutable, why would you want an explicit copy mechanism when every update is essentially being performed on a copy.

It still runs on a single 7$ hobby dyno. Package and registry downloads goes directly to our CDN so the dyno only gets traffic for the HTTP API and website.

Pattern matching and function overloading based on types are different but can be used for the same purposes.

For function overloading the decision for which implementation to use usually happens at compile time along with the type checking. Pattern matching happens at runtime but is more powerful since you can pattern match based on you guessed it: patterns, instead of just types.

Another small difference is that with overloading multiple functions with different signatures are created (they just share name) but with pattern matching there is a single function with multiple "function clauses".

What is wrong with the random routing they are doing now? Random routing works if your dynos can handle concurrent requests.

Yes, memory bandwidth is one of the biggest slow downs of ray tracing. Rasterization access memory very linearly which makes it very easy to cache and easy to optimize in hardware on the GPUs. But ray tracing access memory very randomly, two rays originating from pixels next to each other easily diverges and so hits objects far from each other in the scene. This means that ray tracing will spend most of its time waiting for memory.

Yes. But the "constant factor" will be very large, even larger than for traditional ray tracing, for some global illumination algorithms, even when you chose to only render a small part of the scene. For example photon mapping requires a pre-pass where you trace photons from the light source onto the scene, that means that reducing the pixel count doesn't decrease the time for the pre-pass. http://en.wikipedia.org/wiki/Photon_mapping

Purity has nothing to do with green threads. Many languages that doesn't have the concept of purity have green threads, like Erlang or Go. In fact, green threads are not a part of Haskell, but a part of the runtime. Purity is just a nice thing to have when working with threading or concurrent programs.