Clojure 1.11 planning • Hacker News Board

Re: Clojure 1.11 planning

#21

Post by yogthos » Tue, Oct 08, 2019, 1:07 PM UTC

StreamBright wrote: post #19

dancek wrote: post #12

Earlier quoted context omitted.

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.

Re: Clojure 1.11 planning

#22

Post by puredanger » Tue, Oct 08, 2019, 1:13 PM UTC

badsavage wrote: post #8

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)

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

Re: Clojure 1.11 planning

#23

Post by puredanger » Tue, Oct 08, 2019, 1:14 PM UTC

logistark wrote: post #6

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

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!

Re: Clojure 1.11 planning

#24

Post by thelazydogsback » Tue, Oct 08, 2019, 1:49 PM UTC

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?)

Re: Clojure 1.11 planning

#25

Post by puredanger » Tue, Oct 08, 2019, 1:55 PM UTC

thelazydogsback wrote: post #24

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.

Re: Clojure 1.11 planning

#26

Post by rcarmo » Tue, Oct 08, 2019, 1:56 PM UTC

thelazydogsback wrote: post #24

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?)

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

Re: Clojure 1.11 planning

#27

Post by StreamBright » Tue, Oct 08, 2019, 2:00 PM UTC

yogthos wrote: post #21

StreamBright wrote: post #19

Earlier quoted context omitted.

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.

Re: Clojure 1.11 planning

#28

Post by thelazydogsback » Tue, Oct 08, 2019, 2:08 PM UTC

thelazydogsback wrote: post #24

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?)

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.

Re: Clojure 1.11 planning

#29

Post by robto » Tue, Oct 08, 2019, 2:13 PM UTC

rcarmo wrote: post #26

thelazydogsback wrote: post #24

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?)

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

Re: Clojure 1.11 planning

#30

Post by Scarbutt » Tue, Oct 08, 2019, 2:44 PM UTC

dancek wrote: post #5

roenxi wrote: post #3

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 someth…

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.