Clojure 1.11 planning | Hacker News Reader

Clojure 1.11 planning

insideclojure.org

188 pointsgalfarragem71 comments

Clojure had kept the core lean and simple and has grown through the years with libraries for features like spec. It makes the language as a whole stable with features developed and tested like spec being a library in alpha.

Spec is very useful, but please implement it without macros. Metosin did a great job to make it more usable, but we still struggle because specs could only exist in Namespaces. We want to use spec as EDN with pure functions. (+ recursive specs would be awesome)

For schemas as EDN you might want to take a look at malli:

https://github.com/metosin/malli

I didn't know malli, thank you Borkdude!

Spec 2 can be used without touching any macros if desired and has a lot more programmatic options.

Awesome!

I enjoy Clojure and spec is very interesting; but it remains uncertain if I have any problems that spec will solve. I'm not really that interested in the generative testing aspect since I write mostly amateur code.

So I can't figure out if it is more like a debugger for targeted location of difficult bugs or more like compiler error messages where it becomes a pervasive part of the workflow.

There is obviously something to this spec if it warrants a v2. It just isn't obvious whether it solves my problems, library maintainer problems or professional problems. It is very different to the immutable-everywhere design where a Clojure beginner is forced in to understanding it to even try trivial experiments.

One use case is API input validation.

Spec is great for validation. For example, we have a HTTP API built using https://github.com/metosin/reitit where we have specs for each endpoint. We have a coercion middleware that checks each request (and optionally response) conforms to a spec (and coerces things like integer ids from path to the correct type). And there's a swagger handler that automatically generates a full documentation of the API just from the route tree and specs, including samples of input and output for all routes.

Similarly you can do HTML form validation, etc.

We even use honeysql with nice helper functions that ensure that data-changing SQL queries are of the expected form. Say, you want to update just one row, you have a helper function that checks the honeysql data has a where clause with a unique column and only then runs the query. Someone should maybe blog about that sometime.

What I've found, though, is that trying to use spec like type checking is usually not a great idea. I expect better from static analysis / compile-time checking, with clj-kondo being the most promising tool atm.

I remember spec being pitch for something you only use at dev time and turn off in production because it makes your runtime very very slow, what has change? Seems users are using it for everything now.

No. It was always designed to be configurable so you can keep on the API endpoints, but deactivate them internally.

We don't have instrumentation in production, ie. we spec much more at dev time. But for things you'd validate anyway spec is a good match and probably about as performant as hand-written validation.

The only strange use of spec I mentioned is validating db queries. For us updates and deletes are rare enough that perf doesn't matter.

I bet you are thinking of https://clojure.org/guides/spec#_instrumentation_and_testing - it was always just one use of spec among many.

Spec has numerous uses. We use it heavily in production for data validation/conformance: https://corfield.org/blog/2019/09/13/using-spec/

I have a somewhat off-topic question I've been wondering about... How do you pronounce "reitit"? I've been considering giving a talk on it at my local clojure group, so I should probably learn how to actually say the word!

In my brain I usually say re-it-it, but sometimes I think "rye-tit" which makes me laugh and definitely seems wrong.

Raitit (rye-tit) is a Finnish word too: the plural of "a lone village road splitting the village in half".

Would make a nice library name. Wonder if Metosin takes requests...

It's more like "ray-tit". A colleague at Metosin came up with a good alternative: "rate it!" Used in sentence like "I reitit 5 out of 5!"

It's a Finnish word. Google Translate's text-to-speech is pretty decent - click the speaker icon on the left: https://translate.google.com/#view=home&op=translate&sl=fi&t...

Thank you!

You won't necessarily have to use it directly to reap benefits from it. API authors can use it to provide you with excellent error messages which pinpoint the exact location something is wrong

We use it extensively as a kind of "incremental typing" - that is, I can assert that what goes in to a function has a given shape and what goes out complies as well. Even in production, the overhead is quite low (think 5% in our use case).

My daily usage:

- input and message streams validation.

- data generation for testing.

- spec is the best data structures documentation!

- sequential data structures parsing and transform

More magic, but based on everything mentioned: dev-time macro input and destructuring sanitizing and error report.

The dream for me is to model things like HTML5 specification as data instead of English

I use it often as a giant sanity assert that guards my application state in dev mode. In lieu of static types. Helps me catch dumb type errors early at the site of mutation.

