Great conversation, thanks for sharing

I think that is caused by a pre 19 version of java-fx, which doesn't work with M2. Try to upgrade java-fx to the latest stable, which I think is 21

add this deps to your project :

org.openjfx/javafx-controls {:mvn/version "21.0.2"}
org.openjfx/javafx-base {:mvn/version "21.0.2"}
org.openjfx/javafx-graphics {:mvn/version "21.0.2"}
org.openjfx/javafx-media {:mvn/version "21.0.2"}
org.openjfx/javafx-web {:mvn/version "21.0.2"}

if that doesn't solve it you can try the latest early access, which is 23-ea+3 in all those deps

Also, it's not entirely obvious to me from the Java details, so just in case - there are two JDK variants that can be run on M2. One is native to M2, the other is not. The latter is slower and causes problems more often.

@U0739PUFQ It worked! Thanks

@U2FRKM4TW oh, I was not aware. Let me see if I can find how to install/use it

I'm getting a feeling that it is related to macos and java (maybe clojure) setup more than cljfx specific issue

hm, I think this is a known issue (https://github.com/cljfx/cljfx/issues/177), though I’m not sure what’s causing it

it might be that emacs is running in rosetta emulation mode (i.e. x86, not arm), and that maybe causes emacs to pick up x86 jdk if both x86 and arm are installed…

maybe you could try launching jdk using nrepl and evaluating (System/getProperty "os.arch") ?

@U47G49KHQ I didn't fully understand launching jdk using nrepl . I opened terminal and typed clj and evaluated (System/getProperty "os.arch") .The result is aarch64

hold on, which cljfx version do you use?

on jdk 21, it should automatically select javafx version 22-ea+16 which should work on m2

if you are using 1.8.0

@U47G49KHQ I'm using latest git commit (from project readme) - cljfx/cljfx {:sha "60bb2dd6ca3331959600e67ad9eb401f7b09d83e", For cljx repo (examples tutorials). I've updated all javafx-* libs to 21.0.2 as suggested before

ah, the git dep

then you need to explicitly update the javafx deps in your project

you mean like copy pasting from cljxfx deps to my project's deps.edn so that it will override cljfx's java-fx lib versions? should I use 22-ea+16

org.openjfx/javafx-controls {:mvn/version "21.0.2"}
        org.openjfx/javafx-base {:mvn/version "21.0.2"}
        org.openjfx/javafx-graphics {:mvn/version "21.0.2"}
        org.openjfx/javafx-media {:mvn/version "21.0.2"}
        org.openjfx/javafx-web {:mvn/version "21.0.2"}

21.0.2 is fine

22-ea+16 is latest, and has some fixes for issues that you might not even hit, depending on what you want to do. It has some improvements for keyboard shortcut handling on non-US keyboard layouts

maven central shows 23-ea+3 as the latest, which is weird, not sure why there are early access to 23 but no 22 stable

@U47G49KHQ It worked 👍:skin-tone-3: Thanks a lot! I'm trying out cljfx for my desktop product. This is my first time taking a jab at it. I'm little concerned out the distribution process for java/clojure/cljfx stack. Will user need java to be installed or deal with any other steps except download and install? Majority of users will be non technical people My other candidates were electron (I'm a web dev) and most electron based desktop app I personally use have straight forward way for all platforms (exe, dmg, appimage etc). And I've https://github.com/logseq/logseq for reference to setup it up Is there any tips you can provide? A prod ready project will be perfect for pipeline setup if it available online

Check out https://github.com/cljfx/hn

It has GitHub actions that builds executables that embed jdk

Thanks!

> small engineering community I'm not sure about this, if it is about hiring, there seems to be always people looking for Clojure jobs, and if it is about finding help and support, I think there is plenty > no (broadly-accepted, successful) static typing system I don't think this is a drawback for every system. It is not clear from the article what aspects of the lack of static typing he is missing, and why spec or malli can't cover those > Some aspects of the polymorphism system are lacking by reading the comments he talks about lack of inheritance there, and if I have to choose between having to repeat some code vs reasoning about inheritance calls I choose the former > The error messages are terrible this is super generic, and imho it applies much more to beginners than to experienced Clojurists. The clojure compiler is form based instead of file based, which makes things worse. I think there is room for improvement here but imho the way to improve this is on a case by case.

>> small engineering community > ...if it is about finding help and support, I think there is plenty It's not a showstopper for me but I do notice the drawbacks of having fewer people working on things.

> I do notice the drawbacks of having fewer people working on things interesting, you mean the speed in which the ecosystem evolves?

Sure

Now factor in all the hammock time those people are taking as well

> The error messages are terrible This one has been near the top of the list every year since the core team started doing the surveys lol. In my opinion, having used a number of other languages that provide significantly better error messages, I find this to be the hardest part of continuing to work in Clojure. I pretty frequently find myself in situations where I have a mismatch of expectations and the resulting error messages provide little to no help. I end up doing a painstaking close reading of the stack trace to figure out exactly what went wrong and why, performing the work that other compilers perform automatically. I don't think it all comes down to "dynamic types" either. Python has put a lot of work into their error messages, and they're able to point out exactly what went wrong with clear and helpful wording. "But what about Clojure 1.10's error messages?" I think they're a good step up, but they're still quite opaque and cumbersome. I wrote a bunch of reddit comments about this back in 2022 (https://old.reddit.com/r/Clojure/comments/x6x9gu/what_is_most_in_need_in_clojure_opensource/inbi192/, https://old.reddit.com/r/Clojure/comments/x6x9gu/what_is_most_in_need_in_clojure_opensource/inbvgmq/, https://old.reddit.com/r/Clojure/comments/x6x9gu/what_is_most_in_need_in_clojure_opensource/inbzdpx/) , but in short, there's no fundamental philosophy about what an error message should be or how it should work in Clojure. Some of them are pretty clear ("Unmatched delimiter"), some are complex and hard to parse and understand ("Syntax error macroexpanding clojure.core/defn"), some are completely impenetrable ("class java.lang.Long cannot be cast to class java.util.concurrent.Future").

yeah, about the macro expansion errors it would be great if the most used macros like defn , let , etc gave error messages like this instead :

I guess I could experiment with that in ClojureStorm

My thoughts (though aphyr has way more experience with Clojure than me): > small engineering community AND no (broadly-accepted, successful) static typing system I think the benefits of static typing are clear, but there are downsides, too. So it isn't obvious yet that that it would be a net win. > Both of these would constrain a large team, but Jepsen’s maintained and used by only 1-3 people at a time. What if yes, it would constrain a large team, but it also enables a small team to do a lot?

The black swan retort to the large engineering teams argument is Nubank.

Yea I was wondering about that too, but wasn't sure if they had to do something special to accomplish that

E.g., maybe it is 1000s of codebases, not 1

Yeah, I’m not familiar, but I doubt it involves grafting on a static type system onto Clojure. More likely specs and schemas, if indeed they use something of the sort.

they use a lot of schemas, and as i remember it, they don't run traditional microservices, but they do something similar to polylith where there are defined entrypoints to every service that are checked by those schemas

I doubt they are as affected by the potential “small community” issue as well, given the rather large engineering force they employ. They can theoretically make in-house what they’re missing.

I think the removing the 'small community' argument was also the point of building on the JVM. So there is a bridge between the small community to a massive one. But it doesn't invalidate the argument completely, just mitigates it.

Purely from my own experiences it does seem that projects using static typing languages tend to have a lot of people working on them. Fewer people seem to be required for a Clojure project to get the same results in the same timeframe (or less). I believe this is one of the benefits that was said about lisp dialects back in the 1980s. As the language syntax is simpler and has less boilerplate code, then more time can be spent understanding the problem and finding the appropriate solution than wrangling with the language syntax (or looking up the 50+ precedence rules for the language) I also see a small community as a positive thing. There is less division and fewer frameworks to pick through, is much more stable and you don't feel you have to rebuild your stack or tooling every 6 months.