<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: rvirding</title><link>https://news.ycombinator.com/user?id=rvirding</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Thu, 23 Apr 2026 10:41:19 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=rvirding" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by rvirding in "Lua for Elixir"]]></title><description><![CDATA[
<p>The reason for calling it Luerl was that it was/is an implementation of Lua on Erlang. It is Dave who has been working with a more serious Elixir interface. The original one, which still exists, had a very simple Elixir interface module which just flipped the argument ordering to calls to be more Elixiry in feel.</p>
]]></description><pubDate>Mon, 19 May 2025 14:25:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=44030256</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=44030256</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44030256</guid></item><item><title><![CDATA[New comment by rvirding in "Parallel garbage collection for SBCL [pdf]"]]></title><description><![CDATA[
<p>I would be very interested about the architectural possibilities of the BEAM you mentioned. Also the speed of the BEAM is not as bad as is often mentioned, definitely not when you start looking at problems/tests with lots of inherent concurrency. Also the sequential speed has markedly improved with the new ASMJIT.<p>Also problems with GC basically don't exist when running Erlang/LFE code, at least you have to put a lot of effort into getting problems with GC. A lot! And, of course, the BEAM does automatic load balancing over multiple cores which is another problem gone away. We never have to think about the class of problems like "I have my system set up to run on 2 cores, how should I modify it to run on 4?".</p>
]]></description><pubDate>Tue, 12 Sep 2023 14:25:57 +0000</pubDate><link>https://news.ycombinator.com/item?id=37481823</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=37481823</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=37481823</guid></item><item><title><![CDATA[New comment by rvirding in "Erlang: The coding language that finance forgot (2022)"]]></title><description><![CDATA[
<p>I think the thing to remember that it all started as an interpreter written in Prolog in which we could develop our ideas on what the real problem was and the right semantics of a system for solving them. As we went along our "language" evolved as well and became less and less Prolog and more functional as we removed much Prolog semantics, added functional "stuff" and developed the final syntax.<p>We had along the way also looked at concurrent logic languages. So by the time we had a language and design rules how to use it most of Prolog had disappeared, though some of its syntax still remained. This language was, of course, Erlang.<p>While Prolog was a nice base on which to develop our ideas it was never the language we would have used in real life.</p>
]]></description><pubDate>Thu, 02 Feb 2023 15:00:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=34627377</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=34627377</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=34627377</guid></item><item><title><![CDATA[New comment by rvirding in "Erlang's not about lightweight processes and message passing"]]></title><description><![CDATA[
<p>OTP came much later than the design of the language.<p>The language was designed around our I ideas of what the problem really was and the best way of solving it. The massive and extremely lightweight concurrency were a critical part of attacking the problem which was/is extremely concurrent. There are an enormous number of things going on in a switch which have to be handled concurrently, sometime over 10k calls plus running the switch. So the concurrency was fundamental. The error handling primitives were of course also a a critical part of the solution as fault tolerance was a critical part of the problem.<p>A lot of effort went in to working out what the concurrency and error handling should look like to be right for how to attack the issues and solve the problems. Fortunately we worked with a user group looking at designing a new architecture who tested using our ideas and came with extremely important feedback on the ideas, what was good or bad or just not necessary. They then became the first group to build a product using Erlang. It didn't use OTP as it didn't exist then.<p>OTP came later and is “just” a formalised, generic wrapper around these ideas. We had client-servers, state machines and the equivalent to supervisors in products before OTP was developed. Behaviours came with OTP. And in the beginning there were many different versions of OTP alive at the same time.<p>Behaviours could not have been developed as they are without lightweight processes and communication. OTP is of course fundamnetal to the distribution and use of the language as it does encapsulate most of of our original ideas in how Erlang should/could be used to build systems.</p>
]]></description><pubDate>Sat, 28 Jan 2023 16:11:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=34558745</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=34558745</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=34558745</guid></item><item><title><![CDATA[New comment by rvirding in "Lisp-Flavoured Erlang"]]></title><description><![CDATA[
<p>I am not really a fan of clojure and I much prefer the Erlang concurrency model to the options that clojure gives you. I don't agree with Rich Hickey here. And I prefer classic lisp syntax to clojure syntax.<p>But clojerl does give you the chance to run on a better VM so in that respect it is good. ;-)</p>
]]></description><pubDate>Thu, 06 Sep 2018 12:13:58 +0000</pubDate><link>https://news.ycombinator.com/item?id=17925653</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=17925653</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=17925653</guid></item><item><title><![CDATA[New comment by rvirding in "Lisp-Flavoured Erlang"]]></title><description><![CDATA[
<p>I am a big fan of Prolog and concurrent logic languages as well.</p>
]]></description><pubDate>Thu, 06 Sep 2018 12:10:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=17925632</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=17925632</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=17925632</guid></item><item><title><![CDATA[New comment by rvirding in "Lisp-Flavoured Erlang"]]></title><description><![CDATA[
<p>Well, I do of course see the beauty of the Erlang language; it is a simple, concise and consistent syntax. However, I also like Lisp being an old lisper. Lisp was actually the first high-level language I learnt. So LFE is an attempt to get the best out of Erlang and Lisp, at the same time.</p>
]]></description><pubDate>Thu, 06 Sep 2018 12:08:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=17925623</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=17925623</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=17925623</guid></item><item><title><![CDATA[New comment by rvirding in "History of Lisp (1979) [pdf]"]]></title><description><![CDATA[
<p>No, I did not know of Scheme's original goal, and we had never heard of the actor model when doing Erlang. And we wouldn't have cared either. :-)</p>
]]></description><pubDate>Tue, 28 Aug 2018 18:49:02 +0000</pubDate><link>https://news.ycombinator.com/item?id=17861676</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=17861676</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=17861676</guid></item><item><title><![CDATA[New comment by rvirding in "What's all this fuss about Erlang? (2007)"]]></title><description><![CDATA[
<p>Well, it's a skin on the rocket that will make it big. While they generally say that Elixir runs on top of the Erlang VM there happens to be a big fat Erlang/OTP layer in-between which Elixir and its libraries make full use of. This is just smart of course but not mentioning doesn't paint the whole picture.</p>
]]></description><pubDate>Tue, 24 Jan 2017 21:12:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=13475509</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=13475509</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=13475509</guid></item><item><title><![CDATA[New comment by rvirding in "Joxa – A concurrent, distributed Lisp"]]></title><description><![CDATA[
<p>Much of that blog/description is broken and it is not describing LFE as it is, or ever was in fact.</p>
]]></description><pubDate>Tue, 24 Jan 2017 13:57:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=13471288</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=13471288</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=13471288</guid></item><item><title><![CDATA[New comment by rvirding in "Languages on BEAM, the Erlang virtual machine"]]></title><description><![CDATA[
<p>No, they are the same, there is no basic difference at all.</p>
]]></description><pubDate>Tue, 24 Jan 2017 13:55:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=13471272</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=13471272</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=13471272</guid></item><item><title><![CDATA[New comment by rvirding in "Languages on BEAM, the Erlang virtual machine"]]></title><description><![CDATA[
<p>They are not only similar they are in fact the same. Elixir compiles down to Erlang and the Elixir libraries are built using Erlang and OTP "underneath". Also the the BEAM, the Erlang VM, is designed to run Erlang so it is difficult to make an efficient implementation of a language with different semantics on top of it. It is truly Erlang all the way down.</p>
]]></description><pubDate>Tue, 24 Jan 2017 13:54:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=13471263</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=13471263</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=13471263</guid></item><item><title><![CDATA[New comment by rvirding in "If I could amend PEP 8"]]></title><description><![CDATA[
<p>Yes "Indeed".</p>
]]></description><pubDate>Tue, 24 Jan 2017 13:48:39 +0000</pubDate><link>https://news.ycombinator.com/item?id=13471226</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=13471226</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=13471226</guid></item><item><title><![CDATA[New comment by rvirding in "Languages on BEAM, the Erlang virtual machine"]]></title><description><![CDATA[
<p>There are other languages, just read the reference.</p>
]]></description><pubDate>Fri, 20 Jan 2017 23:21:27 +0000</pubDate><link>https://news.ycombinator.com/item?id=13447758</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=13447758</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=13447758</guid></item><item><title><![CDATA[New comment by rvirding in "Languages on BEAM, the Erlang virtual machine"]]></title><description><![CDATA[
<p>I of course prefer either LFE or Erlang, they are much simpler, Elixir has a bit too much fluff for my liking.</p>
]]></description><pubDate>Fri, 20 Jan 2017 23:20:53 +0000</pubDate><link>https://news.ycombinator.com/item?id=13447754</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=13447754</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=13447754</guid></item><item><title><![CDATA[New comment by rvirding in "Show HN: A Travis CI Elixir client"]]></title><description><![CDATA[
<p>Erlang, and hence Elixir, was never optimised for raw computation, it's all about the massive concurrency (we can handle literally millions of processes), fault-tolerance and scalability. This is not surprising as no language is good at everything, you have to pick and choose what you is most important. In most systems different parts will have  different requirements so I think it is perfectly reasonable to use multiple languages in a system. Erlang is very good at communicating with other languages/systems.</p>
]]></description><pubDate>Fri, 13 Jan 2017 21:57:46 +0000</pubDate><link>https://news.ycombinator.com/item?id=13395074</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=13395074</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=13395074</guid></item><item><title><![CDATA[New comment by rvirding in "Erlang encourages poor Functional Design"]]></title><description><![CDATA[
<p>In many cases this article shows a lack of knowledge of how Erlang programs are written.</p>
]]></description><pubDate>Tue, 10 Jan 2017 09:39:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=13363737</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=13363737</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=13363737</guid></item><item><title><![CDATA[New comment by rvirding in "Programming languages that are actively developed on GitHub"]]></title><description><![CDATA[
<p>Actually the Elixir compiler does NOT compile directly down to the BEAM, it generates Erlang AST which is then passed into the Erlang compiler which then generates the BEAM code. So most of the compiler is in Erlang. It also uses a significant amount of the Erlang libraries as a base for its own libraries. So calling it 'mostly self-hosted' is stretching a bit.</p>
]]></description><pubDate>Mon, 09 Jan 2017 22:08:20 +0000</pubDate><link>https://news.ycombinator.com/item?id=13360264</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=13360264</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=13360264</guid></item><item><title><![CDATA[New comment by rvirding in "Lumo – A fast, standalone ClojureScript REPL that runs on Node.js and V8"]]></title><description><![CDATA[
<p>I just felt that as you can many functions with the same name but with different arities (number of args) at the top-level why shouldn't I be allowed to have it deeper down as well. Also this means that I can only <i>sometimes</i> refer to a function with just its name, when it is at the top-level you need need both name and arity.<p>This means that Lisp-1 doesn't really fit anyway so why let it limit you?</p>
]]></description><pubDate>Fri, 11 Nov 2016 18:12:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=12932869</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=12932869</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=12932869</guid></item><item><title><![CDATA[New comment by rvirding in "Lumo – A fast, standalone ClojureScript REPL that runs on Node.js and V8"]]></title><description><![CDATA[
<p>Actually no, it is completely different internally with different properties.</p>
]]></description><pubDate>Fri, 11 Nov 2016 18:09:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=12932853</link><dc:creator>rvirding</dc:creator><comments>https://news.ycombinator.com/item?id=12932853</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=12932853</guid></item></channel></rss>