Lisp Flavoured Erlang 1.0 released after 8 years of development
312 points by vdaniuk 9 years ago | 91 comments- eggy 9 years agoGreat news! I wanted to learn BEAM/OTP, but had tried Erlang briefly years ago, and then went back to Common Lisp. Now I can try to learn BEAM/OTP in a syntax that is more appealing to me than Elixir's Ruby-like syntax. I like Elixir, and it is very popular, but true runtime macros are available in LFE 1.0. In addition, Robert Virding was one of the co-creators of Erlang, so his devotion to bringing the best Lisp he could to the BEAM platform within its confines, comes with some authority. The Google Group Lisp Flavoured Erlang is a very responsive community and resource for getting started. Congratulations LFE on your v1.0! OT, but I also use Extempore - the music, graphics livecoding environment with a great language, xtlang that I believe was based upon S7 scheme and has an LLVM backend [1]. There are some s-expression to WebAssembly projects floating around too. All around good news for all the choices to work with up front no matter your preferences.
[1] http://extempore.moso.com.au/- sjtgraham 9 years agoElixir is really not similar to Ruby and the comparison wears thin. This is my opinion after having used Elixir daily for the last 1.5 years and Ruby for 10 years before that.
Elixir really is a brilliant language and José et al have made the developer experience second to none with hex, mix, the language guide and docs. Compare how you bring up a repl: Elixir, type iex; LFE, cd into LFE dir, type ./bin/lfe. (EDIT: this is incorrect, see child) Trivial example and something easily fixed if it bothers you, but it's emblematic of the attention to detail that has gone into devx. I am deeply in love with Elixir. That Robert co-authored Erlang should not mean giving Elixir any less consideration IMO.
That said I sincerely wish to congratulate Robert on this 1.0, I look forward to using LFE in anger for something very soon now it is 1.0 (and it will be easy to slip in an LFE module into one of my OTP apps). Exciting times for the Erlang ecosystem.
- eggy 9 years agoI didn't exactly write it that way; I specifically referred to syntax. I am aware of the good things in Elixir, since I started playing with it years ago. I gave up trying to figure out why something in life becomes more popular than another, and just go with what I judge is best for me, makes me happy and gets the job done. Pony seems to be chomping on the heels of Erlang/Elixir/LFE, but I will stay with LFE for now. Jose and team have done a great job putting together a great ecosystem. I just happen to prefer Lisp syntax over blocks with 'END's. It is purely subjective. I know many languages to a certain degree (J, Python, C, Scheme, some Prolog, APL), and I try and pick the one that is best for the job. I just find myself comfortable in Lisp or Scheme. I am trying to grok Idris and Haskell this year, but I am really into livecoding, and so I chose Extempore. Sonic Pi is great, and is based on Ruby. Again, just personal preference. I am just excited about LFE for my selfish reasons ;)
- masklinn 9 years ago> Compare how you bring up a repl: Elixir, type iex; LFE, cd into LFE dir, type ./bin/lfe.
Is that a joke?
> If you have installed LFE, then you may start the REPL from any location:
what you quoted is if you're running LFE straight from the git clone[0], and noted so.$ lfe[0] because you may not want a system-wide LFE and LFE is being a nice citizen in explicitly supporting that use case.
- sjtgraham 9 years agoSadly not a joke, just me not reading properly (scanning over on my phone but no excuse!). Thanks for correcting me, I deserve the down votes for that. I fully retract and make no claims as to the devx of LFE. My feelings on Elixir remain unchanged :)
- philjackson 9 years agoIn actual fact, the LFE installation experience was a breath of fresh air:
I miss make.$ brew install erlang $ git clone ...lfe.git $ cd lfe; make && make install $ lfe
- sjtgraham 9 years ago
- eggy 9 years ago
- pmarreck 9 years agoI think the JVM can use some good competition and BEAM is ideally geared towards the next generation of immutable/functional/concurrent languages
- vvanders 9 years agoWRT to macros how does LFE differ from Elixir? My understanding was that Elixir macros were incredibly powerful(hence most of the language constructs being built in them).
- sjtgraham 9 years ago
- vdaniuk 9 years agoRobert Virding has just announced the release on twitter https://twitter.com/rvirding/status/710259707819249664
I feel that this LFE release further validates BEAM as a promising platform for future development of new programming languages. Also I look forward to reading SICP converted to LFE. Available chapters can be found here https://www.gitbook.com/book/lfe/sicp
- emmanueloga_ 9 years agoGiven you mentioned SICP... SICP is cool for its math and its puzzle-like problems, but I found http://scheme.com/tspl4/ a much better introduction to Scheme and more likely to help me solve problems with Scheme in the real world (i.e. a good reference book).
- emmanueloga_ 9 years ago
- akavel 9 years agoI've stumbled into an interesting related comment on twitter, didn't know:
"#Erlang based language ecosystem is more diverse than many know: #efene #reia #lfe #luaerl #erlog #elixir #mercury"
https://twitter.com/BillBarnhill/status/670601359016771584
edit: Wow, and many of them seem to actually be by the same rvirding who authored lfe:
- vvanders 9 years agoShame about luerl not supporting __metatable properly. That's half of why Lua is awesome.
Still a massive achievement, awesome stuff.
- rvirding 9 years agoMain issue is that luerl does support metatables. That caveat was written ago and I can't remember what it was I didn't support then. But as I said now it works.
- vvanders 9 years agoKudos! That's really awesome then.
I've got a lot of love for Lua(works great in embedded spaces, we use to do game logic in ~400kb block on a PSP with ~8mb of RAM).
Metatables are such an great way of exposing composability without putting a lot of restrictions on how the language works.
- vvanders 9 years ago
- rvirding 9 years ago
- i_feel_great 9 years ago
- eric_bullington 9 years agorvirding was also one of the creators of Erlang itself at Ericsson.
- vvanders 9 years ago
- rvirding 9 years agoI do want to point out that LFE has been release ready and of production quality for a long time but I tend to suffer from a "Jag ska bara"* syndrome which has delayed things. :-)
* I am just going to ...
- piokuc 9 years agoThank you so much for this wonderful stuff!
- piokuc 9 years ago
- Kuytu 9 years agoRobert Virding gave a short talk on LFE at ClojuTRE last year: https://www.youtube.com/watch?v=BvCBTpnlqs8
- jb1991 9 years agoVirding's YouTube presentation at a Clojure conference about this new lisp says this in the caption:
>LFE (Lisp Flavoured Erlang) has been designed to run efficiently on the Erlang VM and at the same time be a "real lisp" providing Lisp's good bits.
It also knocks Clojure a bit. What do you all think are the "good bits" of lisp that Clojure lacks?
- ska 9 years ago
Compared to common lisp off the top of my head (correct me if I am misrepresenting Clojure from memory): condition system, multiple return values and &key, CLOS with all that entails, and I seem to remember that clojure had some fiddly issues with macros and reader macros.What do you all think are the "good bits" of lisp that Clojure lacks?Not intended as a knock on Clojure, btw, but the JVM is somewhat limiting, in the same way you can't do a "proper" common lisp on the CLR.
- kaeluka 9 years agoFWIW, reading this sentence w/o any extra context, it doesn't seem to imply anything bad about clojure.
- hellofunk 9 years agoThe bit about Clojure was additional information in the source that I did not quote.
- hellofunk 9 years ago
- eggy 9 years agoReadable stack traces. Unfortunately, the JVM is the culprit here. I like Clojure's syntax, and some other bits, but if I were to chose a Lisp that runs under another system like Clojure, I'd choose Shen [1].
[1] http://shenlanguage.org/- hellofunk 9 years ago>The Shen kernel is under BSD and currently runs under CLisp, SBCL, Clojure, Scheme, Ruby, Python, the JVM, Haskell and Javascript.
Hm, I guess I can't imagine how that would work, one language running under all those environments?
- jarcane 9 years agoShen is built on it's own simplified parent dialect that is easily implementable in pretty much any language. Once you implement that core, everything else comes along for free, in theory.
- jarcane 9 years ago
- hellofunk 9 years ago
- yurrriq 9 years agoTail recursion optimization, for one. Clojure makes up for it with recur though, so in practice, it's not that big of a deal.
- ska 9 years ago
- jarpineh 9 years agoThis looks really interesting. I installed it easily through Brew. REPL seems to work fast.
Now if my Clojure flawored Lisp starter level knowledge could be somehow transformed into Erlang flawor...
I wrote this:
and this happened:> (map (lists:seq 1 10) (lambda (a) (io:format a)))
So, I'm not quite there yet. Hopefully somebody can make a Clojure to LFE comparison.#M((1 2 3 4 5 6 7 8 9 10) #Fun<lfe_eval.12.88887576>)And using Elixir based things like Phoenix springs to mind...
- strmpnk 9 years agoMap is a constructor in this case. You'll want lists:map/2 (fn comes first). I don't know LFE much so there may be sugar of sorts for this, perhaps a comprehension syntax.
- rvirding 9 years agoYes, there are list comprehensions but they return the list of values:
(lc ((<- x (lists:seq 1 10))) (lfe_io:format "~p" x))
- jarpineh 9 years agoThank you both. I didn't realize how Erlang flawored this really is. This did the trick:
Though all those OKs look kind of superfluous. I must read Erlang tutorial or two before I proceed.> (lists:map (lambda (a) (io:format (integer_to_list a))) (lists:seq 1 10))
- jarpineh 9 years ago
- rvirding 9 years ago
- strmpnk 9 years ago
- namelezz 9 years ago> A proper Lisp-2, based on the features and limitations of the Erlang VM
What are limitations?
- jsnell 9 years agoOne obvious example is that AFAIK the VM doesn't support functions with a variable number of arguments (foo/1 and foo/2 are two separate functions). This means that you can't have CL-style &rest or &key arguments.
- StreamBright 9 years agoThis is a feature to me more like a limitation. I do not like optional arguments &rest style. In Erlang you need to have explicit number of arguments and need to explicitly implement them. I really like that. Keep in mind that default values are trivial to implement when the smaller arity function calls the higher arity one with added values. Or you can call in yourself to the higher arity function and specify the parameters yourself. In my opinion this is elegant and safe way of dealing with the problem.
- seiji 9 years agoIn Erlang you need to have explicit number of arguments and need to explicitly implement them.
Or, you know, just use lists as parameters. That's the standard Erlang pattern for unknown parameters lengths (e.g. io:format("debug ~s because ~p~n", [SomeString, SomeType]))
- technomancy 9 years agoI feel like it's OK not having rest args if you leave them out in order to support currying, but leaving both out seems really weird for a language that's trying to be functional.
- seiji 9 years ago
- kazinator 9 years agoWhile &key is CL-specific (and if you don't have it, you can ad-hoc it if you have variable arguments) variadic functions are pretty important, and found broadly in Lisp dialects.
If you're on a VM or other target that doesn't do them natively, it's worth fighting tooth and nail to somehow get the functionality.
E.g. make an inefficient variadic type that at the VM level takes a single argument---a list or vector of the arguments. Or multiple types for different combinations of fixed arg arity plus variable list.
- wcummings 9 years ago>E.g. make an inefficient variadic type that at the VM level takes a single argument---a list or vector of the arguments. Or multiple types for different combinations of fixed arg arity plus variable list.
This would hurt interop with Erlang, which seems to be a goal of LFE.
- cronjobber 9 years ago> variadic functions are pretty important
As you already wrote in another comment, most practical uses of variadic functions can be replaced by macros.
What remains that is worth fighting the platform for?
- wcummings 9 years ago
- wtbob 9 years ago> One obvious example is that AFAIK the VM doesn't support functions with a variable number of arguments (foo/1 and foo/2 are two separate functions). This means that you can't have CL-style &rest or &key arguments.
But surely one could call a function with one argument, which is a variable-length list of arguments, right?
- StreamBright 9 years ago
- rvirding 9 years agoSome limitations (?): are no global data; no shared data; all data is immutable; the modules are different from CL packages; functions can't have variable number of arguments[]. It does however have support for decent pattern matching and full access to all of Erlang's concurrency, fault-tolerance and scalability properties. Plus real macros as god intended.
[] The macro handling can go part way to hide this.
- oubiwann 9 years ago"Macro handling as god intended."
I had to laugh :-) That reads like it's out of the Moonual ...
- oubiwann 9 years ago
- rvirding 9 years agoSome limitations (?): are no global data; no shared data; all data is immutable; the modules are different from CL packages; functions can't have variable number of arguments[]. It does however have support for decent pattern matching and full access to all of Erlang's concurrency, fault-tolerance and scalability properties. Plus real macros as god intended.
[] The macro handling can go part way to hide this.
- jsnell 9 years ago
- aidenn0 9 years agoThe users manual has a stub section for macros; does anybody know how LFE macros work? It says "lisp style" but that allows at least 4 options (syntax pattern-matching versus classic defmacro, and capturing versus non-capturing).
- aweinstock 9 years agoThere's some more in-depth documentation in the repo in doc/user_guide.txt, at around line 520-ish.
It has Common Lisp style defmacro (augmented with pattern matching), and Scheme-inspired defsyntax. The documentation warns that both are unhygienic, and `grep -ri gensym` didn't find anything in the repo.
- aidenn0 9 years agoSo I guess you just have to be super careful with variable and function names? That's the dark-ages for lisp, but still usable.
- aidenn0 9 years ago
- aweinstock 9 years ago
- clw8 9 years agoMy exposure to the Erlang world is limited to having read the first few chapters of Programming Elixir. Is interop trivial? Can you easily use Erlang, Elixir, and LFE in the same project?
- lpil 9 years agoYes, compiling a module where the source was written in another language is no different from calling a module written in the same one. In Elixir any time you call a module that starts with a `:` it has most likely been written in Erlang.
- sjtgraham 9 years agoTechnically all modules begin with : as module references are atoms. iex just hides it from for Modules made with defmodule (they have :Elixir prepended to them) /trivia
- sjtgraham 9 years ago
- lpil 9 years ago
- im_down_w_otp 9 years agoThe docs are sadly very incomplete still. :-(
How do I go about sponsoring a technical writer to complete them?
- philjackson 9 years agoI'd love to see a comparison with Clojure, anyone know of such a thing yet?
- oubiwann 9 years agoIt's a work in progress, but this might be useful:
- philjackson 9 years agoGreat - thanks.
- philjackson 9 years ago
- StreamBright 9 years agoYou can answer this from many angle:
- Clojure vs LFE
- JVM vs BEAM
- Lisp-1 vs Lisp-2
Etc, if you are interested only in the syntax differences, there is not much difference there (there are obviously some though!). I think generally speaking Erlang has fewer libraries than Java so that is a big difference in my opinion.
- rvirding 9 years agoOne major difference between the JVM and the BEAM is the type of application they target. The BEAM is designed to implement Erlang so it supports everything necessary to run Erlang at the base level. It is concurrency, fault tolerance and scalability from the very bottom all the way to the top.
- rvirding 9 years ago
- oubiwann 9 years ago
- alberth 9 years agoSlightly off topic: does anyone have an update on BEAM JIT?
- andrewvijay 9 years agoJust waiting for the day when someone launches a js version then the whole world is gonna be coding on erlang vm I think.
- sjtgraham 9 years agoI doubt it. IMO Erlang is fundamentally a different model of programming than JS and what about mutability and things such as pattern matching? It quickly becomes apparent that it would not be much like JS if it was to take advantage of all of Erlang's best bits.
- vdaniuk 9 years agoElixirscript is a thing though and it's being actively developed https://github.com/bryanjos/elixirscript
- andrewvijay 9 years agoIt's a good one to know about. Thanks!
- andrewvijay 9 years ago
- koder2016 9 years agoExactly, Erlang is a DSL for distributed applications. There is not much point to use it for anything else.
- tazjin 9 years agoErlang and related languages are applicable for most long-running applications.
The amount of people who actually use true distributed Erlang is probably small, because you get many of the benefits either way.
- seiji 9 years agoErlang is a DSL for weeding out smart programmers from drone programmers.
- tazjin 9 years ago
- andrewvijay 9 years agoConst keyword for mutability and I have no idea about pattern matching. Just the js syntax would be great I guess. And special keywords to match what misses or misbehaves . Just a try. Won't be bad!
- vdaniuk 9 years ago
- rvirding 9 years agoThere have been "hints" that why don't I implement JS on top of erlang as well. Would love to try, and some of the problems have been solved in my luerl implementation, but the main problem is time, the lack of it.
- andrewvijay 9 years agoJust give it a try and I think even if it's a limited subset of js it's still worth the try. If I can code in js on erlang vm for making distributed apps then it's going to be fun. Plus noobs like me get to know some stuff! Just ignore the naysayers and go for it! :D
- andrewvijay 9 years ago
- sjtgraham 9 years ago
- diskcat 9 years agoCould you believe that 2016 is the year of the beginning of the LISP renaissance.
Im going to buy some spare paren keys, they might become scarce in the immediate future.
- macmac 9 years agoIt started in 2007 with the release of Clojure and there are still plenty of paren keys around.
- 50CNT 9 years agoNow what you want it foot pedals. 3 for emacs and another double pedal for parens. Configure using M-x drumkit.
- macmac 9 years agoGiven the original theme for the MIT SICP lectures was magic, I think some kind of hand motions would be more appropriate.
- macmac 9 years ago
- lispm 9 years agoThe Lisp renaissance started in December 1999 with SBCL being forked from CMUCL.
- oubiwann 9 years agoAgreed. Well, with the date, anyway ;-) (though I am an SBCL user) Somewhere around 2000 we saw the end of AI winter. This most likely owes something to the fairly impressive Lisp marketing that PG did. Within a few years, several new Lisp books came out, and a few years after that we saw what the other poster mentioned: but not Just Clojure, a plethora of Lisps. To mention just a few: Clojure, Liskell, and LFE (LFE was actually started in 2007, first released in 2008). To the best of my knowledge all of these were completely unknown to each other at the time of their inception, and thus indicative of probable momentum in the wider Lisp community from an earlier time, possibly the once-again-growing acceptance of Lisp that started ~2000.
- jhbadger 9 years agoOn the other hand, 1999 was the downfall of LISP in the statistical community because that's when Luke Tierney decided to stop working on LISP-STAT, a LISP dialect with extensions for statistics that was semi-popular before the advent of R. While there have been statistical systems based on LISP since (such as Incanter for Clojure and a port of many of the extensions of LISP-STAT to Common Lisp) none have managed to make a dent against R, unfortunately.
- eggy 9 years agoSadly, I am old enough to agree with this assertion. I went from SBCL to ECL at one point looking for a small Lisp t embed or make games with, purely a hobby. I have not left the Lisp renaissance since!
- oubiwann 9 years ago
- 50CNT 9 years ago
- macmac 9 years ago
- seiji 9 years agoElixir is really not similar to Ruby and the comparison wears thin.
Wasn't Elixir just created because 100%-Ruby-til-Death programmers refuse to learn any other non-ruby-like syntax? It's like their brains would shatter into a brillion pieces if they ever had to think about tail recursion.
have made the developer experience second to none
Except, LFE isn't a giant community and companies and organizations and conferences promoting its usage and building companies around it.
LFE is a nice project that grows as people use it without trying to form an army/cult around it like so many other languages do these days.
and, if you think 'cd' is a complex operation, your brain would explode at trying to start the LFE REPL for most of its life:
erl -noshell -noinput -s lfe_boot start- dang 9 years agoPlease keep programming language flamewars off HN.
- seiji 9 years agoThe first part was a question and the second two parts were examples.
Writers can't be held responsible for the lack of reading comprehension exhibited by audience members.
- dang 9 years agoNo, you broke the rules flagrantly:
> Ruby-til-Death programmers refuse to learn any other non-ruby-like syntax? It's like their brains would shatter into a brillion pieces
You've posted chest-beating things like this before, too. It's destructive to the community, so please don't do it. If you're smarter or more knowledgeable than other readers, use your greater power to improve the quality of HN, not degrade it.
We detached this subthread from https://news.ycombinator.com/item?id=11303413 and marked it off-topic.
- dang 9 years ago
- seiji 9 years ago
- phamilton 9 years agoNope. Elixir was created because of the gap in functionality in Erlang, specifically around documentation and tooling as well as the lack of macros and polymorphism. [0]
The fact that it looks Rubyish at times is just the creator's aesthetic preference, but it wasn't the motivator.
[0] http://www.sitepoint.com/an-interview-with-elixir-creator-jo...
- 9 years ago
- pmarreck 9 years ago> It's like their brains would shatter into a brillion pieces if they ever had to think about tail recursion.
Come on, man. Your anti-Rubyist bias is showing way too clearly. I switched to Elixir from Ruby (or rather, am still trying to move all my project work over), and I grokked tail recursion just fine.
> LFE is a nice project that grows as people use it without trying to form an army/cult around it like so many other languages do these days
No product (language or otherwise; trying to include Apple, here) ever "tried to form a cult around itself." That is just a natural happening when a new thing is really really cool. So discounting something because of its popularity is sort of an "argumentum ad populum" fallacy in reverse (arguing for OR against something because of its popularity).
- dang 9 years ago