hckrnws

Congratulations on the achievement!

Ever since I got into Clojure I have wanted what you are building. I love the language, I love the collections, but I don't love waiting for program startup.

I can't wait until Jank is complete!

In fact, how can we help at the moment?

Thanks! I'm exciting to get it released.

With the three mentees I have, plus my own tasks cruising along, the best way people can help is to build up interest and visibility in jank. Follow, repost, share, like, etc. Once jank is released, I want to make the largest splash we can.

If you have the financial means to sponsor my work, that also helps. I'm quitting my job at EA in January to focus on jank full-time for 2025 and I'd really like to secure some form of stability in terms of funding by the end of 2025.

> but I don't love waiting for program startup.

Question for curiosities sake, how many times per day do you start this program?

I've moved most of my tiny CLI utilities from Clojure to Babashka (with it's handy "cat together bb + your script" workflow) but all the rest is still Clojure, as I don't restart them very frequently.

Thank you for the suggestion. I am aware of (and use, where appropriate) babashka, but there is a certain part of me that just wants a consistent environment rather than context switching between 'full clj' and 'bb'.

That said, I love babashka and Michiel Borkent's work a great in general.

Clojure is a quirky language, and I really enjoyed writing a proof-of-concept microservice with it back in 2015-era when everyone was shouting "Scala is the way!" I was able to prototype with it and stand it up in a weekend. With the tiniest bit of code, I had the exact service I needed. It ended up in production after only spending a couple weeks, most of which was spent wrapping my head around Docker and Mesos that we used to run the .jar.

However, it's a quirky language. So, my quick take, as a glue layer on top of the JVM, it was quite powerful, but jank has me scratching my head. LISP doesn't really read well the bigger the codebase, and as something to write software in standalone environment, it makes me a bit hesitant.

I sometimes would hit walls, because in real world software, you need persistent state. Functional software, for obvious reasons, fights against that, and so modeling state is actually quite difficult. This is where I think, as a small layer on top, it's fast and effective. I would just not want to write more than a few files with it though. Happy to follow along this project though and see where it goes.

Often times, when people learn Clojure, they are also learning functional programming and lisp and data-oriented programming and interactive programming all at once. Writing Clojure requires a shift in perspective, coming from the imperative and object-oriented paradigms, and without that shift, even basic programs can seem impossible to build. This shift was very difficult for me, coming from C/C++/C#/Rust, and I've spoken with many others who've felt the same. I suspect, when you talk about hitting walls due to state, it's due to that perspective shift not being complete.

Does that mean I'm saying Clojure is the best lang for everyone and it's their fault if they don't get it yet? No, certainly not. We need to do better with that, in the Clojure world, to make that bridge easier to cross. But, having fought my way across that bridge, I can confidently say that mutable state is no problem in Clojure. We have first-class support for it and that support is thread-safe by default. Unlike something like Haskell, effects aren't scary and don't need to be wrapped. They can be adhoc.

jank inherits all of this and just brings it to the native world. That means lighter binaries, faster startup, and easier interop with native libs. Aside from that, it's Clojure.

> I sometimes would hit walls, because in real world software, you need persistent state. Functional software, for obvious reasons, fights against that, and so modeling state is actually quite difficult.

I haven't felt this, Clojure has good primitives for dealing with state, both temporary and more permanent. The biggest difference from (most) mainstream languages is that it's very explicit what has state and where you're mutating it. But personally I feel like that makes it easier to manage complicated state relationships, rather than harder, since it's typically isolated in smaller parts.

Clojure offers so many ways for you to manage state for different use cases. Atoms, volatiles, agents, vars, refs.

Functional programming never fights against persistent state. It simply carves out the functionality by use cases and offer you more choice in managing it.

    LISP doesn't really read well the bigger the codebase

Hi Jeaye, love what you and the other contributors are doing with jank. The further proliferation of clojure dialects can't happen quickly enough imo.

Do you have any "killer app" style use cases in mind for jank? Babashka is great in CLI/FaaS settings, native Clojure is great for "situated" programs that can afford a JVM startup and some memory overhead

Which settings are you particularly excited to use jank in?

I may be biased, having built a career in game dev, but I would love to see people developing games using a REPL. Many games these days use Lua or similar for scripting logic, since it doesn't need to be written in C++, it can change at runtime, and it's reasonably fast. jank is all of those things, too! I think, if we can get jank into Unreal Engine, Unity, Godot, etc so that people can use their existing tool set, write functional code, and use interactive programming, it could be a game changer for game dev.

Another great use case, I think, is desktop GUI dev. Outside of Humble UI, which is still very new, Clojure's GUI story has been quite bad. The native world has all sorts of GUI options though and jank will be introducing them to Clojurists.

I think jank will be a good option for anyone who wants to use certain native libraries along with their Clojure programming. Jack Rusher, for instance, has said there are native graphics libs he'd love to use and jank is a promising way to do that.

Finally, I aim to provide a cargo-like experience (if you're familiar with Rust) for jank. This should make building native apps easy. As I alluded to in my post, building C and C++ apps is a pretty terrible experience. If jank can make that twice as easy, for example, it could be that native devs end up preferring it as their project baseline. Since jank allows for arbitrary C++ to be included alongside the jank sources, and required as though it's a Clojure namespace, it actually ends up being a pretty sane way to write programs which involve a lot of C++.

With all of that said, I don't imagine I'll be working on anything other thank jank for quite some time. I think of these mainly as things I'm excited to see others do. :)

This is literally why I just downloaded it 2 days ago, but I was having issues compiling it.

I'm very interested in simulation games with a lot of numeric calculation behind the scenes.

jank is not easy to use yet. Removing vcpkg and the PCHs certainly helps with compilability, but with jank still being pre-alpha, it takes an adventurous spirit to get it going. Hang tight and we'll have binary releases coming next year!

Didn't get to meet you at HoC but I wanted to say thank you for working on jank. It's going to bring Clojure into so many new places typically reserved for compile-to-binary languages. Awesome work!

Oh, darn! Sorry to've missed you, Chris! HoC was a blast. Thanks for following along!

awesome stuff. keep it up!