Correct me if I'm wrong but a big part of the value proposition these days for Erlang/Elixir would be that it comes build in with a lot of the tools that other runtimes would require. For example a message bus is kinda integrated in the BEAM runtime or Erlang, while most other runtimes would have to use something like Kafka or AWS SQS etc. Or caching and some other things. Of course I'm not sure how good all the inbuilt solutions are compared to dedicated tools, overall or usually IMHO I prefer dedicated tools as opposed to all in one as the dedicated tools/services usually are more flexible. On the other hand of course it is also much overhead.

> a message bus is kinda integrated in the BEAM runtime or Erlang

You have that on a single node. If you need to run more than one node, you will end up inventing your own on top of mnesia and usually the results are not spectacular or/and you will end up paying happihacking to do it for you. Or one of the other Erlang oldtimers who you can count on the fingers of your hands.

This is really suboptimal compared to what you can achieve by using any normal language + any message bus. You are actually much better using a proper message bus even if you use Erlang.

Problem with Hare is that it is (or at least was last time I checked) Linux/Unix only and so by design. That kinda makes it DOA for many.

Indeed. There’s a port for macOS though.

And yet out all these newer C-like languages, it looks like Hare probably takes the crown for simplicity. Among other things, Hare uses QBE[1] as a backend compiler, which is about 10% the complexity of LLVM.

[1] https://c9x.me/compile/

The downside of QBE is that it then requires an assembler and a linker. And QBE's only input and output is still text.

Plus the "frontend -> QBE -> assembler -> binary" process is slower than "frontend -> LLVM -> binary". And LLVM is known for being a fairly slow compiler.

The downside of QBE is that it doesn't have a way to generate debug symbols. But I still love and use it.

The most recent release has the ability to generate basic debugging information (see "new experimental dbgfile and dbgloc directives. " from the release notes) as Hare needed that (and IIRC a Hare contributor added it). Unfortunately, there's no documentation on it, and last I checked to see how to use it I had to go spelunking in the Hare source code.

It's funny how they say they are at 10% of the code of LLVM in their marketing, when it is actually closer to 0.1%. Throwing LLVM version 20.1 through wc (just the subdirectory llvm/lib) results in 2.3 million lines for all .c and .cpp files. QBE was around 14k last time I checked.

QBE is an art project. Read the source.

I tried. It's not at Arthur Whitney's levels of terseness, but compared to the source of, say, Redis it's a pain to read.

That and no multithreading.

