10 ms·

I remember reading pg's article on Lisp and startups, and at the time questioned if it was just mere luck. Then having a cursory look at Lisp, I questioned its

I remember reading pg's article on Lisp and startups, and at the time questioned if it was just mere luck. Then having a cursory look at Lisp, I questioned its relevance to the modern world. ... fast forward a decade later and I'm reading books on functional and logical languages for work. After the first chapter of The Little Schemer, I was at first blown away with the content, but then sad after I realised I had put off reading it late in my life. If you're reading this comment and thinking Lisp and what's the point? Take a deep dive. It you're still questioning why, I highly encourage you to read The Little Schemer (and then all the others in the series). Scheme, Lisp, and now Bel, are a super power... pg's article was spot on.

chrismorgan 7y ago
You and I both like Rust. Concrete performance is one key reason why I choose to use Rust for various things, and all Lisps I know of are just generally slower and use more resources; I’m not aware of any Lisp attempting to address this problem, and from what I do understand of Lisps (though I’ve never seriously coded in one) they seem at least somewhat incompatible with such performance. I’m interested in whether you have any remarks on this apparent conflict of goals. (I’d love to be credibly told I’m completely wrong, because syntax aside, which I could get used to eventually, I rather like the model of Lisps and some of the features that supports.)
- capableweb 7y ago
  I don't think "Lisps are just generally slower and use more resources" is true. According to "TechEmpower Web Framework Benchmarks" (which might not be perfect but at least give some indication), Clojure is one of the fastest language (in terms of handling responses per second) for building a JSON API with. Take a look at https://metosin.github.io/reitit/performance.html https://metosin.github.io/reitit/performance.html
  - StreamBright 7y ago
    The fastest for these sort of things are usually C++, Rust, C projects[1]. The fastest Java projects are Rapidoid, wizzardo-http, and proteus. The link you provided does not have a comprehensive comparison of different HTTP JSON frameworks. 1. https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json https://www.techempower.com/benchmarks/#section=data-r18&hw=...
  - chrismorgan 7y ago
    I don’t think those results are actually particularly meaningful or that they scale up very well, but I’m going to skip that and address other relevant matters. I mentioned resource usage, and that includes memory usage. The JVM can be surprisingly fast for some types of code, but it’s never a memory lightweight. I suppose I might as well mention another feature I value: ease of deployment. In Rust, I can produce a single statically-linked binary which I can drop on a server, or on users’ machines, or whatever as appropriate, and run it. For anything on the JVM… yeah, without extremely good cause I will consider dependency on the JVM to be a blocker, especially for a consumer product.
    - cies 7y ago
      TechEmpower is (historically) a JVM shop. No surprise they do not bench the aspects JVM stinks at (startup/warmup, mem usage, total installed size).
      - chrismorgan 7y ago
        It’s rather hard to meaningfully measure any of these figures. Startup you can measure, but the optimal tuning for faster general operation may start up slower, so now you might want both figures. And then you’re getting perilously close to development considerations, so once you’re doing that surely you should benchmark any required compilation, and so on. Warmup is even harder to handle well, because it introduces another dimension; even if you were presenting just a single-dimensional figure (which you’re not quite), you’re now wanting to consider how that varies over time while warming up, so now it’s at least two-dimensional. But unless warmup takes ages, you’ll find it hard to get statistically significant figures, because you have so many fewer samples in each time slice. Total installed size? Problematic because the number isn’t meaningfully comparable, as this is a minimal test, and a number in that scope gives no indication of how much is due to the environment (e.g. JRE, CPython, &c.), and how much further growth there will be as you add more features. People will also start arguing about what should count; if for example you count the delta from a given base OS installation, then you’re providing an advantage to something that uses the system version of, say, Python, and penalising something that requires a different and extra version of Python. Memory usage? Suppose you pick two figures: peak memory usage, and idle memory usage after the tests. Both are easy to measure, but neither is particularly useful. Idle memory usage, similar problem to disk usage, and so the numbers aren’t usefully comparable. Peak memory usage is perhaps surprisingly the more useless of the two, because the increase in memory usage is strongly correlated with how many requests are being served at once—and so a slower contestant might artificially use less memory than a faster one; and so if you wanted those numbers to be comparable, you’d need to throttle requests to the lowest common denominator, which could then be argued as penalising light memory usage patterns.
  - vindarel 7y ago
    and here the author ports a Clojure program to Common Lisp with a x10 speed gain: http://johnj.com/from-elegance-to-speed.html http://johnj.com/from-elegance-to-speed.html. Sorry, x300.
