Comments URL: https://news.ycombinator.com/item?id=46903800

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46593615

Points: 4

# Comments: 0

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.

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.

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.

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

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.

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.

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.

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

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

Comments URL: https://news.ycombinator.com/item?id=45465501

Points: 40

# Comments: 1

This is misleading. Having done a great deal of both (as jank also supports C++ codegen as an alternative to IR), if the input is a fully analyzed AST, generating IR is significantly more error prone than generating C++. Why? Well, C++ is statically typed and one can enable warnings and errors for all sorts of issues. LLVM IR has a verifier, but it doesn't check that much. Handling references, pointers, closures, ABI issues, and so many more things ends up being a huge effort for IR.

For example, want to access the `foo.bar` member of a struct? In IR, you'll need to access foo, which may require loading it if it's a reference. You'll need to calculate the offset to `bar`, using GEP. You'll need to then determine if you're returning a reference to `bar` or if a copy is happening. Referencing will require storing a pointer, whereas copying may involve a lot more code. If we're generating C++, though, we just take `foo` and add a `.bar`. The C++ compiler handles the rest and will tell us if we messed anything up.

If you're going to hand wave and say anything that's building strings is error prone and unsafe, regardless of how richly typed and thoroughly analyzed the input is, the stance feels much less genuine.