It can also be used for generating more optimal instructions which don’t need to check there arguments as they know through the compiler their types. It is quite cunning really, we are doing type handling in our dynamically typed language,
The dymanic typing will not go away because of this.
Blast from the past, the number one issue here is that the replace function is public, exporting functions not only increases compile time it significantly reduces runtime performance as the compiler cannot do it’s job.
I remember José joking about introducing nil was his billion dollar mistake, a common software engineering joke, but in all honesty I’ve come to believe it is defaulting to exported functions which is an explicit action in Erlang as all functions are private by default.
You may be misremembering or misquoting it. The phrase above is attributed to Tony Hoare (and it also relates to implicit nullables), and not myself.
Also, I am not sure private/public function is the number one issue for high compile times. It may be in some cases but it has never been the issue in my experience. So we need to see examples and their frequency to understand how well it generalizes. Also don’t forget that compilers are always evolving, so this could be something tackled/improved too.
Thread too long to parse in the early morning but I remember solving issues with lots of function heads by switching to a case statement.
so instead of
def funct(:a), do: bla
def funct(:b), do: hum
It’s now
def funct(arg1)
case arg1 do
:a → bla
:b → hum
end
end
Yes, if you are meta-programming code, that can indeed have an impact, since function clauses need to do additional work, such as process attributes, check for overridables, and what not, but I would expect it to happen only in the cases where hundreds of function heads are defined programmatically.
There are a few different ways of improving it too. IIRC, Phoenix Router fixes it by wrapping the function definition in an anonymous function, so it is preexpanded:
route = fn method, path ->
def match(unquote(method), unquote(path), do: …
end
This trick can actually save a lot of time. One system I used to maintain got down from 2min to 20s compilation time on the same machine because it was generating routes from YAML files metaprogramatically.
That’s very interesting given that ex_cldr and friends generate a lot of function heads at compile time. How would you suggest I apply this technique to (quite a lot of) code I have in the following form:
def define_backend_functions(config) do
backend = config.backend
quote location: :keep, bind_quoted: [config: Macro.escape(config), backend: backend] do
for locale_name <- Cldr.Locale.Loader.known_locale_names(config) do
delimiters = delimiters_for_locale(locale_name)
defp quote_marks_for(unquote(locale_name)) do
unquote(Macro.escape(delimiters))
end
end
end
end
Have you tried the case instead of function heads approach? The rewrite is easy, the speedup considerably.
Routex can generate a few helper functions per route for more than 2000 routes (I just stopped benching) while before it would trip over less than 200 routes due to compilation limits.[1] Not sure if it’s faster than José suggestion though 
Ps. Or :use persisted_term? Seems a fitting use case as I see no computations for the key and its load-once, read-many global state. One can even (re)load more locale data at runtime.
[1] the extension for legacy support of good old route helpers is/was the culprit. Blessed be Verified Routes.
Footnotes ↩︎
Yes.
But I have 17 libraries and many many constructs like that. So I’d like to see if there is an answer to the question I asked.
I am rewriting ex_cldr into a mono-repo localize library that will start to emerge in 2026. It will use :persistent_term (which didn’t exist when I wrote ex_cldr).