←back to thread

jank is C++

(jank-lang.org)
252 points Jeaye | 3 comments | 11 Jul 25 17:22 UTC | HN request time: 0.001s | 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(8): >>44535506 #>>44535588 #>>44535621 #>>44535873 #>>44535967 #>>44536143 #>>44539903 #>>44540443 #
o11c ◴[11 Jul 25 18:43 UTC] No.44535621[source]▶
> the lack of standardization for name-mangling, or even a way mangle or de-mangle names at compile-time.

Like many things, this isn't a C++ problem. There is a standard and almost every target uses it ... and then there's what Microsoft does. Only if you have to deal with the latter is there a problem.

Now, standards do evolve, and this does give room for different system libraries/tools to have a different view of what is acceptable/correct (I still have nightmares of trying to work through `I...E` vs `J...E` errors) ... but all the functionality does exist and work well if you aren't on the bleeding edge (fortunately, C++11 provided the bits that are truly essential; everything since has been merely nice-to-have).

replies(2): >>44535879 #>>44538499 #
mort96 ◴[11 Jul 25 19:11 UTC] No.44535879[source]▶
Like many things people claim "isn't a C++ problem but an implementation problem"... This is a C++ problem. Anything that's not nailed down by the standard should be expected to vary between implementations.

The fact that the standard doesn't specify a name mangling scheme leads to the completely predictable result that different implementations use different name mangling schemes.

The fact that the standard doesn't specify a mechanism to mangle and demangle names (be it at runtime or at compile time) leads to the completely predictable result that different implementations provide different mechanisms to mangle and demangle names, and that some implementations don't provide such a mechanism.

These issues could, and should, have been fixed in the only place they can be fixed -- the standard. ISO is the mechanism through which different implementation vendors collaborate and find common solutions to problems.

replies(3): >>44536325 #>>44536604 #>>44537468 #
vlovich123 ◴[11 Jul 25 20:04 UTC] No.44536325[source]▶
> Anything that's not nailed down by the standard should be expected to vary between implementations.

When you have one implementations you have a standard. When you have two implementations and a standard you don’t actually have a standard in practice. You just have two implementations that kind of work similarly in most cases.

While the major compilers do a fantastic job they still frequently disagree about even “well defined” behavior because the standard was interpreted differently or different decisions were made.

replies(2): >>44536495 #>>44537324 #
1. SideQuark ◴[11 Jul 25 20:28 UTC] No.44536495[source]▶
> When you have two implementations and a standard you don’t actually have a standard in practice

This simply isn't true. Plenty of standardized things are interchangeable, from internet RFCs followed by zillions of players and implementations of various RFCs, medical device standards, encryption standards, weights and measures, currency codes, country codes, time zones, date and time formats, tons of file formats, compression standards, the ISO 9000 series, ASCII, testing standards, and on and on.

The poster above you is absolutely correct - if something is not in the standard, it can vary.

replies(1): >>44537782 #
2. vlovich123 ◴[11 Jul 25 23:17 UTC] No.44537782[source]▶
Lots of things have standards that are mostly interchangeable. But pretending like the implementations don't interpret standards differently and have important differences is naiive. This is doubly so for language implementations which frequently leave things as "implementation defined". Clang and GCC have intentionally made significant efforts to minimize their differences which is why it's less noticeable if you're just swapping between them (it didn't start out this way). MSVC has not made these efforts. Intel abandoned their compiler for Clang. So basically you already have MSVC & clang/GCC as dialects, ignoring more minor differences that readily exist between clang and GCC.

Compare this with languages like Zig, Rust, and Python that have 1 compiler and doesn't have any of the problems of C++ in terms of interop and not having dialects.

Java is the closest to C++ here but even there it's 1 reference implementation (OpenJDK that Oracle derives their release from) and a bunch of smaller implementations that everyone derives from. Java is aided here by the fact that the JDK code itself is shared between JVMs, the language itself is a very thin translation of code --> byte code, and the language is largely unchanging. JavaScript is also in a similar boat but they're aided by the same thing as Java - the language is super thin and has almost nothing in it with everything else deferred as browser APIs where there is this dialect problem despite the existence of standards.

replies(1): >>44540727 #
3. suprtx ◴[12 Jul 25 09:48 UTC] No.44540727[source]▶
HN is a censorship haven and all, but I'd like to point out just one thing:

>Compare this with languages like Zig, Rust, and Python that have 1 compiler and doesn't have any of the problems of C++ in terms of interop and not having dialects.

For Python, this is straight up just wrong.

Major implementations: CPython, PyPy, Stackless Python, MicroPython, CircuitPython, IronPython, Jython.