Clojure 1.10 release (opens in new tab)

> The language has been designed by experienced and mature people and doesn't go through "let's throw everything out and start again" phases like so many other languages do.

Swift was designed by highly experienced and mature compiler devs and is notorious for making breaking changes. It's just a difference of opinion. I prefer to suffer the occasional upgrade pain in exchange for clean and consistent APIs. And I totally understand those who don't want to deal with that.

Although to be fair to them, Swift is much younger than Clojure and the number of breaking changes has steadily declined with each major release. In seven years maybe they will take the backwards compatible approach too.

Didn't Clojure change the + function (hardly obscure!) from automatically updating ints to bigints and therefore never overflowing to throwing an exception if you added ints that were too big?

I've got a Clojure book with a spirited defense of why it's good that the simple symbol + just does what you'd expect instead of throwing exceptions based on an implementation detail, and it kind of falls flat now.

I was a bit sad that the changelog was so small. Then I realized that maybe core features were stable and that's it, what was needed wasn't big beside spec and a few other things.

S-expressions are perhaps partly responsible as well. They don't suffer the same brittleness as regular programming languages (is there a word for non-s-expression languages like c/python/etc?).

Which languages threw everything out and started again?

Clojure's emphasis on backwards compatibility is commendable, but keep in mind Clojure is still a very young language ( only about 10 years old ) so there isn't much backwards compatibility to worry about.

I did a write-up that should give you an idea: http://insideclojure.org/2018/12/17/errors/

fwiw: https://gist.github.com/lsh-0/173f1a11e2e76f718c002607c8fa1e...

No need for Go, GraalVM already allows you to create a native binary:

https://www.innoq.com/en/blog/native-clojure-and-graalvm/

As fcurts below mentioned, [Graal's native image generation](https://www.graalvm.org/docs/reference-manual/aot-compilatio...) might be what you want.

It can turn a Clojure app into a single executable with excellent performance and memory characteristics.

You might be interested in joker (a small Clojure interpreter and linter written in Go) https://github.com/candid82/joker

The JVM supports AOT native binaries since the early 2000's, just not for free.

All major commercial JDKs have such support, e.g. PTC, Aicas, IBM J9, IBM RealTime WebSphere, Imsys, Excelsior JET.

Additionally OpenJDK has been integrating such support since Java 9 via Graal and GraalVM.

All you'd need is a Clojure to Go compiler. A simple matter of implementation (joking). The good news is that Clojure is relatively easy to tokenize and has a simple grammar. Go v1's lack of generics would make the implementation tedious, but the features announced for Go v2 should make it easier.

you might want to have a look at Joker (https://joker-lang.org/)

It's a Clojure dialect written in Go. Currently, its mostly used as a linter but you can also do programming/scripting.

I guess I might ask what this stance is founded on? The JVM is just a binary that runs byte code. It's stable and runs well pretty much everywhere. If you insist the JVM has cooties, you could use Docker and abstract it away, it might be an ideal way to use it anyways depending on your work.

The JVM /= Oracle JVM by the way. There is OpenJDK

EDIT: Also I think recent Java releases have gotten into making self contained binaries (which just means they package the JVM...it's in there, it might jump out and bite you!). But, as long as you are careful what you are shipping, packing up a JVM has always been an option

You can use GraalVM, I guess? But keep in mind that the code typically runs faster on the JVM.

https://www.graalvm.org/

Its often referred to as a guest language. The syntax is largely the same across JVM, CLR, and JS V8. The aim was to utilize the richness and reach of the most popular ecosystems, so all of Maven and npm are available to Clojure devs. The language should be able to be consistent across future runtimes with largely the same semantics.

There’s a CLR port if you really just hate the JVM ;)

Can do NodeJS with Clojure a’la Clojurescript as well

In what context are you trying to avoid the JVM?

You can do that yourself if you care (https://m.youtube.com/watch?v=zp0OEDcAro0) but I get what you mean. On the other hand, on a server application a REPL on exception wouldn’t help me.

> While I like the language very well, tooling does have issues, even simple things like not distributing Leiningen with Clojure when it is almost essential for any serious development. Version incompatibilities between Leiningen and Clojure creates subtle problems. I also wonder what the experience of using lein in Windows, it seems to install using a mysterious batch file.

Clojure bundles tools.deps since 1.9, and it works great. cljs and figwheel already supports it, as do many others. I prefer it to leiningen, but YMMW.

I use emacs to develop clojure, never had any problems with it :/

> Usage of local jars is extremely difficult, you need to setup a local maven repository and then add dependencies through it, which is a very painful process, esp for hobby projects and prototyping. I should be working on my problem not wrangling with maven.

tools.deps makes this very easy.

Actually, I haven't used leiningen in 6 months, Clojure's new included cli tools work great these days.