I think it is way simpler than that. IMHO, for many people young or old the value proposition of emacs simple is no longer there and/or worth the huge learning curve. For most things people would use something like emacs the alternatives are simple good enough and some cases better. By better I mean mostly more accessible, less complex and with a better ecosystem. One tool that does all, also simply does not resonate with everyone nor do many people feel the need to make their almost their lifestyle (not saying you do, I'm speaking in general to the Emacs runs my life folks). Another thing to consider often is that when working in a group or team at work for example it can be the easiest path forward to use the tool the company officially uses and your teammates do. If your team uses for example slack to communicate why go through the hassle of setting up some most likely cumbersome workaround to target it via emacs instead of just using the slack.

My team does use Slack app and I use it too. The point is not to do "everything in Emacs" because you love that so much. The point is that when plain text is the main medium (and for majority of tasks we deal with daily, it is), then using text-oriented tools can give you certain edge.

When communicating over Slack my colleagues would send me a ticket number in Jira or a link to some code snippet on GH. When I have to share the same (or similar) stuff — I can easily provide the exact link to the ticket, with its description, I can quickly retrieve some relevant data from that ticket, if I'm adding some notes. When I'm sharing a link to a code snippet, I can easily retrieve the fully-qualified namespace and the name of the function, so the url is not some arbitrary incantation that my teammates have to guess about before clicking on it — it contains the exact piece of information they may like to see even before opening it.

When someone shares 'some incantation' with me, I don't even hesitate — I delegate the task to Emacs, and it is smart enough to recognize that a piece of plain text like "XYZ-146" is a Jira ticket, that "RFC-6364" is a document, that a github url is a link to a PR — with a single keystroke I can browse the jira ticket, read RFC document, explore the changes in the PR. I can invoke an LLM on the spot to summarize the points of the RFC document, to give me some insight to add a comment to the PR review.

All that without a hassle, all that done with simple keystrokes, all in one place. I can easily copy relevant information into my notes, I can grab stuff from my notes and share with my colleagues, easily converting Org-mode markup into Markdown without even blinking. The flow is there. And that flow also contributes to the general well-being of my teammates. I can assure you, they are happier with me using Emacs, even though most of them don't even know anything about it.

> the value proposition of emacs simple is no longer there

My main point from the get-go was that most people don’t even realize what a ‘value proposition’ there is.

All fair. I suppose my point is that I think people do actually have a decent sense of what value proposition there with emacs but simply don't agree that its strengths are worth the steep climb and or a the much better that their current tool needs replacing.

Are you comparing Elixir with a framework as extensive as Phoenix to Go and "just" its standard http library? If so I'm not sure that would be a good comparison then.

No, you could import a full-blown framework and have it set up within one single file, in fact, that is how you usually start, typically... Unless you like having lots of files, of course. I have used such Go libraries / frameworks before, and it all started out as a single file, but with Phoenix, you start with lots of files. I am not saying it is a bad thing, I am just expressing my preference to fewer files. Organization and modularity are great, but in the case of Go, I create the files myself (so I am more aware of everything that is going on). In case of Phoenix ("mix phx.new"), it is done for you. Again, not saying it is a bad thing. I am fine with it by now, but it was overwhelming and demotivating in the beginning, as opposed to, say, Go.

To some vscode probably is good enough and that is OK. I don't see why this would be an issue.

This is an issue become the some don't know better.

Or they simply think or know that vscode does what it needs to, for them to get the job done. In the end the best tool is the one you can be productive in. No need for gatekkeeping about something as trivial as ones preferred editor or IDE.

To be fair the importance for devs/programmers to touch type is often very exaggerated. Not saying it is not a benefit but is is far from a "must" or something that is a detriment to producing quality work. In the days where secretaries were typing out memos from their boss touch typing was much important or needed.

I am likely bad at what I do, and am not a real developer, instead being someone who just uses "code" to look after infrastructure (or at least I was.)

I never felt a need to punch things out so efficiently that minute differences in time spent on or off keyboards, or my touch typing speed matter. Most of my time that consumes the budget allocated to me is honestly spent in researching and thinking. Once I get to writing the code, sure I could shave down the time to implement it by a few minutes each time, but its not enough for me to care about honestly.

That being said, I do use vim, but only because I was at one point a junior systems administrator and my CTO demanded to know why I was not already using it and instructed me it would be good practice to do so as its installed on everything we ran and so...vim it was. Not for efficiency, or because it empowered me but instead because it was there.

Now that I do more busy work instead such as discoveries, PIR's etc, sure my touch typing speed matters but its very different work.

I mean it depends what one use Vim or their editor of choice for. For example I do think that efficiency gains when for example developing in Java are marginal if there at all. Or for people who do not hate the mouse, or people who can't touch type and probably many more examples. Also with how integrated vscode is these days, it is no surprise that many prefer it.

What real world application is there, where in 2024 Lisp(s) is the definite better tool vs the dozen of established languages that are used in its place. Yes, technically Lisp is also established but still. Besides that I also think that Lisp has a readability problem similar but not severe of course as APL for example. And of course just like APL part of that is familiarity but that is only part of it IMHO.

To be fair some of these are subjective. People of course should never sell their opinions as objective or facts. Which btw, I don't think the person you responded to did.

You invented all those quotes and then argued against them. I said none of them. It's probably not your intent but it feels like you are coming after me angrily with these long text responses.

I'm not coming "after you." I'm sorry if you feel attacked, and I apologize if you think I'm angry. We're in a public forum, and I'm simply expressing my opinions (for everyone to see and read). They are not specifically aimed at you or in response to what you've said. This particular comment wasn't even a response to your comment; it just happened to be in the same thread.

As long as most Lisps and Schemes rely so heavily on Emacs as part of their tooling, it will never reclaim its status from its heydays. Emacs is just too clunky in 2024. Just IMHO of course. Also Common Lisp, while a great lang with fantastic implementations such as SBCL, really do need a better or standard packet manager, Quicklisp is a great effort but still in beta, and saying "well it is technically still beta, but basically ready or good for use" is simply not cutting it. Quicklisp also still, as far as I know, does not do https and the communities opinion on that seems rather "oh well" on it. I guess where I'm going at is that Lisp's tooling has some serious limitations or gaps compared to most modern languages.

> Emacs

For plugins for Vim, Atom/Pulsar, VSCode, Jetbrains, Sublime, Jupyter notebooks and more see https://lispcookbook.github.io/cl-cookbook/editor-support.ht... they have very good to good and improving support.

> Quicklisp

see https://github.com/rudolfochrist/ql-https

a new package manager: https://github.com/ocicl/ocicl

and also https://www.clpm.dev or Nix, Guix.

> Emacs is just too clunky in 2024

Believe me, you couldn't be more mistaken. Modern Emacs offers virtually unlimited ways to provide a smooth, graceful experience for so many tasks, sometimes in completely unexpected areas.

I just watched someone show me a way to integrate YouTube. It allows you to subscribe to channels and playlists, automatically fetch new videos, and watch them directly within Emacs. One feature that blew my mind is the ability to follow video transcriptions alongside the video, karaoke-style, providing an enhanced, distraction-free experience in a more interactive and engaging manner. You can not only search through the content of videos but also jump to any point. I have never seen a better way of consuming useful information from videos.

That's why I said IMHO. I tried Emacs in 2023 and 2024 and to me it is still way too clunky, gets in my way all the time and has , what I consider, bad defaults and to me very bad ergonomics. It literally negatively impacts my hands. And performance was nothing special either for me. It is however very powerful, I agree with that.

I don't know what to tell you. I myself never got into Emacs on the first try. It took me about two years of constant debate and deliberation. At that time, I was using IntelliJ and had been for seven years. I knew it extremely well and was very happy with it. Yet, seeing what’s possible with Emacs continuously fueled my curiosity. I was annoyed by my own inability to finally understand what makes it so great. Little by little, I started finding features and packages that were awesome, but I still kept stumbling on other roadblocks that ruined the whole experience. At some point, instead of blindly copy-pasting Elisp snippets, I tried to dissect and understand them and had a few aha moments. Finally, one day, I decided that instead of reaching for the tools I knew well already, for every problem at hand, I would try to figure out how to get it done with Emacs. It was very slow at first, but after a couple of weeks, I felt more productive than I ever was with other tools. A few months later, I received a notification about having to extend my IntelliJ license, and I realized that I didn’t need it anymore.

Emacs is extremely empowering, although it comes at a cost, even though technically it is free. For some people, including myself, that time is the best lifetime investment. I have never regretted the time and effort I spent learning it. Even with the plethora of features that constantly get added to VSCode, I have zero FOMO. I do occasionally fire it up just to make sure I don't get stuck in my bubble. Once you understand how advising functions work in Emacs and realize that you can redefine any behavior of any function, whether third-party or built-in, it gives you incredible authority over absolutely any textual data you have to deal with on your computer. Check this out: I can perform a search that looks for things on Google, DuckDuckGo, Wikipedia, my browser history, and other sources (this is customizable). Then, I can select any given url and send it to an LLM to extract a summary. After that, I can create a note with a deadline and schedule to review it at a specific date and time, or add this stuff to my Anki cards collection. All that without ever leaving Emacs, and with just a few keystrokes.

If you ever feel curious about it again, maybe try Doom Emacs. Who knows? Maybe this time, it will be different.

Again I agree that Emacs is powerful and can be an excellent tool. Never disputed that. But it still, again, to me is clunky. I dislike its defaults, its interface, the ergonomics. Also I have no use for many of its offerings. Could I configure it to something I find tolerable, I could but to me the return is simply not worth it. I simply would use emacs as (sourcecode) editor and for that other offerings provide me with what I want and need with only a fraction of the cost and investment needed and my hands thank me to boot. I tried Doom Emacs (and Prelude and Spacemacs) as well, it just made realize I could just use neovim if I wanted vim bindings. I tried Emacs and gave it an honest go multiple time and simply did not like it or like it enough to invest further into it. The alternatives for me simply do better job for what is important to me. And just like you I have zero Fomo with my decision.

Ah, yeah, the pace at which Neovim is developing actually makes me more envious than the VSCode world. One can use Fennel to configure it and probably get the REPL running, getting very close to how Emacs operates with Elisp. To be honest, if I didn't already know Emacs and had to choose today between Neovim and Emacs, I'm not completely sure which way I would go. I've been using Vim for a long time, and the advancements in recent years are pretty awesome. My Neovim config is minimal because I know Emacs too well at this point to try scratching the itch and build some sophisticated config, but maybe I should give it a try at some point.

I don't think neovim is as strong as emacs when it comes to extensibility. It also has no self documenting like emacs. If one is committed to the philosophy of using emacs for everything or almost everything neovim would probably leave one wanting. I do agree however it has come a long way. It is good there so many strong options these days. And I will cede one thing about emacs and vim (neovim). They most likely still be around after whatever next big editor replaces vscode.

If you do try neovim again maybe check out (in case you may have not heard of it) https://github.com/Olical/conjure It was (is) pretty nice last time I used it.

Yes, I know about Conjure as I am a relatively frequent user of Fennel. One of my projects was, at one point, the third or fourth most starred Fennel project on GitHub. Thank you for reminding me about it; I may decide to borrow some ideas from it, as I'm finding more and more cases where Lua is used. The latest revelation is that mpv can be extended with Lua, and I just found out about it. I jokingly call Fennel "the best formatter for Lua code; it makes your Lua look much nicer..." :)

Thank you once again. I tip my hat to you, my fellow vimmer, as another die-hard vimmer who, quite amusingly, happens to be on Emacs.

Thank you, too for the friendly discussion.