Yes "the continuity of residence" is required for naturalization.
> An applicant for naturalization ... must have resided continuously in the United States after his or her lawful permanent resident (LPR) admission for at least 5 years prior to filing the naturalization application and up to the time of naturalization.
To be fair, what made Elixir take off, other than syntax there is also the developer experience overall, including documentation, package manager, unit testing framework out of the box, web-framework initially inspired by Rails etc.
Though, slightly off topic, but worth mentioning, that both Erlang and Elixir communities support each other very well. For example, now not only elixir is built on top of Erlang, but also Erlang adopts some things from elixir, such as monadic expression `with` from elixir inspired `maybe` in Erlang, or starting OTP27 Erlang is using ExDoc introduced by Elixir to generate documentations.
Do you know what other ecosystem comes closest to the existing in Python? I've heard good things about Julia.
13 years ago when I was trying to explore the field R seemed to be the most popular, but looks like not anymore. (I didn't get into the field, and do just a regular SWE, so I'm not aware of the trends).
There is also a lot of development in Elixir ecosystem around the subject [1].
I don't think the ML community has an appetite for learning a different language.
There are Microsoft-backed F# bindings for Spark and Torch, but no one seems interested. And this is despite a pretty compelling proposition of lightweight syntax, strong typing, script-ability and great performance.
The answer will probably be JavaScript.
Everyone already knows the language - all that's missing is operator overloading and a few key bindings.
> There are Microsoft-backed F# bindings for Spark and Torch
> this is despite a pretty compelling proposition of lightweight syntax, strong typing, script-ability and great performance.
For exactly the reasons your mentioned, i feel like F# would have been the perfect match for both MLE/ETL(spark pipeline) work and some of the deep learning/graph modelisation such as pytorch.
Saddly, even from MSFT, the investment in F# as dried up
I guess it has something to do with those functions frequently used in guards.
_Notice tuple_size/1, map_size/1, byte_size/1 and some other functions/macros are defined in Kernel and documented in the section Guards[0]_
We can't invoke remote functions (which Tuple.size/1 would have been) in guards.
Though, there are some other functions that I can't think of a reason why they are "orphaned" such as put_elem/3 to put element into a tuple, while, for example, for maps there is Map.put/3
Some companies from the section "Who is using Elixir" are probably not using elixir anymore unfortunately.
1. Bleacher Report gutting out OTP[0]
2. I've heard that Toyota Connected also ditched elixir after some changes in the leadership of the department (just rumors I heard in the hallway tracks at ElixirConf)
I enjoy Elixir but this situation is quite unfortunate, there is alias, import require and use for referencing / pulling in code external to a file in some way or another, plus the possibility of calling a function from another module directly by name without an import statement using the module name – and the most annoying part of it is that none of these give an indication of which file the other module is from, which is like 50% of the utility of an import statement for me.
Instead there is this pattern of naming modules based on the file path they are located in, which is not enforced.
Doesn't Elixir (and Erlang for that matter) specifically require a module to not be in a specific place in order to have hot reloading of modules? Though I suppose you could still have hot reloading and require a module to be in a specific place.
Not sure, could be that Elixir stuck close to Erlang's module system yeah.
But for example gleam [1] is another language on the BEAM (compiles to Erlang), that has a much nicer approach:
All imports must be declared explicitly, and the import path in your local project is based on the file structure so you always know where something is imported from [2].
For those who is interested, as mentioned in the article, Gleam is already near v1 (v1.0.0-rc2)! And in a recent talk[1] Louis shared the idea, that there won't be major changes to the language anymore, and the main focus now is switching to the tooling!
