Officially support Vert.x

Hi All, Curious about Vert.x is officially supported? We tried to use some new languages on JVM e.g. Scala, Kotlin etc. and be interested in using some relatively purely functional programming languages and so far Clojure is our best bet but unfortunately couldn't find native Clojure api on

Re: [ANN] Clojure 1.9.0 is now available!

What’s the full stack trace on the original exception? (Or if same repros without aot)? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated -

1.9 is close to 2.0...

At the moment I expect 1.10 to be next (that’s the current snapshot version). There are currently no grand plans for major changes warranting a 2.0. We have a bunch of work in progress in spec, tools.deps, and other new projects that I expect to be the source of novelty for the near future.

Re: [ANN] Clojure 1.9.0 is now available!

Hi, I am baffled. I switched a project from 1.8 to 1.9.0 upgrading also other dependencies (latest version fo core.async, ...) via lein ancient. As usual I ran an AOT pass to make sure I don't have anything fishy before running the code. I got this from the AOT pass:

Re: 1.9 is close to 2.0...

I would expect 1.10 is next. Andrew Oberstar On Thu, Dec 28, 2017 at 4:58 PM Jacob Goodson wrote: > Now that clojure 1.9 is out, will future releases be 1.91, 1.92, etc? > > Or, are talks in place for a clojure 2.0? > > If there is discussion of clojure 2.0, what

1.9 is close to 2.0...

Now that clojure 1.9 is out, will future releases be 1.91, 1.92, etc? Or, are talks in place for a clojure 2.0? If there is discussion of clojure 2.0, what would that look like? Clojure running on graal, clojure (the people behind it) doing some other fantastically amazing thing? Just

[ANN] CIDER 0.16 (Riga)

Hey everyone, Here's one (a bit overdue) Christmas present for all of you - a major update to CIDER, the popular Clojure interactive development environment, built on top of Emacs and nREPL. The big news is that CIDER 0.16 starts much faster when you use `cider-jack-in` (due to deferred loading

Re: spec key aliasing or different specs for same keyword

Yes, the namespacing is great, so I have no issue with that. I would just rather use snake-case in Clojure than camel-case. Since the payload has 'resultCount' I'd like to map that to a spec named result-count instead. I think I figured out part of the answer: (s/def :my/result int?) (s/def

Re: spec key aliasing or different specs for same keyword

Avoiding global name collision is the reason why specs are named with namespace-qualified keywords. I am confused by your last sentence though. Do you mean Clojure namespaces or the namespace component of the keyword itself? There is no requirement in clojure.spec that the namespace of the

spec key aliasing or different specs for same keyword

I have one spec question covering two scenarios. 1. Suppose I want to spec a payload from a third-party API that has the keyword ':resultCount' in it. Does that mean my specs for that item must have the same name? 2. Supposed I have a few payloads from that API and each has a keyword