- deepaksurti 7y ago
  >> they seem ... incompatible with such performance Might answer your question [0] [0] https://news.ycombinator.com/item?id=2192629 https://news.ycombinator.com/item?id=2192629
  - chrismorgan 7y ago
    I don’t think so. My simple reading of things there is that that was for one particular micro-benchmark (and the Benchmarks Game is acknowledged to be unrealistic and not actually suitable for comparing language performance), that the results were not actually conclusive, and that it had required telling SBCL to do some stupidly dangerous things that you should probably never turn on on real software, because they may well make it behave catastrophically badly rather than just crashing when you have a bug. On https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... at present, the fastest SBCL implementation, which seems to include these optimisations, is at 2.0, with other SBCL implementations being slower, the first one (whatever that means) being 8.0; meanwhile, the Rust implementations range between 1.0 and 1.2. The SBCL implementations all use at least eight times as much memory as the Rust implementations, too. I think this demonstrates my point pretty well, actually.
    - armitron 7y ago
      The (micro)benchmarks game is a gimmick and should not be taken seriously. You forgot to mention that the SBCL #3 implementation also sits at 2.0 and is fully memory safe. I fail to see the reason for you presenting the facts in this manner especially the "stupidly dangerous things part" which is of course totally inaccurate. (safety 0) has its uses (e.g. like Rust unsafe). Your conclusions are not indicative of real world performance.
      - igouy 7y ago
        > … benchmarks game is a gimmick … What exactly is it designed to attract attention to? > … should not be taken seriously. Because? > … fully memory safe. Here's the problem, the programs are explicitly required to use function calls but: ;; * redefine eval-A as a macro
- elamje 7y ago
  I don’t know if you are wrong, but I would give fennel lang a look. It’s a lisp that compiles to Lua, so you can access LuaJIT performance while lisping away.
  - didibus 7y ago
    I don't think OP considers LuaJIT high performance, considering lots of Lisps are just as performant as LuaJIT.
- JohnStrangeII 7y ago
  There is no conflict of goals, languages offer certain features, some of them offer only "zero-cost" abstractions (C++ and Rust) and others offer more abstractions. You get what you pay for in terms of runtime executable speed / features trade-offs. The other factor is the compiler toolchain - see below. If Rust had the same features as most LISPs have, then using these features would make Rust programs as "slow" as LISP programs. That is generally true for most programming language comparisons. What also matters for final executable speed is the toolchain, of course. Any languages that compile directly using GCC or LLVM and allows for compile-time typing will be roughly in the same ballpark. If they use their own compiler, such as Chez or Racket, then they usually don't match the performance, because there is not enough manpower in their teams to implement all those nifty optimizations GCC and LLVM have. SBCL is probably the fastest LISP with its own compiler. (Or Allegro?) To give an example, here are some CommonLisp features that Rust lacks: Full object system with inheritance and multiple dynamic dispatch, dynamic typing, hot runtime code reloading/recompilation, garbage collection.
  - chrismorgan 7y ago
    You seem to be describing the effects of conflicting goals.
    - 13415 7y ago
      You mean trade-offs? The point is that every language and every implementation has them.
- mark_l_watson 7y ago
  I use SBCL to build command line applications. Reasonable enough memory use and very fast startup times. I for a while used to use Gambit Scheme for this but decided I like Common Lisp better. We no longer need hardware Lisp machines for good performance. That said, for some applications Rust is clearly better.
  - neonate 7y ago
    Why do you like Common Lisp better?
    - mark_l_watson 7y ago
      I have so much experience with Common Lisp, starting around 1984 on my 1108 Lisp Machine. I have used various Scheme implementations a lot, but I just have more history and experience with Common Lisp. Both are great choices, and there are many high quality Schemes, plus Racket. Experiment, and then choose your own favorite Lisp.
  - e12e 7y ago
    Do you have some examples you could share?
    - mark_l_watson 7y ago
      There is one in the new edition of my Common Lisp book https://leanpub.com/lovinglisp https://leanpub.com/lovinglisp You can read it online for free, and clone the github examples repo.
- antisemiotic 7y ago
  Not exactly lisps, but Carp (https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp) and Scopes (https://bitbucket.org/duangle/scopes/wiki/Home https://bitbucket.org/duangle/scopes/wiki/Home) might be worth a look. I haven't tried the former, and couldn't get the latter to do anything useful, though. (it looks like the author stopped responding to issues, sadly).
- roryrjb 7y ago
  I always thought that SBCL was considered high performance and for example Chicken Scheme compiles to C. Both might be slower than Rust but I always had the impression both of these were more performant than say Java, but I haven't used either in a meaningful way to really know how it would rate for your performance needs.
  - cylinder714 7y ago
    Chicken's author also created Bones, a Scheme that outputs x86-64 assembly language. http://www.call-with-current-continuation.org/bones/ http://www.call-with-current-continuation.org/bones/ README: http://www.call-with-current-continuation.org/bones/bones.html http://www.call-with-current-continuation.org/bones/bones.ht...
  - ska 7y ago
    SBCL is quite fast for a lot of things. I used to use it frequently for research projects that required performant code, and it generally wasn't to difficult to get within a factor of 2 of c code, though getting much closer could be hard. I haven't really kept up with it recently, but it regularly impressed me at the time.
- alfiedotwtf 7y ago
  Hey Chris :) I totally get you with Lisps and performance, but I was more talking about the beauty and elegance of code written in them. Algorithms written in Lisps seem to be pieces of art. And that's just Lisps... having a look at logic programming languages like Prolog and Mercury, it's amazing to see just how compact yet understandable an algorithm can be. They're beautiful! But as for performance, take a look at Mercury - its a declarative logic programming language with built in constraint solving, which compiles down to C, and its performance is great. We've rewritten some Mercury in Rust, and yes our Rust is faster, but not by orders of magnitude as you'd think.
  - DickieStarshine 7y ago
    How's the editor support with Mercury?
    - alfiedotwtf 7y ago
      Not sure about other editors, but there's syntax highlighting for Vim in the repo, and mtags (ctags for Mercury).
