
Clojure 1.10 release - finalfantasia
https://clojure.org/news/2018/12/17/clojure110
======
jwr
From the perspective of a (fairly large-scale at this point) app developer: I
find it great that Clojure places such emphasis on backwards compatibility. In
general, migration to newer Clojure versions is completely painless.

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.

~~~
trevor-e
> 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.

~~~
jwr
> Swift was designed by highly experienced and mature compiler devs

"Compiler devs". I think that is exactly my point. I should have said "app
developers" or "system designers". If you listen to a Rich Hickey talk, you'll
see that he is all about Getting Things Done in the real world, and much less
about theoretical concepts. Language design is subservient to app developer
needs.

~~~
krn
I would put it simply: Clojure was designed by a _thinker_ , who creates when
he is away from the keyboard, not in front of it. When one releases and breaks
the code in his head first, very few breaking changes are left for the public
releases.

~~~
gavinpc
It takes one to know one. (Or so I would like to think.)

Rich's writing, presentations, and example of overall conceptual discipline
and maturity have helped me focus on the essentials in ways that I could not
overstate. I'm glad (but not surprised) to see so much appreciation for him
around here, even among non-Clojurists (like myself).

At the risk of fanboyism, I am _constantly_ referencing his ideas* to my team,
and I give them my blessing to watch any of his talks as soon as they come
out.

* That is, the old but sometimes obscure ideas whose importance he's brought to his audience.

~~~
starbeast
I made the mistake of showing the 'hammock driven development' talk to an
employer of mine. He got annoyed by it and said he thought that it was just
providing programmers with an excuse for staying away from the computer when
they should be writing code.

~~~
raspasov
Has he ever written code that was used in production and he was in charge of
the project?

~~~
starbeast
He became a project manager when he found he wasn't good at writing code after
becoming a coder when he found he wasn't a good physics researcher.

------
casion
The new error messages are fantastic. Clojure just went from one of the most
annoying languages to debug to mid-top tier.

More complex things still present you with overly complex errors, but with
some painless repl usage it's way easier to figure out things now.

Kudos.

------
jplane
I'm so excited about all the error messages work on this release! Also, the
new metadata and tap functionality creates so many possibilities. And Java 8
minimum guaranteed so we can build things on top of java's time libraries and
trust they will be there.

Nice work everyone!

------
Sharlin
Any examples of what the new error reporting looks like? The release
announcement is rather lacking in details.

~~~
puredanger
I did a write-up that should give you an idea:
[http://insideclojure.org/2018/12/17/errors/](http://insideclojure.org/2018/12/17/errors/)

------
marcrosoft
Congrats. I'm trying to learn Common Lisp for great good. And, I love that
lisp is still alive. I think we still haven't learned all that lisp has to
offer.

For me personally, I think Clojure (or any lisp) targeting Go would be
awesome.

The JVM lacks a killer Go "feature" which is _native binaries/easy deployment.
Common lisp and many other lisps lack community which is why I think Go+Lisp
would make a great combo. Go, even though it is a new language, already
outpaces (a much older) Common Lisp as far as libraries go due to the huge
community Go has.

I know there is `zygomys` but it doesn't reach Clojure popularity/maturity.

Can Clojure target Go?

Edit:

Maybe it is infeasible but I think targeting JVM, Go, and JavaScript would
give Clojure a ridiculous advantage over almost any current programming
language.

~~~
xapata
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.

~~~
fcurts
A more feasible option is to compile Clojure byte code to native code with
GraalVM ([http://www.graalvm.org/docs/reference-manual/aot-
compilation...](http://www.graalvm.org/docs/reference-manual/aot-
compilation/)). GraalVM's native compiler still has some limitations but is
coming along nicely.

------
dannyobrien
I've just started toying with Clojure, and while I've enjoyed it a great deal,
the error messages were definitely one of the more unfriendly parts.
Fortunately, my last two hobby languages were Elm and Haskell, so Clojure was
always going to be in the middle between those two extremes). Good to see it
being worked on!

