←back to thread

jank is C++

(jank-lang.org)
257 points Jeaye | 3 comments | 11 Jul 25 17:22 UTC | HN request time: 0.446s | source
Show context
johnnyjeans ◴[11 Jul 25 18:29 UTC] No.44535498[source]▶
I'm not surprised to see that Jank's solution to this is to embed LLVM into their runtime. I really wish there was a better way to do this.

There are a lot of things I don't like about C++, and close to the top of the list is the lack of standardization for name-mangling, or even a way mangle or de-mangle names at compile-time. Sepples is a royal pain in the ass to target for a dynamic FFI because of that. It would be really nice to have some way to get symbol names and calling semantics as constexpr const char* and not have to deal with generating (or writing) a ton of boilerplate and extern "C" blocks.

It's absolutely possible, but it's not low-hanging fruit so the standards committee will never put it in. Just like they'll never add a standardized equivalent for alloca/VLAs. We're not allowed to have basic, useful things. Only more ways to abuse type deduction. Will C++26 finally give us constexpr dynamic allocations? Will compilers ever actually implement one of the three (3) compile-time reflection standards? Stay tuned to find out!

replies(9): >>44535506 #>>44535588 #>>44535621 #>>44535873 #>>44535967 #>>44536143 #>>44539903 #>>44540443 #>>44542272 #
1. almostgotcaught ◴[11 Jul 25 18:30 UTC] No.44535506[source]▶
> LLVM into their runtime

they're not embedding LLVM - they're embedding clang. if you look at my comment below, you'll see LLVM is not currently sufficient.

> [C++] is a royal pain in the ass to target for a dynamic FFI because of that

name mangling is by the easiest part of cpp FFI - the hard part is the rest of the ABI. anyone curious can start here

https://github.com/rust-lang/rust-bindgen/issues/778

replies(2): >>44535663 #>>44535774 #
2. Jeaye ◴[11 Jul 25 18:48 UTC] No.44535663[source]▶
To be fair, jank embeds both Clang and LLVM. We use Clang for C++ interop and JIT C++ compilation. We use LLVM for IR generation and jank's compiler back-end.
3. johnnyjeans ◴[11 Jul 25 19:00 UTC] No.44535774[source]▶
> they're not embedding LLVM - they're embedding clang

They're embedding both, according to the article. But it's also just sloppy semantics on my part; when I say LLVM, I don't make a distinction of the frontend or any other part of it. I'm fully relying on context to include all relevant bits of software being used. In the same way I might use "Windows" to refer to any part of the Windows operating system like dwm.exe, explorer.exe, command.com, ps.exe, etc. LLVM a generic catch-all for me, I don't say "LLI" I say "the LLVM VM", for example. I can't really consider clang to be distinct from that ecosystem, though I know it's a discrete piece of software.

> name mangling is by the easiest part of cpp FFI

And it still requires a lot of work, and increases in effort when you have multiple compilers, and if you're on a tiny code team that's already understaffed, it's not really something you can worry about.

https://en.m.wikiversity.org/wiki/Visual_C%2B%2B_name_mangli...

You're right, writing platform specific code to handle this is more than possible. But it takes manhours that might just be better spent elsewhere. And that's before we get to the part where embedding a C++ compiler is extremely inappropriate when you just want a symbol name and an ABI.

But this is besides the point: The fact that it's not a problem solved by the gargantuan standard is awful. I also consider the ABI to be the exact same issue, that being absolutely awful support of runtime code loading, linking and interoperation. There's also no real reason for it, other than the standards committee being incompetent.