Live data from Hacker News

Clojure 1.11 planning

insideclojure.org

31–40 of 72 posts

Re: Clojure 1.11 planning

#31
post #16

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

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…

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

Re: Clojure 1.11 planning

#32
post #16

Earlier quoted context omitted.

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…

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.

Re: Clojure 1.11 planning

#33
post #29
post #26

Earlier quoted context omitted.

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…

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

Re: Clojure 1.11 planning

#34
post #33
post #29

Earlier quoted context omitted.

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…

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 :(

Re: Clojure 1.11 planning

#35

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

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

Re: Clojure 1.11 planning

#36
post #5

Earlier quoted context omitted.

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…

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.

Re: Clojure 1.11 planning

#37

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

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.

Re: Clojure 1.11 planning

#38

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

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

Re: Clojure 1.11 planning

#39
post #5

Earlier quoted context omitted.

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…

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.

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.

Re: Clojure 1.11 planning

#40
post #11

Earlier quoted context omitted.

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.

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?

Post reply on HN