- aasasd 7y ago
  I'm currently using a CPU-slow machine, and I've discovered everything is slow among the popular scripting languages, except Lua. I've thought JS has good startup time, but some of my Lua scripts that are doing file i/o finish faster than node.js does a ‘hello world.’ Lua is also very lightweight on memory, to my knowledge. I think it can even do true multithreading, via libraries. So, there's a Lisp on top of Lua―compiled, not interpreted: https://fennel-lang.org https://fennel-lang.org It's deliberately feature-poor, just like Lua: you use libraries for everything aside simple functions and loops. And it suffers somewhat from double unpopularity of Lua and Lisp. But it works fine.
  - DickieStarshine 7y ago
    Have you looked at Julia?
    - MiroF 7y ago
      Julia is compiled to machine code, not interpreted
      - vanderZwan 7y ago
        That has nothing to do with how "lispy" it might be. Part of the compiler is implemented in femtolispe no?
        MiroF 7y ago
        I suspect this does have to do with whether or not it is a fast scripting language, considering a language compiled into machine code is by definition not a scripting language. Sure, flag me, but my comment was relevant to the discussion.
      - fiddlerwoaroof 7y ago
        Many lisps compile to machine code too. Compilation vs. interpretation is a feature of an implementation, not a language.
- SigmundA 7y ago
  What if there was hardware accelerated Lisp?: https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
  - agumonkey 7y ago
    a forth array cpu based lisp machine would be a fun toy
- bachmeier 7y ago
  "they seem at least somewhat incompatible with such performance" Lisp is for the other 99.5% of programming that doesn't require you to wring every last drop of performance out of your CPU.
- nickpsecurity 7y ago
  You can build a Lisp to stay close to the metal with zero-cost abstractions. Most people drawn to Lisp are wanting productivity instead of max performance. Besides, the commercial Lisps and fastest in FOSS are really fast. There was a systems type of Lisp called PreScheme that was closer to what you're envisioning. Carp also aims at no-GC, real-time use. Finally, ZL was C/C++ implemented in Scheme with both their advantages compiled to C. Although done for ABI research, I've always encouraged something like that to be done for production use with tools to automatically make C and C++ library bindings. https://en.wikipedia.org/wiki/Scheme_48 https://en.wikipedia.org/wiki/Scheme_48 https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp http://zl-lang.org/ http://zl-lang.org/
- tambourine_man 7y ago
  After JavaScript’s success, I’m convinced any language can be made fast given enough time and money. Some languages are easier to be made faster, but I think JS almost proves there’s no such thing as a language incompatible with high performance by design. You’d be hard pressed to conceive a more dynamic language and here we are, with crazy fast performance through many JIT tiers, interpreters, compilers, each of which would take years for a bright engineer to understand.
  - chrisseaton 7y ago
    JavaScript is an extremely small, well-defined language with relatively simple semantics and very limited metaprogramming. It’s not a challenge compared to something like Ruby.
    - iLemming 7y ago
      When was the last time you looked at it? Javascript is not small anymore. ECMAScript specification is over 800 pages, only a few hundred pages smaller than Java's.
      - chrisseaton 7y ago
        > When was the last time you looked at it? I’ve read the latest version of the specs of all these languages in detail. I’ve worked professionally on a team implementing Ruby, the latest version of JavaScript, and Java at the same time, using the same language implementation system, so I can directly compare. JavaScript is simplest by far. There’s quite a lot of sugar now, but the core semantics are small and simple. The core semantics of a language like Ruby are an order of magnitude more complicated.