------
kbd
Are there any plans for a native version of Clojure? I'd rather avoid the JVM
if possible, but I suppose the whole ecosystem is dependent on it so that's
unlikely?

~~~
preordained
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

~~~
kbd
> I guess I might ask what this stance is founded on?

Kotlin has Kotlin/Native, so I was hoping there might be a similar initiative
for Clojure. But, a few reasons:

* Startup time

* Ability to deploy/share a binary

* The JVM just seems so "heavy" to me. It's certainly the only language runtime I know of that runs a persistent helper app, or asks to install an Ask toolbar upon installation.

* Bias against Oracle and Java

> Also I think recent Java releases have gotten into making self contained
> binaries

TIL, thanks.

Edit: edited.

~~~
zmmmmm
> * Bias against Oracle and Java

It's always fascinating when I encounter people with opposite biases to my
own. While I'm no fan of Oracle, I seek out technologies that are based on the
JVM and try to avoid things based on many other technologies because I
intrinsically trust certain behaviors and features of the JVM that other
ecosystems lack.

~~~
kbd
After suffering through Java early in my career I've completely avoided it
since then. What parts of Java/JVM do you find indispensable vs the rest of
tech?

~~~
zmmmmm
Definitely more the language ecosystem than Java itself - coding in Java
itself is painful to me as well. I actually write most of my code in Groovy,
some in Kotlin and Scala. But these things keep me liking the JVM -

\- maturity of the infrastructure (monitoring, debugging, IDEs, build
tooling). I love that I can fire up my debugger and remote attach to a process
running on some other host and set a breakpoint for a specific condition to
catch a bug. Or that I can do the same to profile memory etc., all with very
mature tools.

\- very good performance - smack bang inbetween C/C++ and higher level
languages (acknowledging that startup time is a big hole in that - but not an
important one for me)

\- truly cross platform - none of this python style, cross platform except
half your packages are really written in C and won't compile unless an entire
ecosystem of dependencies is there to support them, and even then some of the
flat out don't work on some platforms. This extends deeper than most other
languages ie: you can get closer to low level OS features while maintaining
100% cross platform capability.

\- strong / static typing under the hood which you can access optionally (eg:
languages like Groovy / Kotlin let you write high level code without being
burdened too much by the overhead of static typing), but all the Java APIs,
ecosystem of libraries are all statically typed so you have good guarantees
and excellent documentation.

\- deployment behavior - I can run the JVM, give it specified memory footprint
and know it's going to stay within that

------
souenzzo
Onde clojure is coded in edn, I think that is no reason to break changes. If
one day we need to change something in core, we can make clojure.core2 and
make the ns2 macro.

------
billfruit
Nice to know that debug messages have improved. Ease of debugging would
improve more, if an exception happens a live repl is spawned at that point
allowing one to view locals/values, modify state, continue execution, etc.

Most lisps allows such live repls for debugging like Scheme and Emacs lisp,
while clojure only provides a stacktace on exception, and not a repl.

~~~
phyrex
You can do that yourself if you care
([https://m.youtube.com/watch?v=zp0OEDcAro0](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.

------
billfruit
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.

The emacs based tooling had too many components, and is very brittle, ie, a
minor version bump in one of the component often renders the whole build/repl
process unserviceable.

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.

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

~~~
snorremd
I quite like tools.deps, but it is maybe a bit problematic that it is bundled
with the Clojure install. Before tools.deps there were no officially
sanctioned dependency and project management tool. This is probably why we got
both leiningen and eventually boot. Now the bar for choosing something
different than tools.deps is probably going to be quite high.

Sadly tools.deps lack the support for reading credentials from a gpg/pgp-
encrypted file:
[https://dev.clojure.org/jira/browse/TDEPS-9](https://dev.clojure.org/jira/browse/TDEPS-9)
This is a shame as I rely on this to keep repository credentials safe. I'm not
a fan of the maven master password system.

