I don't see how this brings anything new to the ecosystem. Clojure is a LISP and we already have lfe (http://lfe.io/) - LISP floured Erlang for quiet a while now, hence it will definitely be more mature than a new implementation altogether. Moreover I feel, seeing the the currently more effort should be made in maturing the classic clojure implementation and the tooling around it itself, rather than diverting the community into fancy new (not so useful) ports of the same syntax for other runtimes. Seriously, just go improve clojure itself. And if you want to be able to write lisp for BEAM, just use lfe.
A quick plug for LFE and its very simple premise: in mortal fear of Rails, I embraced the potential of Elixir (with 100% more Phoenix); I had a wonderful test case for macros (can't even remember what it was anymore); I spent hours trying to craft it and fought, fought, fought the AST/syntax/complexity; finally, in anger remembered the mere existence of LFE and its promise of DEFMACRO.
I wrote my first vaguely non-trivial LFE program as a macro in the REPL as a guess, and it worked on the first try.
If I need a lisp in BEAM, I would run with LFE on that alone.
I don't think this implementation harms either Erlang or JVM clojure ecosystems. I also doubt the creator of this has as much interest in maturing JVM tooling as you so demand of them, if they did, they wouldn't have made this port.
If this is inferior in every way to lfe then it will remain a niche project. If not, perhaps it will encourage some improvements either in lfe or Erlang itself (though I think the latter is unlikely).
More to the point, Clojure is in 2020 the only Lisp that matters. If ypu want to develop a Lisp that attracts the attention of people who work on things that make actual money, your best bet is to port Clojure.
the only major difference I see between what you're calling 'clojure' and a lisp is that clojure compiles to JVM. That alone goes for a toss when you say you're porting it to BEAM. There is no more java in the equation. Its interop with erlang/elixir ecosystem. Which is exactly what lfe is (apart from some minute differences in syntax which may or may not be there).
Don't know why but the post doesn't mention Ingress resources when it comes to exposing and load balancing your services. It is a much better and official way then that mentioned in the article.
> Commits often touch files for completely arbitrary reasons, so the last commit tells you almost nothing. I can’t think of any case when somebody would need that particular information
You sir are using git in a very wrong way it seems. Its not dropbox, you get to decide and see exactly what changed and why. Not just do a `git add .; git commit; git push`
I think I can see what the author meant. It's not about doing `git add . && git commit`; it's about things like changing the signature of a utility function and touching all files which use it. Such a commit arguably doesn't tell you too much about the file itself. I disagree with the author that it happens often enough to make the "last commit which touched this file" not useful, though.
I think it would be safe to assume that the author knows pretty well how to use git and github: https://github.com/tonsky/
Probably, while his own commit messages seem to be consistent and informative, he spent too much time looking at repos of other people, where it is not so.
Since I frequently have the same feeling when exploring potential dependencies for my projects, so yes, changing the Github UI to accept the status quo seems more logical for me, than trying to reeducate all the developers in the world to follow the universal guidelines for commit messages sensibility.
Well I found this video by vice https://www.youtube.com/watch?v=jhXaM_r80_c which claims that they found the source in zug island across the river, but were not allowed to investigate further due to cross-border politics.
