Cool to see that after Cotowali was sadly abandoned due to lack of funding. Please, fund the FOSS projects you use!

Still don’t get why Go simultaneously picked this and introduced defer

Still shame they didn’t pick it for desktop and we had to wait years for a quality alternative client like Flare.

deleted by creator

This. I can’t count HOW MANY FUCKING TIMES I had to either look up the source code or search GitHub for code using a function from a given library because the documentation was so laconic and/or disjointed.

I mean, libraries access is good. But lack of tail call optimization support is not something you’d want in a functional programming language runtime. Luckily here Clojure somehow manages to fare better than Scala.

Clojure. Although it’s currently the most popular lisp but the ecosystem is not super lively and sometimes you need to rely on Java interop. This also severely limits the platform flexibility, if more things were written in pure Clojure or targeting BEAM or CLR it’d be nice. But luckily at least unless a library you use doesn’t rely on Java interop, the language is designed in a way that really reduces the bit rot.

Fun thing about it is that despite the S-expressions which you love to appreciate - I mean, it usually looks better than }) at the end of a Promise / closure in js or super deep nesting which you’d easily resolve using a thread last macro in Clojure. Therefore I’m also really excited that the pipe operator is finally coming to JS soon. Just add colored delimiters to your IDE. The virtual lack of syntax makes it quite easy to pick up.

With lisp semantics and minimal syntax that resemble the lambda calculus very closely, dynamic typing is rarely an issue (you can still specify types optionally), not to mention that pure functions are super easy to reliably test. Also, many things like DOM, nested data structures, b-trees (to a degree) or ASTs are actually structured like an S-expression tree, making Clojure good for such applications. All of this allows for clean code that does not feel like an assortment of free functions but is usually very loosely coupled yet everything seems to fit really neatly together like a coherent tree.
In general LISPs, as the name implies, are a superb tool for studying algorithms and DS in a way that allows you to focus on the problem itself more than the implementation, unlike in imperative languages where going into every little step in what feels like almost operating at individual CPU instructions at times can feel overwhelming and confuse the hell out of you.

Realizing the open-closed principle with Clojure comes pretty naturally since you’d more likely use function composition or write new transformations than modify the existing functionality.
Since functions are the primary unit of abstraction, dependency inversion is also trivial to adhere to.
Also protocols, which are somewhat more powerful than interfaces in some OO languages. They offer multi-method dynamic dispatch, retroactive polymorphism (extending types defined outside the current codebase), are independent from class hierarchy and are generally somewhat more succinct as virtually everything in that language.

First-class support for STM and immutability also make it good for concurrency like most functional PLs and make it a bit more intuitive than the actor model of Elixir/Akka.
Some Clojure frameworks do as well in certain benchmarks as those written in Rust.
Also compared to some other lisp dialects, the “primary” data structure is not a singly-linked list.

It’s goto data representation format, EDN is also a really nice thing.
And you have a REPL and get to choose what should be compiled AOT and what JIT. It’s most popular build tool, Leiningen is quite neat and in my experience has been a little bit faster in terms of dependency retrieval than Mix used by Elixir.

It can also transpile to js or dart. It generally is a quite flexible and extensible language where the said extensibility does not really make you feel the levels of inconsistency comparable only with PHP a couple years ago before they’ve decided to get it’s shit together as much as possible as can be the case with Haskell codebases that rely on a large number of language extensions.

And lastly, first-class documentation support but that should be a standard (looking at you JS and everything that still uses Doxygen)

Tbh Clojure’s greatest Achilles’ foot is the baggage of JVM with it’s lengthy stack traces, startup time, lack of tail call optimization, different paradigm and backwards compatibility issues. So if the question was which runtime you wish was more popular, I’d pick BEAM. But in it’s current state, whilst BEAM is more suited for functional programming, Clojerl doesn’t allow you to do much more than the standard library since many libraries wrap java, like web frameworks for example.
But on the other hand, JVM integration might make it easier for teams using Java or Scala to adopt Clojure.

Also it might not do the best job of handling bugs gracefully. This is good in the sense of giving you those almost Rust-like levels of strictness but without the lengthy compilation time but if you are looking for a way to move fast and tolerate some breakage, Elixir could be a better pick.
Also currying is not automatic and you have to use partial or macros.
But speaking of macros, they are almost as neat as in Rust and much more intuitive than in C or Scala.

thought Saint Terry A. Davis already pointed out what actually is the hardest problem in CS

lmao imagine allowing to run your software only on RISC-V boxes basically, pretty based but also a shoot in the foot in terms of acquiring any major funding

Go with the Fiber framework will probably offer you enough performance https://www.techempower.com/benchmarks/#hw=ph&test=composite&section=data-r22

attempting to build a database normalization checker up to 4NF. Also forking some Spotify client and modifying it to work with the Soulseek network has been in my bucket list for a long time

impure functions and their consequences

I don’t think you need a better PC

This will hold true as long as OP doesn’t trash his IDE’s performance with too many plugins where even smaller project might run into performance issues if this mistake is made. But it doesn’t mean OP has to distract themselves with learning a modal TUI editor, although it’ll probably be beneficial for their productivity if they persevere and better to do that early than waste time hopping IDEs just for the sake of it. Tip for staying somewhat flexible if you still haven’t decided yet is using something like vim plugin to vscode or vice versa, trying Neovim “distributions” (see awesome Neovim for some examples) and switching to a more feature-rich, GUI-based IDE.

Why not gitignore the build artifacts and either publish them with releases or include a build directive in makefile/justfile? I mean, your platform might not be someone else’s. Also consider using less global variables and shortening your main() in favor of dedicated functions ( that can still run in a loop inside main()) and using shorthand := assignment. Otherwise good job with documenting your code well.

PS, this one’s more of a marketing tip really: try including a GIF in README.

Same. Shame though they may still probably have the audacity to use mirrors for non-consensual copilot training.