Last time I checked, detecting whether given set of instructions will reach halt state is not possible. For sure it looks like software problem.
Incompatible with user expectations that (assuming new syntax for vectors #(a, b, c, d)) this code can fail in runtime:
foo(X) when is_integer(X) ->
#(X, X, X, X).
As X can be greater than allowed vectored integer, as Erlang allows arbitrary length of integers (for example it can be 2048-bit integer and AFAIK there is no architecture that allows such integers, especially in the vectored operations).
Erlang has 2 numeric types - integers of arbitrary length and IEEE754-like floating points (not fully compliant as Erlang do not support NaNs and infinities).
We have different thoughts about it. First of all, each technology has it’s niche where it was meant to be used, for example C for systems programming, R for statisticians, Matlab for engineering, Julia for scientific computations, Go for Google networking stack, Java for Sun applications, ,NET for MS applications, etc. Going outside your niche rarely works, especially as you were strictly designed with completely different use case (immutability isn’t the best thing out there for number crunching).
I disagree, but ok, let’s assume you are right.
If you say so, I am not an expert there.
I disagree even more, but in such cases it is way better to use other languages like Julia or Python to do number crunching and connect to BEAM application via one of many possible ways to do FFI there (already mentioned NIF, ports, and C-Nodes, just pick your poison). For few reasons:
- There is already a lot of libraries for such use cases in other languages, porting all of that to Erlang-native implementation would be enormous job that no-one would have time for.
- New algorithms, ideas, and libraries will be always implemented in mentioned above languages, no-one will come and say “well Erlang seems like great networking language which also supports F16, so I will write my paper in it, despite the fact that all my colleagues use different language, so I will need to implement everything from the ground up”.
- Finding people proficient with these languages, and libraries for them, will be much easier. And knowledgeable people are much more important than any issues with FFI, especially as this FFI is simple and straightforward in Erlang (which I said earlier).
So if you want/need AI in you web application (99% of applications do not need it and even if they market it as containing “AI” these are often simple algorithms that I do not count as AI, for example simulated annealing, k-means or Bayes filter), then there is plenty of solutions that do not need BEAM changes. What is more, BEAM changes would be an issue there, as it means more places where it can break and more maintenance burden for the maintainers.
IMHO not worth it, and if you really want to do it, then make it as a commercially available NIF library. It will be much simpler, easier to maintain, and equivalently fast.
