Hacker News Reader

Comment by le-mark | Hacker News Reader

Looks like fennel compiles to lua; does that mean this is a blazing fast lisp when using luajit? And you can call any lua library? A blazing fast lisp with a large library ecosystem (luarocks)? That's very interesting indeed!

Edit; not bytecode, thanks

View on HN

Just to go ahead and "be that person." Pretty sure CommonLisp already fits the "blazing fast with a large library ecosystem."

The ecosystem can be somewhat confusing, because much of what would look like abandoned packages in most ecosystems are more like completed packages, but speed hasn't been a real failing of Common Lisp for a long time now. Talked about a ton, of course.

CL is a system in itself; it can be seen as an environment / OS, and has even been used in this role.

Fennel piggy-backs on a known and widely deployed language / VM.

This gives them different capabilities, and very different possible adoption curves.

True, but one very great advantage of Common Lisp is that it’s a (reasonably) well-designed system, borne of the combined experience of many people. It has many features which seem like hacks (e.g. optional dynamic scoping) or historical baggage (e.g. dynamic scoping) or like over-engineering (e.g. UPDATE-INSTANCE-FOR-REDEFINED-CLASS), but which are actually the product of sound engineering practice, and which lead to solid, well-engineered code.

I agree: CL is a wonderful language but you have to embrace the whole environment/philosophy if you want to adopt it. And the language is not so easy to embed which prevents many "enterprise"/application development use cases.

As a matter of fact the only game in town for embedding CL code is ECL which: 1) relies on the Bohem garbage collector 2) is LGPL licensed

Both points have cons which might discourage embedding of Common Lisp code in other applications. Matters would be different if there was something like a CL to C transplier adopting a generational GC distributed with a MIT/BSD like license.

SBCL on some benchmarks outperforms C, and what portions of the code are not completely public domain are MIT/BSD licensed.

My point was not about peformances but rather about embedding. CL performances are good and toghether with interactive development these are the main selling points. It's a compiled programming language that feels like a scripting language "done right". However try to develop something like an embeddable library in SBCL and then use it in native Android, Ios , Mac and Windows applications. This is something that can be done in Javascript, Go, Dart, C,C++, Lua and so on. As far as I know the only CL that can achieve something similar is ECL. In my opinion this limits considerably CL adoption because it forces to adopt the entire ecosystem as a whole.

In some of my own benchmarks, was indeed able to get better perf using SBCL for some graphics stuff vs. Love. I particularly want to run this stuff on mobile though, so Lua / Love is the way to go!

It "transpiles" to lua. So you can do anything lua does, run on any lua interpreter, use any lua library.

So yeah, blazing fast, with a decent macro system and fixing some of the odd corners of Lua at compile time. It's really a great little thing (it's 2k lines of lua, so super easy to embed/ship too).

Targeting Lua is a great choice, emitting byte-code ties one to a particular implementation.

There are at least two other Lisps in Lua

* https://github.com/sctb/lumen

* https://github.com/SquidDev/urn

I want to use one of these three in order to write Lisp code, while getting Lua's ecosystem and distribution, but I am not sure which is most stable, and the differences between them. Can anybody expound on what makes them distinct from each other? I see Fennel and Lumen as the same with a big exception that Lumen also transpiles to JavaScript?

[Edit] I recalled this older HN thread with some relevant information: https://news.ycombinator.com/item?id=16566825

The creators of Fennel and Urn both chimed in to describe the differences between the two here: https://news.ycombinator.com/item?id=16567763

tl;dr Urn is a much bigger language that happens to compile to Lua as an implementation detail. Fennel is much closer to Lua and is dramatically simpler, only diverging from Lua semantics when the changes can be implemented purely at compile time. (immutable locals, blocking accidental global references/setting, etc) The compiler output from Fennel tends to be pretty readable and looks a lot like the input.

If you need to write code that runs in the browser, Lumen is one choice, but you can also run Fennel in the browser using Fengari: https://fengari.io/ I know next to nothing about frontend development but was able to integrate Fengari into https://fennel-lang.org to get the live REPL working with ease.

Yes, I had a comment in that older HN thread. I think this has me moving towards Fennel when compared with Urn, since I want a smaller language, but the examples of Lumen in this HN thread:

https://news.ycombinator.com/item?id=17958650

are swaying me to spend some time with Lumen this weekend to understand how it compares to Fennel. The Lumen examples were pretty impressive and it works for JavaScript too.

I tried the live repl and input the fibonacci example:

  > (fn fib [n]
   (if (< n 2)
    n
    (+ (fib (- n 1)) (fib (- n 2)))))

which seemed to take, but then upon trying

  (print (fib 10))

it spit out the following:

  [string "return print(fib(10))"]:1: attempt to call a nil value (global 'fib')

Do I need to initialize fib before in the repl?

It works if you run both expressions from file. There's a tutorial page that explains why this doesn't work in REPL. See "Locals are per-chunk" here: https://github.com/bakpakin/Fennel/blob/master/tutorial.md#g...

