Looks nice, reading it. ![]()
Comments as I read it. ^.^
Due to immutable data, common operations such as for-loops aren’t available because incrementing a counter isn’t an option.
Well it ‘is’ available, just not in the form they expect as you carry state along a TCO or so. Perhaps word it as Due to immutable data, common imperative operations such as for-loops aren’t available in the usual imperative forms because there is no mutation of a variable. or so? ![]()
although the Enum library provides common iterative patterns in a manner that is comfortable.
Many already find recursion comfortable, if not more comfortable than iteration, so this sentence seems a little accusatory to me. ^.^
Using a hash pattern as an argument, that function will only be called if a hash with a key of data is passed in that has a nested hash which contains a nifty key that has a value of “bob” and an other_thing key. The variable other would be set to its value.
A hash? Is this referencing perl? o.O? I think you mean map, also internally it is not a hash-map last time I saw the implementation, so even describing it as a hash-map would not be accurate. ![]()
def example_pattern({ "data" => { "nifty" => "bob", "other_thing" => other}}) IO.puts other end
Also, your example, even though you were speaking of 'hash’es is not a map, it is a compilation error as it looks like you are mixing tuples and key/value referencing (which you cannot do in tuples). Also, the IO.puts other form I think is deprecated, you should have parenthesis like IO.puts(other).
Even though Go allows functions to be called by a specific interface type,
g.area(), it’s essentially the same thing as callingarea(g).
Not entirely. Go scopes out so you could have different area’s in different interface ‘trees’ as well as they are turned into an, as I recall, log(N) dispatcher to the correct implementation if the interface cannot be resolved or to built-in function pointers on the interface otherwise, it might be more accurate to change the area(g) to be something like g.__dispatchTable[area]() or something like that as pseudo-code.
Elixir can’t reuse the patterns as easily, but the pattern is always defined in the exact place where it is used.
Well there are libraries to handle that, or you could do it yourself via macro’s, but it is doable to reuse patterns and quite effective as well. ^.^
Strong typing essentially means dynamic typing where the compiler can catch virtually every type, with the exception of ambiguous arguments in a pattern match
I… do not think so? As I recall:
- Type castability?:
- Strong typing: Types cannot be transparently cast from one to another (Elixir, OCaml, C++, Python, …)
- Weak typing: Types can be transparently cast from one to another (Javascript, Visual Basic, …)
- Type liveness?:
- Dynamic typing: The compiler does not know the types, they exist at runtime, this cannot be optimized as well as static types
- Static typing: The compiler knows all types at compile-time and can optimize code and shrink memory usage based on that information
Elixir is thus a Strong Dynamically typed language, but your above description sounds like Static typing. Elixir, however, does have dialyzer, which can do a form of Success typing over the calls, but it is not static nor can the BEAM optimize based on that information nor can the compiler catch type errors.
Cooperative versus prescheduling
In this section you describe how cooperative scheduling works with Go, but do not go into near as much detail about how preemptive (not prescheduling) in Elixir works. Also it is preemptive, not prescheduling. ![]()
Go programmers have the ability to insert runtime.Gosched() in their code to force more check-ins with the scheduler as a precautionary measure for potential problem code. Run-time enforcement allows more trust of third-party libraries and real-time systems.
The beam has similar calls as well, including ones that can entirely reset the operating memory of a process as well (hibernate) and operate only on the next passed in parameters and such
Also note that functions must be inside modules in Elixir.
No they don’t, you can spawn anonymous functions too, your example even shows that. ^.^
Go calls them channels, while Elixir has inboxes.
Technically Erlang calls it the Process Mailbox I’ve seen everywhere.
Wrappers include
Taskfor simple async/await style calls;Agentfor concurrent processes which maintain and update a shared state;GenServerfor more complex custom logic.
Actually Task and Agent are not OTP parts, they do not even fit into the OTP supervision tree unless you do it manually. Those are more simple abstractions over spawn, not really parts of OTP I’d personally say.
Elixir inboxes default to unlimited messages but can utilize
Task.async_streamto define max concurrency for an operation and blocking senders in the same way as limited buffers on a channel.
Ehhh, not unlimited, rather the more full a mailbox the more the system pauses things trying to put messages into the mailbox of that process, so as a process gets overwhelmed with messages it slows scheduling everything else trying to put ‘into’ that process (but none others) as it tries to catch up. And the Task thing is something different entirely, maybe should be removed?
Elixir processes have their own isolated heap spaces which are individually reclaimed when the process finishes
Might also be good to mention Elixir has a GC but it only runs over a single process (not pausing anything else unlike Go’s GC) and only when the process starts getting large, else no GC may ever be run on a process at all.
I’m getting busy again, will keep reviewing later if I remember (or poke me). ![]()






