- iamwil 7y ago
  There's a post about the three tribes of programming. https://josephg.com/blog/3-tribes/ https://josephg.com/blog/3-tribes/ Tribe 1: You are a poet and a mathematician. Programming is your poetry Tribe 2: You are a hacker. You make hardware dance to your tune Tribe 3: You are a maker. You build things for people to use alfiedotwtf falls in the first tribe. You fall in the 2nd. Different tribes have different values, and hence all the back and forth.
  - dkarras 7y ago
    What if I'm kind of all of them? Eternal damnation? I've always strived to write beautiful code - for things people find very useful - in ways that push boundaries for what people think is possible with the machines we use. I have succeeded in balancing any two of the above, to terrible detriment of the third. Never been able to juggle the 3 at the same time and this bothers me a lot. The upside is this pushes me to learn a lot, downside is I'm never content with my craft. I'd have loved to solve domain specific important problems with a domain specific language I craft with a LISP and have state of the art performance while doing so.
  - kirillzubovsky 7y ago
    Love this distinction. Makes a lot of sense, and is probably a key to happiness, to both realize which tribe you're in, and whether you're trying to argue with the tribe with another set of principles.
  - alfiedotwtf 7y ago
    I like this :) Programming is my poetry. Damn... that's a nice take
- vindarel 7y ago
  Some pointers: - how to make lisp go faster than C: https://www.reddit.com/r/lisp/comments/1udu69/how_to_make_lisp_go_faster_than_cpdf/ https://www.reddit.com/r/lisp/comments/1udu69/how_to_make_li... - https://github.com/marcoheisig/Petalisp https://github.com/marcoheisig/Petalisp "Petalisp is an attempt to generate high performance code for parallel computers by JIT-compiling array definitions. It is not a full blown programming language, but rather a carefully crafted extension of Common Lisp that allows for extreme optimization and parallelization."
