As much as any C++ project would, yes. That includes either through the C ABI or through the various C++/Rust interop mechanisms.

jank is Clojure and will track upstream Clojure development. I'm working closely with the Clojure team and other dialect devs to ensure this remains the case. I am leading a cross-dialect clojure-test-suite to help ensure parity across all dialects: https://github.com/jank-lang/clojure-test-suite We have support or work ongoing for Clojure JVM, ClojureScript, Clojure CLR, babashka, Basilisp, and jank.

With that said, jank will do some trail blazing down other paths (see my other comments here about Carp), but they will be optional modes which people can enable which are specific to jank. Clojure compatibility will remain constant.

JIT compiling C++ is definitely the slowest thing we do. However, we're working on two different codegen modes.

1. C++

2. LLVM IR

The IR is much faster to compile, but its perf isn't nearly as good. This is meant to be a nice trade off, during iteration, so that you can use C++ codegen for your release artifact, but stick with IR when you're REPLing. The IR gen is still unstable right now, for the alpha, but we'll have both solidified this year.

Carp is great and I would love to include a mode of jank which is very much Carp-esque. If you're interested in working together on this, please let me know.

Most of my contributions were to the stdlib so my knowledge of the implementation of the type system is limited sadly.

Maybe Erik, the creator, would be interested. I know he was looking at rewriting Carp in cpp at some point.

We have a working nREPL server, but it's not yet merged into the jank repo. https://github.com/kylc/try-jank

There's a Clang bug getting in the way of the progress we want, so we'll need to work around. There's a lot I'm juggling, but this is high priority.

Thanks for the broken link report. That should be fixed now.

No full-lang static type system. jank has seamless C++ interop and all interop is statically typed, but as soon as things get back into Clojure land, it's all dynamically typed and hella polymorphic.

I will be exploring optional static typing modes for jank in the future, a la Carp. That will not be this year, though.

Please link to https://book.jank-lang.org/ for anything related to the jank alpha. I wasn't quite ready to announce the alpha, but I appreciate that folks are excited. :)

There's just a couple more compiler features I wanted to get merged, but everything should be in order for folks to follow the book and try jank out.

Hi! I'm excited about jank and so I'm excitedly reading through the book you just linked. I noticed some grammatical errors. Will you consider PRs to the `book` section of the code, or would you prefer feedback in some other format in order to better maintain your authorial voice?

Hi! I'm happy to accept grammatical PRs to the book. You could also report issues via Slack or Github issue. I will not be accepting larger PRs to the book, to maintain a consistent voice.

Cool! I'm still reading, but when I'm done I'll open a PR for the few small issues I've seen.

Thanks for your work on jank! I hope the Alpha brings you lots of new users, useful bug reports, and some contributors. :)

big kudos to all involved

This is superb. Thank you for making it and licensing it MIT. I think this is a contender to replace the lexer within jank. I'll do some benchmarking next year and we'll see!

Wow, that is a greate news!) Thanks for looking at it from this perspective! There are some benchmarks already available in the project - https://github.com/DotFox/edn.c/blob/main/bench/bench_integr...

you can run it locally with `make bench bench-clj bench-wasm`

Let me know if I can do anything to help you with support in jank.

It looks like the key missing part which would be needed for a lexer is source information (bare minimum: byte offset and size). I don't think edn.c can be used as a lexer without that, since error reporting requires accurate source information.

As a side note, I'm curious how much AI was used in the creation of edn.c. These days, I like to get a measure of that for every library I use.

It should be easy to add source info for every token, some of them already keep both (size and offset) I can create a branch for that.

> I'm curious how much AI was used in the creation of edn.c

A fair amount. This is my first big public project written in pure C. I did consult LLM about best practices for code organisation, memory management, difference in SIMD instructions between platforms, etc. All the things Clojure developer typically don't think about (luxury of a hosted language). Ultimately, the goal was to learn some part of C programming, working reader is a side effect of that.

> These days, I like to get a measure of that for every library I use.

Btw, I'm curious, what kind of measuring you are looking for?

Oooo that’d be nice.

Yeah, this isn't quite C++ interop on its own. It's C++ interop via C, which is an incredibly pertinent qualifier. Since we go through C, opaque pointers are needed for everything, we can't stack allocate C++ values, we need to write extern C wrappers for everything we want to do (like calling member fns), and we don't get any compile-time type/safety checking, due to the opaque pointers.

Direct C++ interop is doable, by embedding Clang into Zig and using its AST, but this is significantly more work and it needs to be done in the Zig compiler. As a Zig user, going through C is about as good as you can do, probably.

It's a bit more than your typical "interop via C". With a "sized opaque" type you actually can stack allocate C++ values in Zig (and vice versa stack allocate Zig values in C++), i.e.

fn stackExample() void {

    var some_cpp_type: c.SomeCppType = undefined;
    c.some_cpp_type_ctor(&some_cpp_type);
    defer c.some_cpp_type_dtor(&some_cpp_type);

    // ...

}

Rocket League works just fine for me, via Proton. I have over 4k hours in, each one of them done from Linux.

BakkesMod also works, thanks to https://github.com/CrumblyLiquid/BakkesLinux

Rocket League has a platinum rating on ProtonDB: https://www.protondb.com/app/252950

Does that include multiplayer? As far as i know, multiplayer was killed a couple years ago, which is actually what i meant by “works on Linux”

Yeah I have hundreds of hours or more in Rocket League on Linux, all competitive multiplayer. I use the Heroic launcher: https://heroicgameslauncher.com/

YES! Use the Proton version, not the native Linux version.