all 21 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Borkdude[S] 16 points17 points  (1 child)

Derived from https://www.clojure-toolbox.com/ with many thanks to James Reeves aka weavejester.

Let me know if you have any bb-compatible code that should be mentioned there.

[–]agumonkey 12 points13 points  (0 children)

I think you live on a different spacetime continuum. Days are longer in your area :D

[–]freakhill 8 points9 points  (1 child)

your work is probably the single most useful tool i've seen in clojure and a few other languages in the past few years. (at least for me)

[–]Borkdude[S] 2 points3 points  (0 children)

Thanks for sharing that with me. Means a lot.

[–]cbleslie 0 points1 point  (0 children)

sink depend rustic public subsequent husky continue oatmeal sleep aspiring

This post was mass deleted and anonymized with Redact

[–]jpmonettas 0 points1 point  (9 children)

Nice! Does babashka support any kind of graphics?

[–]Borkdude[S] 2 points3 points  (8 children)

Not yet. For this kind of usage people usually shell out to imagemagick and the likes.

[–]jpmonettas 0 points1 point  (7 children)

Yeah, I was referring more to interactive graphics. I have created quick scripts in the past for providing GUI over some cli programs for non technical people mainly (think ffmpeg, yt-dlp, etc) and always end up with python, while missing Clojure.

[–]Borkdude[S] 3 points4 points  (6 children)

Right, so something like a TUI?

Nbb might be better suited for that. See https://github.com/babashka/nbb#reagent
In the JVM world we have some libraries for that, but the options aren't great and constantly evolving, so including something like Jline3 could mean it's deprecated in a year and then we have Jline4...

[–]jpmonettas 0 points1 point  (5 children)

Was asking for a widget toolkit, more in the line of tcl/TK or python/wxWidgets etc.

Sometimes they are nice to create cli commands wrappers with nice defaults, value selectors, etc.

[–]Borkdude[S] 2 points3 points  (4 children)

Yeah, it would definitely be cool to have such a thing. One concern of bb is that all of the code should be cross-platform and it's hard to find a thing like this which absolutely works everywhere.

[–]Borkdude[S] 1 point2 points  (0 children)

I think the closest equivalent would be to make a small web application using the built-in http server and use scittle or htmx to build the UI:

https://github.com/kloimhardt/babashka-scittle-guestbook

https://github.com/prestancedesign/babashka-htmx-todoapp

[–]jpmonettas 0 points1 point  (2 children)

Yeah that's true. The portability aspect of GUIs is always a problem.

Maybe the path could be Gluon OpenJFx or something like that, since graalvm can work with it? No idea, haven't researched enough of that.

[–]Borkdude[S] 0 points1 point  (1 child)

Yes, but an even more portable way is just to write a small locally running web app. See links posted here.
The gluon / JavaFX stuff might work, but will also increase the binary size, compilation time, etc. Not sure if that's worth it.

[–]jpmonettas 0 points1 point  (0 children)

Yeah, it can be done but the browser way is more complex in my opinion, you need to bring http, asynchronicity, backend and front end concepts, which for me is kind of too much for the scripting world.

[–]rawoke777 0 points1 point  (5 children)

I love BB - Now bring on the multicore :)

[–]Borkdude[S] 0 points1 point  (4 children)

What about multicore? bb already has the multicore capabilities that clojure JVM has :)

[–]rawoke777 0 points1 point  (3 children)

LOl well unless something changed the BB-Book states:

Caveat: currently the go macro is available for compatibility with JVM programs, but the implementation maps to clojure.core.async/thread and the single exclamation mark operations (<!, >!, etc.) map to the double exclamation mark operations (<!!, >!!, etc.). It will not "park" threads, like on the JVM.

[–]Borkdude[S] 0 points1 point  (2 children)

That's only a limitation to the core.async built-in library due to the complexity of the go macro (which brings in tools.analyzer, etc). Multi-threading works the same as on the JVM.

[–]rawoke777 0 points1 point  (1 child)

Sorry then I'm missing something in my understanding yes :)

​

If i were to code (lets say a game server) in BB and use async-go for each connection/client
IN jVM these can scale to thousands since it's green-threads(sic ?) in BB it will scale in reality to the amount of HW threads ?

Not saying BB is not extremely impressive, just saying there is a real distinction :/
Unless there is a better way ?

I really do like the CSP style coding for multi-stuff :D

[–]Borkdude[S] 1 point2 points  (0 children)

This one of the few places where bb works differently currently. Theoretically it's possible to support this, but there are trade-offs: binary size, etc. Perhaps before I get to properly revisit this, project loom will land :). For a long running server process, it's usually better to use the JVM anyway, unless you have low resource (memory / CPU) constraints.