- sedachv 7y ago
  The issue is memory management. Henry Baker helped popularize linear types in the early 1990s (http://home.pipeline.com/~hbaker1/ http://home.pipeline.com/~hbaker1/) in his proposals for Lisp, from which work Rust's affine types derive, but no one wants to write in a dialect with those restrictions. Garbage collection seems like an algorithmically insurmountable problem. The other overheads are constant time, and Common Lisp already includes mechanisms to optimize them away (declarations and efficient arrays).
- didibus 7y ago
  You may be wrong in thinking all programs require maximum performance? I just find your question a little confusing. My house is only two floors, yet meets all my needs. A bigger house would just waste my time in cleaning, cost me more in maintaining, in heating, etc. It's the same for programs. Target performance at all cost, and for a lot of programs you get a hard to maintain, non scalable, bug ridden, featureless program that took you way too long to build. That's why for example I use Clojure and Rust. Rust gets the least use, because the programs I tend to write can manage fine with Clojure's performance. In fact, I mostly toy with Rust, because I really never needed to write anything higher performance. So I'm just not sure what you mean. The world is full of useful programs that meets the needs of their users which aren't high performance. For all these programs, Lisp is a superpower.
agumonkey 7y ago
10 years after college I finally understood the lisp, ml, prolog ladder mainstream world is damaging to my soul
- alfiedotwtf 7y ago
  I know right :O
braythwayt 7y ago
A major mistake is thinking that Lisp itself is magic. The magic is actually in how Lisp changes the way you think.
- alfiedotwtf 7y ago
  No, no... that's exactly what I meant :)
throw_xyzyz 7y ago
Guile + guix. I work in devops and that replaced a horrible mess of god knows how many containers with a straight forward, boring and reproducible single large instance of Guix SD.
- partdavid 7y ago
  I'd be pretty interested in reading about this work. Do you have a blog post or any code you can share around this case study?
  - throw_xyzyz 7y ago
    No, I find the current climate of online discourse too vindictive and narrow minded, hence the throwaway accounts. I've scrubbed as much of my presence from the internet as I could because of that. I'm toying with having something in Freenet or some even more user unfriendly format so I don't have to deal with idiots with a grievance getting me fired.
- deleted 7y ago
  [deleted]
- dexterlagan 7y ago
  Very interesting. I played with Guile a while ago and came back impressed. I'd love to hear more about your work.
  - throw_xyzyz 7y ago
    What it says pretty much, used Guix to replace a bunch of containers people had set up and needed to be coordinated on the network. The only reason why they were using those was because the other devs were on Windows/Mac and couldn't run the software natively. The rest was boring details about getting the right version of the jvm running using shepherd instead of systemd, which I liked a lot because it wasn't systemd.
breck 7y ago
I just read Fibonacci's Liber Abaci (from 1202). I think I'm not too far off the mark if I say Lisp in our day is what the Indian numeral system was in Fibonacci's day. A new writing system that has significant practical advantages.
dang 7y ago
> fast forward a decade later and I'm reading books on functional and logical languages for work What work has you doing that?
- alfiedotwtf 7y ago
  I work at a wonderful company called YesLogic, and we try our best to do PDF generation. Mercury works wonders against all the constraints that CSS rendering can throw at us.
  - zem 7y ago
    if you have any blog posts about that up i'd love to read them!
    - alfiedotwtf 7y ago
      Can't say when, but we're planning on blogging about it in the near future. You'll most likely see it on "This Week in Rust" :)
      - dang 7y ago
        If you want to, you can email a draft to hn@ycombinator.com and we might be able to give some tips on what the HN community tends to respond better to. Same offer goes for anyone who's working on something they hope will interest HN. Just don't be disappointed if you don't hear back for a long time—and as a corollary, don't send it just a couple days before you plan to publish. We have terrible worst-case latency!
        alfiedotwtf 7y ago
        Awesome, thanks for that!

chrismorgan 7y ago

You and I both like Rust. Concrete performance is one key reason why I choose to use Rust for various things, and all Lisps I know of are just generally slower and use more resources; I’m not aware of any Lisp attempting to address this problem, and from what I do understand of Lisps (though I’ve never seriously coded in one) they seem at least somewhat incompatible with such performance. I’m interested in whether you have any remarks on this apparent conflict of goals. (I’d love to be credibly told I’m completely wrong, because syntax aside, which I could get used to eventually, I rather like the model of Lisps and some of the features that supports.)

capableweb 7y ago
I don't think "Lisps are just generally slower and use more resources" is true. According to "TechEmpower Web Framework Benchmarks" (which might not be perfect but at least give some indication), Clojure is one of the fastest language (in terms of handling responses per second) for building a JSON API with. Take a look at https://metosin.github.io/reitit/performance.html https://metosin.github.io/reitit/performance.html
- StreamBright 7y ago
  The fastest for these sort of things are usually C++, Rust, C projects[1]. The fastest Java projects are Rapidoid, wizzardo-http, and proteus. The link you provided does not have a comprehensive comparison of different HTTP JSON frameworks. 1. https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json https://www.techempower.com/benchmarks/#section=data-r18&hw=...
- chrismorgan 7y ago
  I don’t think those results are actually particularly meaningful or that they scale up very well, but I’m going to skip that and address other relevant matters. I mentioned resource usage, and that includes memory usage. The JVM can be surprisingly fast for some types of code, but it’s never a memory lightweight. I suppose I might as well mention another feature I value: ease of deployment. In Rust, I can produce a single statically-linked binary which I can drop on a server, or on users’ machines, or whatever as appropriate, and run it. For anything on the JVM… yeah, without extremely good cause I will consider dependency on the JVM to be a blocker, especially for a consumer product.
  - cies 7y ago
    TechEmpower is (historically) a JVM shop. No surprise they do not bench the aspects JVM stinks at (startup/warmup, mem usage, total installed size).
    - chrismorgan 7y ago
      It’s rather hard to meaningfully measure any of these figures. Startup you can measure, but the optimal tuning for faster general operation may start up slower, so now you might want both figures. And then you’re getting perilously close to development considerations, so once you’re doing that surely you should benchmark any required compilation, and so on. Warmup is even harder to handle well, because it introduces another dimension; even if you were presenting just a single-dimensional figure (which you’re not quite), you’re now wanting to consider how that varies over time while warming up, so now it’s at least two-dimensional. But unless warmup takes ages, you’ll find it hard to get statistically significant figures, because you have so many fewer samples in each time slice. Total installed size? Problematic because the number isn’t meaningfully comparable, as this is a minimal test, and a number in that scope gives no indication of how much is due to the environment (e.g. JRE, CPython, &c.), and how much further growth there will be as you add more features. People will also start arguing about what should count; if for example you count the delta from a given base OS installation, then you’re providing an advantage to something that uses the system version of, say, Python, and penalising something that requires a different and extra version of Python. Memory usage? Suppose you pick two figures: peak memory usage, and idle memory usage after the tests. Both are easy to measure, but neither is particularly useful. Idle memory usage, similar problem to disk usage, and so the numbers aren’t usefully comparable. Peak memory usage is perhaps surprisingly the more useless of the two, because the increase in memory usage is strongly correlated with how many requests are being served at once—and so a slower contestant might artificially use less memory than a faster one; and so if you wanted those numbers to be comparable, you’d need to throttle requests to the lowest common denominator, which could then be argued as penalising light memory usage patterns.
- vindarel 7y ago
  and here the author ports a Clojure program to Common Lisp with a x10 speed gain: http://johnj.com/from-elegance-to-speed.html http://johnj.com/from-elegance-to-speed.html. Sorry, x300.
deepaksurti 7y ago
>> they seem ... incompatible with such performance Might answer your question [0] [0] https://news.ycombinator.com/item?id=2192629 https://news.ycombinator.com/item?id=2192629
- chrismorgan 7y ago
  I don’t think so. My simple reading of things there is that that was for one particular micro-benchmark (and the Benchmarks Game is acknowledged to be unrealistic and not actually suitable for comparing language performance), that the results were not actually conclusive, and that it had required telling SBCL to do some stupidly dangerous things that you should probably never turn on on real software, because they may well make it behave catastrophically badly rather than just crashing when you have a bug. On https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... at present, the fastest SBCL implementation, which seems to include these optimisations, is at 2.0, with other SBCL implementations being slower, the first one (whatever that means) being 8.0; meanwhile, the Rust implementations range between 1.0 and 1.2. The SBCL implementations all use at least eight times as much memory as the Rust implementations, too. I think this demonstrates my point pretty well, actually.
  - armitron 7y ago
    The (micro)benchmarks game is a gimmick and should not be taken seriously. You forgot to mention that the SBCL #3 implementation also sits at 2.0 and is fully memory safe. I fail to see the reason for you presenting the facts in this manner especially the "stupidly dangerous things part" which is of course totally inaccurate. (safety 0) has its uses (e.g. like Rust unsafe). Your conclusions are not indicative of real world performance.
    - igouy 7y ago
      > … benchmarks game is a gimmick … What exactly is it designed to attract attention to? > … should not be taken seriously. Because? > … fully memory safe. Here's the problem, the programs are explicitly required to use function calls but: ;; * redefine eval-A as a macro
elamje 7y ago
I don’t know if you are wrong, but I would give fennel lang a look. It’s a lisp that compiles to Lua, so you can access LuaJIT performance while lisping away.
- didibus 7y ago
  I don't think OP considers LuaJIT high performance, considering lots of Lisps are just as performant as LuaJIT.
JohnStrangeII 7y ago
There is no conflict of goals, languages offer certain features, some of them offer only "zero-cost" abstractions (C++ and Rust) and others offer more abstractions. You get what you pay for in terms of runtime executable speed / features trade-offs. The other factor is the compiler toolchain - see below. If Rust had the same features as most LISPs have, then using these features would make Rust programs as "slow" as LISP programs. That is generally true for most programming language comparisons. What also matters for final executable speed is the toolchain, of course. Any languages that compile directly using GCC or LLVM and allows for compile-time typing will be roughly in the same ballpark. If they use their own compiler, such as Chez or Racket, then they usually don't match the performance, because there is not enough manpower in their teams to implement all those nifty optimizations GCC and LLVM have. SBCL is probably the fastest LISP with its own compiler. (Or Allegro?) To give an example, here are some CommonLisp features that Rust lacks: Full object system with inheritance and multiple dynamic dispatch, dynamic typing, hot runtime code reloading/recompilation, garbage collection.
- chrismorgan 7y ago
  You seem to be describing the effects of conflicting goals.
  - 13415 7y ago
    You mean trade-offs? The point is that every language and every implementation has them.
mark_l_watson 7y ago
I use SBCL to build command line applications. Reasonable enough memory use and very fast startup times. I for a while used to use Gambit Scheme for this but decided I like Common Lisp better. We no longer need hardware Lisp machines for good performance. That said, for some applications Rust is clearly better.
- neonate 7y ago
  Why do you like Common Lisp better?
  - mark_l_watson 7y ago
    I have so much experience with Common Lisp, starting around 1984 on my 1108 Lisp Machine. I have used various Scheme implementations a lot, but I just have more history and experience with Common Lisp. Both are great choices, and there are many high quality Schemes, plus Racket. Experiment, and then choose your own favorite Lisp.
- e12e 7y ago
  Do you have some examples you could share?
  - mark_l_watson 7y ago
    There is one in the new edition of my Common Lisp book https://leanpub.com/lovinglisp https://leanpub.com/lovinglisp You can read it online for free, and clone the github examples repo.
antisemiotic 7y ago
Not exactly lisps, but Carp (https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp) and Scopes (https://bitbucket.org/duangle/scopes/wiki/Home https://bitbucket.org/duangle/scopes/wiki/Home) might be worth a look. I haven't tried the former, and couldn't get the latter to do anything useful, though. (it looks like the author stopped responding to issues, sadly).
roryrjb 7y ago
I always thought that SBCL was considered high performance and for example Chicken Scheme compiles to C. Both might be slower than Rust but I always had the impression both of these were more performant than say Java, but I haven't used either in a meaningful way to really know how it would rate for your performance needs.
- cylinder714 7y ago
  Chicken's author also created Bones, a Scheme that outputs x86-64 assembly language. http://www.call-with-current-continuation.org/bones/ http://www.call-with-current-continuation.org/bones/ README: http://www.call-with-current-continuation.org/bones/bones.html http://www.call-with-current-continuation.org/bones/bones.ht...
- ska 7y ago
  SBCL is quite fast for a lot of things. I used to use it frequently for research projects that required performant code, and it generally wasn't to difficult to get within a factor of 2 of c code, though getting much closer could be hard. I haven't really kept up with it recently, but it regularly impressed me at the time.
alfiedotwtf 7y ago
Hey Chris :) I totally get you with Lisps and performance, but I was more talking about the beauty and elegance of code written in them. Algorithms written in Lisps seem to be pieces of art. And that's just Lisps... having a look at logic programming languages like Prolog and Mercury, it's amazing to see just how compact yet understandable an algorithm can be. They're beautiful! But as for performance, take a look at Mercury - its a declarative logic programming language with built in constraint solving, which compiles down to C, and its performance is great. We've rewritten some Mercury in Rust, and yes our Rust is faster, but not by orders of magnitude as you'd think.
- DickieStarshine 7y ago
  How's the editor support with Mercury?
  - alfiedotwtf 7y ago
    Not sure about other editors, but there's syntax highlighting for Vim in the repo, and mtags (ctags for Mercury).
aasasd 7y ago
I'm currently using a CPU-slow machine, and I've discovered everything is slow among the popular scripting languages, except Lua. I've thought JS has good startup time, but some of my Lua scripts that are doing file i/o finish faster than node.js does a ‘hello world.’ Lua is also very lightweight on memory, to my knowledge. I think it can even do true multithreading, via libraries. So, there's a Lisp on top of Lua―compiled, not interpreted: https://fennel-lang.org https://fennel-lang.org It's deliberately feature-poor, just like Lua: you use libraries for everything aside simple functions and loops. And it suffers somewhat from double unpopularity of Lua and Lisp. But it works fine.
- DickieStarshine 7y ago
  Have you looked at Julia?
  - MiroF 7y ago
    Julia is compiled to machine code, not interpreted
    - vanderZwan 7y ago
      That has nothing to do with how "lispy" it might be. Part of the compiler is implemented in femtolispe no?
      - MiroF 7y ago
        I suspect this does have to do with whether or not it is a fast scripting language, considering a language compiled into machine code is by definition not a scripting language. Sure, flag me, but my comment was relevant to the discussion.
    - fiddlerwoaroof 7y ago
      Many lisps compile to machine code too. Compilation vs. interpretation is a feature of an implementation, not a language.
SigmundA 7y ago
What if there was hardware accelerated Lisp?: https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
- agumonkey 7y ago
  a forth array cpu based lisp machine would be a fun toy
bachmeier 7y ago
"they seem at least somewhat incompatible with such performance" Lisp is for the other 99.5% of programming that doesn't require you to wring every last drop of performance out of your CPU.
nickpsecurity 7y ago
You can build a Lisp to stay close to the metal with zero-cost abstractions. Most people drawn to Lisp are wanting productivity instead of max performance. Besides, the commercial Lisps and fastest in FOSS are really fast. There was a systems type of Lisp called PreScheme that was closer to what you're envisioning. Carp also aims at no-GC, real-time use. Finally, ZL was C/C++ implemented in Scheme with both their advantages compiled to C. Although done for ABI research, I've always encouraged something like that to be done for production use with tools to automatically make C and C++ library bindings. https://en.wikipedia.org/wiki/Scheme_48 https://en.wikipedia.org/wiki/Scheme_48 https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp http://zl-lang.org/ http://zl-lang.org/
tambourine_man 7y ago
After JavaScript’s success, I’m convinced any language can be made fast given enough time and money. Some languages are easier to be made faster, but I think JS almost proves there’s no such thing as a language incompatible with high performance by design. You’d be hard pressed to conceive a more dynamic language and here we are, with crazy fast performance through many JIT tiers, interpreters, compilers, each of which would take years for a bright engineer to understand.
- chrisseaton 7y ago
  JavaScript is an extremely small, well-defined language with relatively simple semantics and very limited metaprogramming. It’s not a challenge compared to something like Ruby.
  - iLemming 7y ago
    When was the last time you looked at it? Javascript is not small anymore. ECMAScript specification is over 800 pages, only a few hundred pages smaller than Java's.
    - chrisseaton 7y ago
      > When was the last time you looked at it? I’ve read the latest version of the specs of all these languages in detail. I’ve worked professionally on a team implementing Ruby, the latest version of JavaScript, and Java at the same time, using the same language implementation system, so I can directly compare. JavaScript is simplest by far. There’s quite a lot of sugar now, but the core semantics are small and simple. The core semantics of a language like Ruby are an order of magnitude more complicated.
iamwil 7y ago
There's a post about the three tribes of programming. https://josephg.com/blog/3-tribes/ https://josephg.com/blog/3-tribes/ Tribe 1: You are a poet and a mathematician. Programming is your poetry Tribe 2: You are a hacker. You make hardware dance to your tune Tribe 3: You are a maker. You build things for people to use alfiedotwtf falls in the first tribe. You fall in the 2nd. Different tribes have different values, and hence all the back and forth.
- dkarras 7y ago
  What if I'm kind of all of them? Eternal damnation? I've always strived to write beautiful code - for things people find very useful - in ways that push boundaries for what people think is possible with the machines we use. I have succeeded in balancing any two of the above, to terrible detriment of the third. Never been able to juggle the 3 at the same time and this bothers me a lot. The upside is this pushes me to learn a lot, downside is I'm never content with my craft. I'd have loved to solve domain specific important problems with a domain specific language I craft with a LISP and have state of the art performance while doing so.
- kirillzubovsky 7y ago
  Love this distinction. Makes a lot of sense, and is probably a key to happiness, to both realize which tribe you're in, and whether you're trying to argue with the tribe with another set of principles.
- alfiedotwtf 7y ago
  I like this :) Programming is my poetry. Damn... that's a nice take
