Glojure: Clojure interpreter hosted on Go, with extensible interop support

Post by vips7L » Thu, Dec 05, 2024, 9:16 PM UTC

agumonkey wrote: post #59

vips7L wrote: post #57

Earlier quoted context omitted.

Please don’t take this rudely. But if you haven’t used a language or looked into in over a decade perhaps you shouldn’t comment on it? That being said you should really check out how streams, records, switch expressions, pattern matching and all of the recent additions in the last 5 years have made Java a magnitude less verbose than Go.

Few factors: - a ton of java is still legacy, ask works with java 7 vs java 17 and enjoy the laugh - I assumed java culture was still too rotten by its roots. I've used streams but whenever I have to import BiFunction I feel very sad. on the other side, the few go code I've seen was always very concise, or even when the code base wasn't very well designed it was, at worst, still below java

   func(a A, b B) C

Post by mark_l_watson » Fri, Dec 06, 2024, 12:34 AM UTC

Capricorn2481 wrote: post #60

mark_l_watson wrote: post #54

Earlier quoted context omitted.

A little off topic, but as someone who has occasionally used Clojure since Rich released a beta version (on many professional gigs, and to support examples in my Clojure AI book), I used to make such a mistake by writing wrappers in Clojure for Java libraries I used. A while back someone set me straight, and I no longer do that. So much better to call Java directly. Seeing the Glojure/Go interop examples reminded me…

What's the practical difference? Aren't you doing the same java interop in your app that you would be doing in your wrapper?

Post by binary132 » Fri, Dec 06, 2024, 5:57 PM UTC

jpcom wrote: post #62

ludston wrote: post #13

Earlier quoted context omitted.

You're not my dad.

You theoretically can but Clojure is not OS-level so you'd be working something like JVM->CLJ->Go and that would remove a lot of performance. Or Go->Clj->Go which is redundant. So yeah, I stand by my statement. And I could be your dad, how do you know 100%?

Post by jpcom » Fri, Dec 06, 2024, 7:52 PM UTC

binary132 wrote: post #65

jpcom wrote: post #62

Earlier quoted context omitted.

You theoretically can but Clojure is not OS-level so you'd be working something like JVM->CLJ->Go and that would remove a lot of performance. Or Go->Clj->Go which is redundant. So yeah, I stand by my statement. And I could be your dad, how do you know 100%?

Go -> JVM bytecode with a Clojure-facing API and a Clojure-based compiler as a Clojure package wouldn’t be so bad. It’d just be another JVM frontend, hosted in Clojure. Clojure is also just a JVM frontend. I’m not quite understanding this “JVM->Clojure” bit of your equation; Clojure is a JVM frontend and stdlib API.

Post by gf000 » Sun, Dec 08, 2024, 8:46 AM UTC

xyproto wrote: post #66

vips7L wrote: post #61

Earlier quoted context omitted.

Only 2% [0] of runtimes are on Java 7. There is a large majority on 8 still and 45% are running Java 17. That being said Java 8 is still less verbose than Go. The number of lines needed to do basic programming like iterating collections or error handling is a magnitude larger in Go. You’re basing your opinion on your feelings rather than objective facts of being in the ecosystem. Yes you may have to import BiFunction…

JetBrains earns money on selling Java-related products. They are a very biased source.