I think this is potentially a serious problem. It could cause a serious split in the community which I think would be detrimental. So while the elixir side may want keep the community together as they, through elixir, are using erlang and want to be able to influence the development, the erlang side may, quite legitimately, say “why bother as nothing they create is usable by us and we don’t see any positive feedback from our work”. Worst case it can be viewed as they are just using us without contributing anything.
For example while phoenix uses cowboy can I use phoenix from erlang and write my plugins in erlang? If not, why not?
If I was feeling paranoid conspiratorial I would say this had been done on purpose.
Primary reasons that it’s hard to use Phoenix or Ecto from Erlang is that they rely heavily on Elixir macros. There are parts, that can be easily used from Erlang and I’ve heard of some teams that do use Ecto from Erlang - writing the macro-requiring parts in Elixir and the rest in Erlang.
Fortunately, it’s not a complete “taking without giving back” situations. There are some PRs from the Elixir community into the VM and compiler and often into some libraries.
I think the primary barrier from making Elixir libraries more widely usable from Erlang is the tooling (and rebar3 in particular). I know there’s a will from the maintainers of rebar to improve things, but time is the limiting factor.
The usual way I see this is being worked around is to wrap everything in mix project / umbrella Elixir app. Then you can have some parts in Erlang, some in Elixir and they can communicate very well.
This is exactly why I think the Erlang community would be well served by deprecating rebar and embracing mix. Dividing efforts like this for a common requirement (build tooling) which really needs to work with as many variants of BEAM usage as possible is not an efficient use of resources nor does it provide the best user experience.
If rebar3 were great (having used it a lot, it is a HUGE improvement over previously versions of rebar, but I still wouldn’t call it “great”) then I would suggest the other direction just for the sake precedence (of rebar, not rebar3 in isolation). So this isn’t an Elixir bias on my part, but rather a pragmatic thought.
I’d guess that some Erlangers would be less happy to have a key tool written in Elixir rather than Erlang (“more dependencies for my dev environment!”) and of course there would be the usual intertia that comes from any move … but one can dream
I do think it is very much just a dream if only because rebar3 itself wasn’t universally greeted with enthusiasm over rebar 2 (which I still don’t really understand and there is also erlang.mk as well … so converging on build tools isn’t a strong suit in the Erlang community at the best of times.
I am reminded of the Bad Days when everyone was using autotools for C/C++, and then eventually enough people got tired of it (because it was really really poor) that new tooling was developed but then for a long while we had to deal with N different build systems, none of which were compatible with each other. These days CMake is almost ubiquitous, and while not perfect it is a combination of good worlds: ubiquity as autotools once had, and the modernity of something, well, more modern. Perhaps a similar path will be forged in the BEAM community …
No, not in terms of the BEAM, I think what @rvirding was meaning in terms of library usage. When you have your main project in erlang it is not easy to just add an Elixir library.
The build system is of course part of the problem. And the use of macros to some degree.
The other part is that it feels more natural to use erlang from elixir than the other way around, which of course make sense as elixir to various degrees extend the language for example with structs.[quote=“michalmuskala, post:22, topic:8556”]
I think the primary barrier from making Elixir libraries more widely usable from Erlang is the tooling (and rebar3 in particular)
[/quote]
Yes, mix has to be the “main” build tool for things to work as smoothly as possible if interfacing with erlang.
rebar3 works nicely with lfe and alpaca though but I take it elixir is a fair bit more involved.
What is the main problem here? I had to try again to use elixir from erlang to see if there had been progress and used the latest rebar3_elixir_plugin I could find.
It was not smooth sailing
I managed to compile poison, and then gave timex ago. I got crash dump when it tried to build ex_docs (who knows why), then I removed ex_docs as dependency which made it at least pass compilation. Unfortuntely Timex couldn’t fully be used because of Elixir.Tzdata module which had a beam file but couldn’t be loaded in the system. I gave up here but it is not just plug’n’play.
It seems the plugin needs mix to build the elixir code, whereas I would have expected the rebar3 plugin to just use elixirc and handle all the dependency resolution in itself. instead of actually having two build tools running. So I guess I agree with you that there is some work to be done here.
I don’t see much difference between mix and rebar3, they both have their pros and cons. Anything in particular you feel rebar3 is weaker at?
This is of course always the case and probably impossible to change. In any community there will always be resistance to change and it is both good and bad. It is good because sometimes the fast moving part of the community need to pause and think and make sure they don’t go down paths already travelled. It is bad because it prevents progress.
Given the fact that rebar3 has been adopted as the default erlang build tool I don’t see mix making it in there anytime soon unless it organically starts getting used by erlang developers, and for this to happens I think you need to listen why it is not used today and really see if the concerns are warrented (everyone likes to be listened to)
I don’t think that’s the case. I’m not a language designer, but my guess the reason is that piping to the end would mean we couldn’t have keyword lists as the last arg with their syntactic sugar as we do now (and as we like/have become accustomed to from Ruby/Rails)
I started answering this but it turned out to be quite long and incoherent (it is 2am here…) It is a good question and I will actually try to see if I can write something up as a response at a later time
Sure they could have been, just wrap them in [] as usual.
/me rarely uses keyword lists without them being inside a [], naked keywords look too much like arguments and are confusing until I can mentally parse it
Plus something like this would still work fine if piped into the end:
or, if it was actually possible to omit brackets with the KW list being in the middle/front:
DB.save use_transaction: true, logging: "HIGH", record
With record going at the end (whereas it reads better at the front, as DB.save record, or DB.delete account etc )
You can hate it all you like but you can’t ignore the fact that a huge number of people not just like it, but love it, and a significant number of people coming to Elixir came via Ruby and in no insignificant part due to the syntax’s likeliness to it
Or better yet, if it supported erlang property lists instead of just basic keyword lists:
do_stuff(42)
|> Blah.changeset(params)
|> DB.save(use_transaction:, logging: "HIGH") # Leaving out the value implies `true` in property lists, this would even be compatible with Keyword Lists if it became true at compile-time
Or better yet, if the save was partially applied with such default options (say via a, hmm, partially_apply or so at the top? Let’s name it db_trans_save) since it is likely to be used with the same options in multiple places in the file:
I think it’s more along the lines of wanting to take advantage of Elixir goodies, you’ll have to dip your toes into the Elixir eco-system - and I’m not talking about becoming an Elixir convert. Though I guess there is room for improvement when it comes to “compatibility”.
But I also believe that anyone who adopts Elixir with a one language attitude is fooling themselves - there comes a point where not being able to at least read Erlang becomes a handicap. For one, a lot of the existing OTP “wisdom” is tied to Erlang and it’s eco-system.
Also Erlang/BEAM seems very aware of the need to interact with other languages/processes (NIFs, ports, C/Java/Python nodes) to “get the job done”. To me this seems to favour a polyglot/language agnostic solution approach (i.e. maybe it isn’t that big of a deal to step out of the Erlang-zone to take advantage of what Elixir has to offer).
I don’t know what’s up with the general Erlang-syntax-phobia expressed by many imperative language developers‡, I prefer it’s brevity, never having been fond of the Ruby syntax in the first place. But I have to be honest - ever since “Programming Erlang” (2007) I wanted to get acquainted with Erlang but it’s relevance from my own perspective seemed a bit “way out in left field” to justify the investment of effort and time. That changed with “Programming Elixir” (2014) which seemed much less esoteric. Should Erlang have enjoyed a wider popularity much earlier in it’s lifecycle? I think so. Could, from the Erlang perspective, the Elixir hype seem puzzling and possibly even annoying? I can empathize with that. I’m still hoping that Erlang gets a bit more exposure because of Elixir but perhaps that is being naive.
Now when it comes wishing for “static type system support” I suspect that is going to take yet another BEAM language, one that is statically typed from the ground up (I only know of Alpaca) to act as a driver - though I’m not even sure how the BEAM could be a barrier to something that seems to be largely a compile time concern.
In the end it seems important that the BEAM gets more widespread visible exposure and use in whatever way possible.
‡ The ant turd tokens serve a purpose - having problems with those just means you haven’t built the right Erlang mindset yet.
I also don’t get the obsession with semi-colon free JavaScript
Though I like Clojure’s “whitespace is good enough” (“commas are considered whitespace”) but I don’t go around maligning languages that rely on commas
However beyond using whitespace as a delimiter I’m not fond of “syntactically significant whitespace” (e.g. Python blocks)
i.e. at the end of the day these are just (sometimes petty) preferences. These types of “dislikes” really shouldn’t get in the way of using/adopting effective tools (though Perl syntax does tax my tolerance).
But KW lists aren’t alway used with a pipe. I can’t really comment on the others as I don’t know enough about the lower level stuff (and why they may or may not be good feasible alternatives).
Well that just boils down to opinion and I think the key point here anyway is that a significant number (arguably the largest majority - a third in our poll) of Elixir users aren’t from those other languages but from Ruby and that in itself has brought more than just users, but ideas, talent, libraries, culture etc
Obviously Erlang plays a significant part too - and it’s precisely this marrying of the two that has led to the success we now see. It’s like what was said when Elixir was born; it’s as though Erlang and Ruby had a baby… and it wasn’t a mistake!
Entirely! The BEAM makes such a fantastic glue engine. ^.^
Yeah I think that is it too. I quite prefer erlang syntax over, say, elixir (ah if erlang had elixir-style macros, entirely doable ^.^). I think most of the fear of erlang’s syntax is it is not C-like, at least that was the issue a 1.5 decades ago I’d say. But yeah, I do get that bit of puzzling/annoying bit.
Not a barrier at all, however it does mean the JIT cannot take advantage of static type information to generate better machine code. ^.^;
Lol, true true, they have their specific functions, like ; is not ‘technically’ a token like it is in C++/javascript/etc, but is rather more of a binary operator where it runs the left expression, discards it, runs the right expression, and returns the result of the right as one example.
After being bit by some javascript stupidity where semicolons fixed it, I’ve used semicolons on the end of every appropriate statement ever since.
Commas are just a form of scoping, like take this convoluted example between elixir (uses commas) and ocaml (uses spacing):
# Elixir
f a, (b 4, 5), c+1, d
f a, b(4, 5), c+1, d
(* OCaml *)
f a (b 4 5) (c+1) d
You are swapping commas for parenthesis or vice-versa (although ocaml has other scoping constructs, parenthesis is what you’d most likely use in this case). Elixir optimizes for ‘heavy’ arguments, where the arguments are often more then just a binding and are often more complex expressions. OCaml optimizes for ‘light’ arguments, where the arguments are often just a binding and where more complex expressions need to be scoped. Elixir requires OCaml-Like scoping in cases where things become ambiguous where OCaml does not have the ambiguity at all as it enforces it. Just different styles in that way.
Likewise, makes refactoring a hell.
Ah perl, the language where you can call something identically in the same place and get back entirely different results, so powerful, but holy frick it is brain draining. ^.^;
But that example would generally be. ^.^
Technically your example in pure OCaml would be like:
DB.save ~use_transaction:true ~logging:"HIGH" record
And of course you can stop at any point to partially apply it, so could do this:
(* somewhere higher *)
let db_trans_save = DB.save ~use_transaction:true ~logging:"HIGH"
(* in functions *)
db_trans_save record
Traditional OCaml would have the use transaction and logging be optional arguments, can be left off, with the final argument(s) being the main data load.
I’m not sure where the macro’s come from though, Ruby does not have macro’s (though you can monkeypatch to hell), if not Lisp of course (that is what they are closest to by far, heck even sigils can enable a kind of scoped read-macro’s), so I’m not sure what ruby brings to elixir other than the syntax itself, which is about the only part of elixir I really really dislike for a multitude of reasons. Ignoring syntax the big main thing I’d change of Elixir is piping to last instead of first, that’d recover compatibility with the multitude of Erlang libraries, allowing them to be used in-place without needing to remake or create thousands of wrappers as Elixir has done, which makes using Erlang in Elixir significantly less popular than it would have been otherwise.
I think you are overlooking the role Ruby has played in the success of Elixir.
Even if you think it was ‘just’ syntax, it brought along a large number of Rubyists (currently over a third according to our poll and probably significantly higher at the start) who in turn brought ideas, talent, libraries, culture, friendships, proponents, authors etc. Remember, whatever it was that attracted them to Elixir from Ruby (syntax or otherwise) was precisely what was needed to entice them, to help get us where we are today.
So if you remove that, you dramatically change the path Elixir may have taken. Would it be the functional language taking the programming world by storm that we know and love today were that not the case? Arguably not…
The ecosystem of Elixir can be used from Erlang. I integrated Elixir into an Erlang project in early 2013. Sure, it required some hackery, but it was definitely doable. I remember that back at the time there was also a rebar2 plugin which allowed the same thing.
You can’t really write Phoenix specific stuff in Erlang b/c it requires features not existing in Erlang. However it should be possible (and fairly easy) to immediately delegate from controllers to a module written in plain Erlang.
For libraries which do not use metaprogramming to inject things into the client modules (e.g. postgrex, comeonin, gen_stage), it should be possible to write the client code in plain Erlang.
Erlang actually had a LOT of webservers, even going back well over a decade. Nitrogen/n2o was an especially fascinating one that I’d like to remake on Phoenix someday, it was a purely server-driven kind of UI interface, kind of like Drab.Live on steroids.