Thanks, that makes sense. I will also try making it a global value assuming global works in the online REPL.

I find your point about Lua's ecosystem to be interesting. I have been working with Nginx/Openresty for quite a while now and I've found the Lua library ecosystem to be quite a bit lacking.

I like Lua quite a bit and it is of course, extremely fast, but I wish there were good "batteries" along with other stuff that I've come to expect from Python/Ruby et all. Of course, I've coded up some of those libraries myself as well. :)

Just wondering what people's general thoughts on this are.

I may not be in need of as many libraries as you. I find Lua has what I need. I have even started playing with Torch vs. Tensorflow, since I am not a fan of Python which is purely subjective for me. Python has a ton of libraries, but it just doesn't feel as good as Lisp or Lua, or many other languages to me. But then again, I love J! [1]

  [1]  jsoftware.com

> It "transpiles" to lua. So you can do anything lua does, run on any lua interpreter, use any lua library.

Bit odd statement, considering that LuaJIT afaik targets Lua 5.1 compatibility with some 5.2 extensions, while main Lua is currently at 5.3. I guess the question is what version Fennel is targeting

Fennel is continually tested against mainline Lua 5.1, 5.2, and 5.3 as well as LuaJIT: https://github.com/bakpakin/Fennel/blob/master/Makefile#L6

It works great with Fengari for client-side scripting; in fact this is what we use on the web site for the live REPL. We have run some tests against other obscure implementations such as Luerl and Rembulan but have encountered some bugs in those compilers that need to get addressed before they get integrated into the test suit.

There's already a blazing fast lisp with a large library ecosystem... It's called Common Lisp.

> There's already a blazing fast lisp with a large library ecosystem... It's called Common Lisp.

sorry what ? where does this meme comes from ? Most CL implementations are at best multiple times slower than your average JITted language

When people only care about the open source ones, maybe.

Where did the meme come from that the average JIT compiler is fast ?

Maybe you could post some links to benchmarks that demonstrate your claim.

The free, open source CL implementation that matters and pretty much everyone (incl Google) is using - SBCL - destroys luajit in performance, not to mention your average JITed language..

Out of interest do you have any links regarding performance comparison of SBCL and luajit.

Before they completely ruined the UI, it used to be possible to compare languages on Debian's language benchmark shootout page. But now I can only find Lua, and can't even compare it to Lisp.

If I recall correctly luajit was removed from those benchmarks, for reasons I'm not entirely sure why, but I think it was to do with including only the 'standard' interpreter for a language?

I seriously doubt SBCL "destroys" Luajit. Or maybe it depends on the type of code. I remember a few years ago doing some Project Euler problems in both Common Lisp and Lua, and my recollection is that for that sort of code (nested loops, array accesses, fixnum arithmetic), SBCL ran code that had no type annotations significantly slower than Luajit, and with full type annotations SBCL only slightly faster than Luajit (and Lua uses no type annotations!). Of course, that type of code is probably in the JIT's sweet spot.

(I recognize this is unscientific and anecdotal, but I'm just trying to point out that it would take significant evidence to convince me SBCL is faster than Luajit, because my experience is the opposite.)

Some benchmarks of graphics stuff was faster for me in SBCL vs. Love. Going with Love still, but yeah.

Like I said in a different reply, it was previously possible to compare right on Debian's language shootout page. Apparently they took out that feature, so here's an old link to somebody comparing SBCL, Factor, V8, and LuaJIT.

http://factor-language.blogspot.com/2010/05/comparing-factor...

All four languages have improved over the last 8 years, but you can see SBCL and LuaJIT are in the same ball park, each winning on some tests. My recollection is that SBCL usually "wins" in the number heavy tests like Mandelbrot, but I don't have time to dig up the links.

Interesting you should mention Mandlebrot:

https://old.reddit.com/r/programming/comments/6eg0x/where_ar...

> the inner loop of mandelbrot is now identical (at the ucode IR level) to the IR generated by a C compiler. All type checks have been eliminated and only the pure (statically typed) FP adds/multiplies are left (the remaining task is to transform the ucode to the best possible machine code -- working on it). Similar results can be obtained for other numeric loops.

^ This is from a ten-year-old post about LuaJIT optimizations.

Now I’m curious, so I’ll try to benchmark SBCL vs LuaJIT vs Fennel when I get home tonight and post the results.

Regardless, though, I think it’s clear that there are already fast Lisps.

I'm definitely interested in your results. I do want to chime in to say that I do not think this would, in any way, take away from any of these efforts. If anything, I would hope they would all help challenge each other. In a beneficial way.

I finally got around to doing this, and the results were nearly the same on the Mandelbrot benchmark. SBCL generates slightly faster code, but in this case it's using less efficient multi-threading.

I might try again with a different program.

https://jl2.github.io/2018/09/01/luajit-and-cl-benchmark/

Maybe most are so, but SBCL and CMUCL are reasonably fast. Also I am not sure what you mean with "average JITed language".

Reply on news.ycombinator.com