vindarel 7y ago
Some pointers: - how to make lisp go faster than C: https://www.reddit.com/r/lisp/comments/1udu69/how_to_make_lisp_go_faster_than_cpdf/ https://www.reddit.com/r/lisp/comments/1udu69/how_to_make_li... - https://github.com/marcoheisig/Petalisp https://github.com/marcoheisig/Petalisp "Petalisp is an attempt to generate high performance code for parallel computers by JIT-compiling array definitions. It is not a full blown programming language, but rather a carefully crafted extension of Common Lisp that allows for extreme optimization and parallelization."
sedachv 7y ago
The issue is memory management. Henry Baker helped popularize linear types in the early 1990s (http://home.pipeline.com/~hbaker1/ http://home.pipeline.com/~hbaker1/) in his proposals for Lisp, from which work Rust's affine types derive, but no one wants to write in a dialect with those restrictions. Garbage collection seems like an algorithmically insurmountable problem. The other overheads are constant time, and Common Lisp already includes mechanisms to optimize them away (declarations and efficient arrays).
didibus 7y ago
You may be wrong in thinking all programs require maximum performance? I just find your question a little confusing. My house is only two floors, yet meets all my needs. A bigger house would just waste my time in cleaning, cost me more in maintaining, in heating, etc. It's the same for programs. Target performance at all cost, and for a lot of programs you get a hard to maintain, non scalable, bug ridden, featureless program that took you way too long to build. That's why for example I use Clojure and Rust. Rust gets the least use, because the programs I tend to write can manage fine with Clojure's performance. In fact, I mostly toy with Rust, because I really never needed to write anything higher performance. So I'm just not sure what you mean. The world is full of useful programs that meets the needs of their users which aren't high performance. For all these programs, Lisp is a superpower.

agumonkey 7y ago

10 years after college I finally understood the lisp, ml, prolog ladder mainstream world is damaging to my soul

alfiedotwtf 7y ago
I know right :O

braythwayt 7y ago

A major mistake is thinking that Lisp itself is magic. The magic is actually in how Lisp changes the way you think.

alfiedotwtf 7y ago
No, no... that's exactly what I meant :)

throw_xyzyz 7y ago

Guile + guix. I work in devops and that replaced a horrible mess of god knows how many containers with a straight forward, boring and reproducible single large instance of Guix SD.

partdavid 7y ago
I'd be pretty interested in reading about this work. Do you have a blog post or any code you can share around this case study?
- throw_xyzyz 7y ago
  No, I find the current climate of online discourse too vindictive and narrow minded, hence the throwaway accounts. I've scrubbed as much of my presence from the internet as I could because of that. I'm toying with having something in Freenet or some even more user unfriendly format so I don't have to deal with idiots with a grievance getting me fired.
deleted 7y ago
[deleted]
dexterlagan 7y ago
Very interesting. I played with Guile a while ago and came back impressed. I'd love to hear more about your work.
- throw_xyzyz 7y ago
  What it says pretty much, used Guix to replace a bunch of containers people had set up and needed to be coordinated on the network. The only reason why they were using those was because the other devs were on Windows/Mac and couldn't run the software natively. The rest was boring details about getting the right version of the jvm running using shepherd instead of systemd, which I liked a lot because it wasn't systemd.

breck 7y ago

I just read Fibonacci's Liber Abaci (from 1202). I think I'm not too far off the mark if I say Lisp in our day is what the Indian numeral system was in Fibonacci's day. A new writing system that has significant practical advantages.

dang 7y ago

> fast forward a decade later and I'm reading books on functional and logical languages for work What work has you doing that?

alfiedotwtf 7y ago
I work at a wonderful company called YesLogic, and we try our best to do PDF generation. Mercury works wonders against all the constraints that CSS rendering can throw at us.
- zem 7y ago
  if you have any blog posts about that up i'd love to read them!
  - alfiedotwtf 7y ago
    Can't say when, but we're planning on blogging about it in the near future. You'll most likely see it on "This Week in Rust" :)
    - dang 7y ago
      If you want to, you can email a draft to hn@ycombinator.com and we might be able to give some tips on what the HN community tends to respond better to. Same offer goes for anyone who's working on something they hope will interest HN. Just don't be disappointed if you don't hear back for a long time—and as a corollary, don't send it just a couple days before you plan to publish. We have terrible worst-case latency!
      - alfiedotwtf 7y ago
        Awesome, thanks for that!