Nicd
Reading this topic, I came to the question:
What is the purpose of the Kernel module?
As I understand it, it somewhat mirrors the :erlang module and contains all functions available in guards. But the problem is, now some map functions are in both Map and Kernel, the same for List. So Kernel contains both functions that work on many datatypes and functions that work only on certain datatypes. If we add the new map_get/2 and is_map_key/2, then map functions will be even more split between Kernel and Map.
This is what I see in Kernel:
- Functions/macros necessary for the structure of the language or that are useful to be default imported, operators/
def*/if/max/is_*etc. - Functions that operate on multiple data types,
get_in/update_inetc. - Functions that don’t fit anywhere else, like maybe
apply - Functions that work on single data types, like
hd/length/elem/map_size
Now category #4 has always bothered me. Why are these functions not in modules, for example Tuple.elem/2? It is very surprising for a new user to see that the most important functions operating on tuples for example are not in Tuple. Even from category #3 some functions could be moved to other modules, like now some spawn functions are in Kernel and some are in Process.
If the reason is Kernel has all the functions that can be used in guards, I think that reasoning isn’t so useful because I still have to go look at the list of functions that I can use in guards as Kernel has other functions as well. I don’t remember the list offhand, so it won’t matter to me if it’s elem/2 or Tuple.elem/2 in the list.
Is there a technical reason for this mixed bag of stuff in Kernel? What does everyone else think about it? I don’t mean to come off as abrasive about it and it’s not the end of the world, it doesn’t come up that often when I program, but I’m just wondering about the reasoning behind it.
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #ai
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First Post!- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
kwando
One reason is that Kernel is imported everywhere by default and it contains core functions which other elixir constructs is built upon.
See the module documentation for Kernel
Most Liked
josevalim
Yup. As commented on the linked thread:
Two other things to consider about this:
If we allowed
Map.sizeandTuple.elemin guards, it would be extremely confusing to most why then we can’t use something likeMap.getin guards. The lack of namespace reveals that there is something special about them. Today you at least know guards are a subset of Kernel. If we move them to modules, then any function that you have ever seen could be a guard.I could easily argue in favor of the guard functions because of #1 too. Imagine how verbose guards would be if each call in a guard had to be fully qualified
I think a good exercise to accompany your question is “how would the language look like if most guards were in potentially separate modules?”. Would it more or less confusing? How easy would it be to discover guards? If you rewrite some existing codebases to the proposed syntax, is it better? Worse?
Of the functions you mentioned, the only ones I would consider misplaced are
apply/3andapply/2, now that we have theFunctionmodule (hindsight is 20/20), and potentiallyget_inand friends, although I would still wonder where would be a good placement for the latter.michalmuskala
This has one important difference - you need to call
require, because it’s a macro. Similar with things defined usingdefguard, they can’t be “just called”, you need to explicitly opt-in to using them withrequire. Can you imagine requiring all theTupleandMapand others to use the guards? Each module would be littered with those.Nicd
Thanks for the explanation!
This I have a different opinion on, though, as my only process to discover guards is “google for ‘elixir guards’ and read the list”. Since not all Kernel functions can be used in guards, the only guide I can use is the list of guard functions, and it wouldn’t matter then if they were in different modules. I do agree then reading a guard with
Tuple.elem(tpl, 1)could lead to the confusion you mentioned, but finding out which functions are supported is already equally confusing.Last Post!
OvermindDL1
I do wish guards had their own ‘name’ namespaces, just like how macro’s get compiled to
:"MACRO-..."prefixed names, I wish guards had a:"GUARD-..."namespaces name, would make things like testing if in a guard or not unnecessary in function as each would have to be done via their owndef/defguard. Many other things could be done on top of that…But yeah, I do wish Guards were not in Kernel but where imported via Kernel, say from
Kernel.Guardsor so as well. At the very least the documentation aspect would be more clear.However, I don’t see the point in changing it, it works well as it is, as long as it continues the follow the pattern it uses (consistency is paramount, unlike the inconsistent multi-arg
for/withoddities ^.^;).