Erlang/OTP 21's new logger
ferd.ca
ferd.ca
I fully agree that too much of magic makes Django difficult and easy to newcomers at the same time. So I switched to Flask which is much pleasure to work with and now I'm very happy.
Side note, I wish variable rebinding were off by default but allowed on names with a sigil (or a ! ).
I feel like anyone who has written a Yacc-based parser for programming-language syntax will appreciate Elixir's grammar even more for these "quirks." Elixir's syntax is as beautiful as it can be while also being explicitly unambiguous. Which means that the language syntax is very easy to change or extend—unlike other PLs I could name, where the set of parsing rules resembles a late-game Jenga tower.
Or, to put that another way: Elixir isn't just a joy to use; it's a joy to be a core maintainer of. (How often have you ever heard anyone consider that part of a programming language's UX?)
Oh, and this simple, explicit set of parse rules also results in a highly-predictable and regular AST, which means you can write an macro-based DSL library in Elixir—one that will actually works with any arbitrary Elixir code hanging out inside your macro body—in not-much code, and without worry that a minor language change in the future will break your lib.
Any time lisp macros come up?
However, this is really minor in the grand scheme of things, it really is one of the most beautiful pls otherwise
It’s hard to sell anything that’s not in the TIOBE top 10.
To answer your comment more directly though, for many systems the benefits of excellent concurrency, monitorability, and fault tolerance can outweigh those of a strong type system or raw performance. It really depends what you’re doing, and how your team likes to work. No such thing as a silver bullet and all that.
Eg JavaScript lets you trivially memoize asynchronous requests, by caching Promise objects instead of responses. In Elixir you'll end up with enormous case expressions like this one: https://github.com/melpon/memoize/blob/master/lib/memoize/ca...
A task is a process that calculates something and eventually returns a result, which you can get synchroneously with `Task.await/1`. There's also an equivalend for Promise.all, which is just `Enum.map(tasks, &Task.await/1)`.
You can store an Elixir task but you can only await it once. You can `.then` a JavaScript promise as often as you want which makes a promise an excellent primitive for caching things that take time (eg network requests) without triggering the same request twice.
Every time someone says "just make a process and a supervisor, put it elegantly in the supervisor tree, go think through the failure modes, ponder a bit about these 3 or 4 edge cases and potential race conditions, and you're done! hooray!" I get a bit grumpy.
Elixir is awesome, but there's a simplicity to a single-threaded execution model that takes away a lot of the things that make concurrency hard.
All I'm saying is that there are things that Elixir isn't the best at. Is that so weird? I feel like everybody responding to me has this strong emotional need to defend Elixir. Why? it's just a tool. Like any tool it has pros and cons.
https://github.com/fazibear/export and https://github.com/hansihe/rustler
What is your system doing if you don't mind the question?
At the last project I worked on, we did a lot of work to optimize our logging, as it was being done on low spec TV set-top-boxes, and we were burning a ton of CPU cycles just doing formatting (lots of JSON serialization). What many devs fail to realise is that, unless extra effort is made (as in the Erlang system in the OP), every log operation you call is a synchronous, blocking call that can actually be relatively expensive due to all the serialization and I/O that goes on.
Async logging can help of course (necessary if you want to send logs over the network). But you can still spend a lot of CPU just formatting the log lines themselves.
The solution we decided on was similar to what you'd do in a C/C++ project: for release/production, add a build step that removes all logging commands below the logging level for the target. For example in C, you'd usually use macros for this, and if your macro wasn't defined in release builds, none of the logging code would be included in your executable.
This is great for performance but does have an operational trade off. Ops people might want to be able to change the logging level of a system to diagnose live issues. But if I think about all the CPU cycles and HDD storage spent on logging (and often those wasted cycles have a very real impact on UX or server latency), then I think in many cases it is worth stripping out anything lower than Error level as standard.
For instance, "arguments given to info/2 will only be evaluated if a message is logged".
You can also trim out (at compile time, like you did with the build step) all the logging commands below the selected level, with the ":compile_time_purge_matching" option.
The handler and filter structure with both global and per-handler filters is fairly clever as a way to turn these things on and off easily, and the module and level checks are done the earliest since they can allow to eliminate the most amounts of logs the cheapest way possible.
Elixir is definitely a darling of HN but there are some areas where there are some shortcomings in my point of view:
- A lot of people seem to love Elixir macros but I actually think that they result in a lot of compile time magic and make the code difficult to debug/read. Macros make code easy to write but supremely difficult to behind-the-scenes-understand and debug. The code that you write is transformed into something very different when you run it! Also every major Elixir library brings its own special macros which is a pain. Erlang OTOH does not use user defined code transformations (i.e. macros) so much so the code there is easier to comprehend. But the Erlang language is quite barebones and does not have the expressive power of some of its functional cousins like OCaml/ML/Haskell. Its seems that macros were an easy way to impart this expressive power to Elixir but it comes with the above mentioned costs.
- The Elixir (Erlang) runtime is stateful. This leads to many advantages but I kinda love the PHP model of every request is isolated/new from the rest of the system also. This may make PHP feel clunky/slowish but then its super easy to debug. PHP works out fine for _most_ systems even at scale. If your system does not have extreme requirements then PHP should work out fine.
- Elixir is not statically typed. In 2018 for a new project its hard to justify not using a typed system to make code more likely to "run" properly out of the gate or increase your confidence while refactoring it. Even a simple type system like golang's will do. No need for something complex like C++/Java/Rust etc.
In summary there is a lot of good in the Erlang/Elixir ecosystem. I think it makes sense to use this platform in many scenarios.
P.S. I've talked about PHP above. It continues to be fashionable to bash PHP and I feel this is a meme that must be combated. PHP 7.x is a much improved platform. Once you look past some of its historical warts you'll find that it can be very productive to work in. Of course it lacks static typing but if you specify the types of the your function parameters and (comment) annotate the type variables you can get some of the benefits of typing if you have the correct IDE/code analysis tools. (Elixir/Erlang also have "soft" static typing via dialyzer).
Is this actually a problem? The macros are not really overused, most library developers are sane about limiting the use of macros, and the lexical scope of any given macros is limited by the require/include semantics. "use" is pretty bizarre, but I've never had a problem with "just roll with it"
2. Depending on the framework you use (we just use cowboy directly), Erlang HTTP pages/endpoints are pretty light on state as well, you need to pass them information or call global functions to make them stateful. Maybe I'm not getting you right here.
3. This is an issue to me as well, but I think most Elixir and Erlang developers would agree that this would really be nice to have, at least optionally. We're right now in the process of making our codebase "dialyzer-safe" but there are so many parts of it that could be checked statically. From what I got from different talks and articles on the subject, the main issues are the dynamic "dispatch" mechanisms, like throw/error/exit and general message passing that allow for arbitrarily typed data to be thrown at arbitrary other code.
No one knows how to do it. It is an open research problem and we are far from a solution still.
Its a tradeoff -- do you go with untyped BEAM concurrency or typed concurrency like in golang.
In Go you have to write code to catch unwanted error and figure out what can go wrong.
So there are many things in Erlang where it soften this no type weakness.
Erlang already has a dual nature:
- the sequential part, which strives to be a pure and mostly side-effect free functional language
- the concurrent part, i.e. send, receive, process preemption, message delivery semantics, etc, which is inherently stateful due to interactions between stateful processes
Gradual typing fits this model well, because it provides soundness to the sequential part of the language, while leaves the message passing parts which _no one knows how to_ type dynamically typed.
BTW, I've spent a while to integrate Gradualizer with Vim - https://github.com/neomake/neomake/pull/2115
Elixir was inspired by Ruby iirc and it was a project started in 2012 according to the elixir documentary by Honey.
Scripting languages without static typing have its place.
I don't believe all languages even new one starting in 2018 should be type. It depends on the language goals.
If you want a actor concurrency model with type then try Pony.
In Erlang for instance, you might have a binary like <<"foo">>, which is the 3 bytes, 'f', 'o', 'o'. The display representation of it - <<"foo">> - though, as an Erlang string (which is a linked list of numbers) takes up 18 bytes according to erts_debug:size, which is a huge multiplier.
As always, though, excellent writing by Fred.
Then there's also ways to prevent just printing huge terms out. That's what parameters like `term_depth` in many handlers do (I believe it's just `depth` in the default handlers). They limit how deep you go into outputting some data. So even if you have some very large strings or deeply nested structure, they can get elided when they reach a certain threshold.