I see it mainly as an answer to static types. Clojure (like most Lisps) places emphasis on dynamic types, for some valid reasons (https://lispcast.com/clojure-and-types/). But there are certain undeniable benefits of static typing that you miss out on: documentation, and IDE hints. Spec, the way I see it, is a way to reclaim some of those benefits without giving up the dynamic paradigm. It also has some advantages over static type systems; most notably you can describe any arbitrary assertion, which makes it more expressive than regular types. You can also check things at runtime, which can be useful for validating foreign inputs that aren't available at build time.

Personally I'm still a static-types person, but I get it. And if I used Clojure regularly, I'd be all over Spec.

But there are certain undeniable benefits of static typing that you miss out on: documentation, and IDE hints.

And performance.

> Spec 2 has been kind of stalled out as Rich is thinking through some of the work we were doing on how to rework function specs and the use case of automating form/map versions of the specs.

It's fascinating to watch a major enterprise language with a Steve Jobs figure at the top, who maintains a firm grip on the wheel, keeping it on track with his clear vision even as its community grows in scale, to the point where he alone would be a bottleneck in its design process.

I mean it's clearly working out - as it worked out for Jobs - it's just highly unusual.

I'd love to see more focus on non-JVM impls other than JS -- .Net Core 3.x specifically. (ClojureCLR is pretty much dead, right?)

ClojureCLR is up to date with the Clojure on JVM, so not dead at all.

It gets regular commits, but I've found it impossible to use practically, somewhat to my regret (I have plenty of use for a LISP that can do .NET interop).

You might want to check out Arcadia[0], a Clojure library for Unity game development. It's all done with ClojureCLR and it's pretty cool. Not saying you want to do game development, but they've definitely got a working product and you can see how they've set up their project.

They just got a round of funding this year, and they've got several good talks posted on their homepage about the quirks of working on .NET.

[0]https://github.com/arcadia-unity/Arcadia

I did, but it was a bit stale a year or so ago (as in it wouldn't even work with the Unity build at the time). Which is too bad, since one of my kids is doing Unity micro-games and I would like to have alternatives...

Development has picked up again AFAIK, saw one of the developers give a short demo/talk on it recently and it seems neat.

Godot is a decent OSS alternative to Unity, but no Clojure/Lisp so far as I know :(

Yup, Ramsey gave a talk at Clojure/north [1] about Arcadia. I got a chance to briefly chat with him, and it looks like they actually managed to raise funding to develop it further.

And somebody made Arcadia bindings for Godot [2], but the project isn't actively maintained. Would be great if somebody picked it up again.

[1] https://www.youtube.com/watch?v=LbS45w_aSCU [2] https://github.com/arcadia-unity/ArcadiaGodot

Godot blows up the entire OS when you have HTTP content filtering enabled on a kids’ account (not Godot’s fault, but it is the only app that ever triggered that particular kernel panic in over 2 years they’ve had a Mac):

https://github.com/godotengine/godot/issues/24890

I doesn't look like it targets .Net Core yet. I don't see much about dev workflow -- is there a VSCode plugin for dev/debugging? The Getting Started page is 403. But I'll spend more time in the wiki and give it a try.

Not .net core specific, but 'Calva' is a good Clojure plugin for VSCode.

Cool, cool. When is full compatibility with Java 8 be available? I mean Java 8 SAMs, Java 8's Stream, Optional and CompletableFuture...

Clojure is a different language. Being "fully compatible" with (more similar to) Java was never a goal.

This is why guest languages tend to fade away, as the platform evolves and the platform system languages adopt the features that made those guest languages appear in first place.

That is true for guest languages designed to overcome specific issues in a given language (think CoffeeScript vs. JavaScript in 2012 and then in 2019). But I don't think it really applies to Java vs. Clojure, which both pretty much force a specific (different) programming paradigms and have completely different design.

True but you need to access the libraries in Java. That is a little bit hard in some cases.

I find that I tend to do very little interop nowadays, and it predominantly happens at the edges with things like database drivers, and so on.

Yes most of the things just work.

Unless they follow up and keep up with the host platform. This is the biggest pain point with Clojure for me, the java interop has some limitations that we could not come by.

Clojure accepts multiple hosts and is simple enough to port to new ones – a hugely underappreciated reason that Clojure is permanent

Just like many Lisp and Scheme implementations that came before it.

I'm looking at the docs -- is there a guide for targeting new host langs? As a starting point, what is the minimum "core" language that needs to be defined in the host lang so that the rest of the system can be bootstrapped by Clojure libs? (Clojure.core doesn't seem to be the answer -- there seem to be plenty of non-core/prim functions defined there.

Also, are Clojure libs (either automatically or via attribute on the package) flagged as "pure" (Clojure-only) vs. needing imports from a specific host lang?

Yes, the special forms.

https://clojure.org/reference/special_forms

Clojure follows the Lisp convention of providing platform specific behaviour via the reader.

https://clojure.org/guides/reader_conditionals

Not sure I follow -- there are certainly many primitives that must be defined by the host to bootstrap that are not special forms -- starting with list, cons/conj...

I doubt there’s a guide anywhere: it’s far from a trivial undertaking. If you want to look at the Java code that builds all the primitives, see the Clojure/Lang folder:

https://github.com/clojure/clojure/tree/master/src/jvm/cloju...

Part of what makes it Clojure instead of just a Java-based lisp are the persistent data structures that allow for efficient immutability, and the seq interface for working with collections smoothly. There’s a big (scary, to my eyes) set of classes that underlies all of the convenience. Thankfully it’s very stable so I don’t have to think about it.

Kotlin seems promising (because of android).

Not really.

Kotlin already has an impedance mismatch with the JVM, because like all guest languages they have come up with their own ideas, which don't follow how the platform ended up implementing them.

Examples are sequences vs streams, lambdas vs SAM types, default interface methods, co-routines vs fibers, inline classes vs records, reflection.

Only first class support on JetBrains products, while many Java shops are still Eclipse, NetBeans and Oracle Studio users.

Additionally, since they want to stretch outside the JVM, there are semantic restrictions if the code is also supposed to be compiled by Kotlin/Native.

Kotlin has indeed a future on Android, given that Google is unwilling to move their support beyond the Android Java flavour (aka Google's own J++) and with #KotlinFirst, Android has become the KVM.

So, on Android I do agree that Kotlin has a bright future, however in what concerns the JVM I forsee an adoption cycle like every other JVM guest language.

What parts of compatibility are missing? The interop works just fine, as with all other Java.

  ; example: Stream.of(1,1,2,3,5).map(x -> 2*x).collect(Collectors.toList())
  user=> (.. (java.util.stream.Stream/of (to-array [1 1 2 3 5]))
             (map (reify java.util.function.Function 
                    (apply [this x] (* 2 x)))) 
             (collect (java.util.stream.Collectors/toList)))
  [2 2 4 6 10]

Of course it's not practical to convert lists and functions to their Java counterparts like that, but if you need to work with Java objects it's possible.

Slightly off-topic, but as someone who's normally using Python / R, my hands feel tired just from thinking about typing all of that

In practice, you wouldn't. You'd import at the top of the file, then type `Stream/of` instead of `java.util.stream.Stream/of`.

I almost never use Java directly though because there are so many great Clojure wrappers.

In Clojure that's:

  (map (fn [x] (* 2 x)) [1 1 2 3 5])
  => (2 2 4 6 10)

so no Java Function to clojure Function automating mapping ? do people use macros to make it nicer ?

you'd use Clojure not Java for an example like the above

I think the context is when doing interop.

yes but I got the feeling the grandparent was confused so I tried to clarify that the only reason for the verbosity is interop - the Clojure code is much more concise than the Java - the interop code is like listening to a speech being translated between English and Spanish

Not out of the box, probably because java.util.function.Function seems like an afterthought in a strictly object-oriented language while Clojure has first class functions. In practice you don't interop with Java very much, let alone functional Java (as Clojure itself is a much better fit). But if it was useful, it'd be easy to write helpers for converting functions back and forth.

functions. Macros are a super weapon and their use is reserved for very special cases. One reason is macros can't be composed as functions and also readability goes out the windows.

I think first class support would remove a lot of boilerplate in that code. For the purpose of writing that, i prefer to write it directly in Java.

Why wouldn’t you prefer writing it directly in Clojure?

    (map #(* % 2) [1 2 3 4 5])

Even less boilerplate, even more signal/noise.

Has been a long topic of conversation trying to figure out the best way to do some of these while also retaining best performance, etc. High in our list of candidate things to work on!

Big pain point, Java 8 was release in 2014, and the java.util.Function interfaces have become very common in practice since then. Clojure is really dying...

I think it's because Clojure itself has been offering a better alternative to streams for years.

And let's be honest: @FunctionalInterfaces are a compiler hack, since Java doesn't really have functions.

And what I simply love about Clojure:

If writing (reify java.util.Function (apply [this arg])) is too verbose, roll your own macro or function. You could also add a tagged literal.

Oof, every single Clojure related HN post, there's always at least one person claiming that Clojure is dying. Clojure is not dying! Look around, Clojure today has more conferences, meetups, podcasts, jobs, and books. More than any of non-mainstream languages. More than Haskell, Elixir, OCaml, Elm, Rust.

I'm sorry for snapping at you. It just makes me sad to have to fight unwarranted skepticism all the time. People throw opinions out of the blue, sometimes without even considering a heartfelt attempt to try things out first.

Evangelizing for Clojure has become a moral issue. Just like arguing with gun-control, climate change opponents, and anti-vaxxers. No matter what arguments you bring to the discussion, those who don't want to listen - just wouldn't.

You say: "Clojure is very pragmatic",

They'd be: "I don't want to learn Emacs".

You say: "But you can use VSCode, Atom, Eclipse, Vim, IntelliJ to write Clojure",

They: "Too many parentheses..."

You say: "Other languages have more, and a bunch of other things like semicolons, commas, curly braces, and operator precedence rules... "

They: "But it's not statically typed"

You say: "It has Spec. Spec can do things, most type systems cannot"

They: "But I don't like JVM..."

You say: "JVM is a very robust, solid piece of tech..."

They: "Clojure is dying..."

---

Honestly, I don't understand this tribalism. Like people really don't want it to succeed. It isn't some zero-sum game - the success of one language ecosystem does not mean there's less pie for others. There are many things in other languages - Rust, Elixir, Javascript, etc. directly inspired by how they first were done in Clojure. Just think about it: Cognitect has a team of fewer than fifty developers, and the Clojure community has no more active members than engineers working for Google, yet there's a constant pace of innovation for the entire CS community. Maybe the language has something to do with that, after all?

Clojure already has equivelent or better stuff to do the same thing. And you can still use it if you like.

Reply on news.ycombinator.com