Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I've never met a FFI I didn't come to loathe

I've felt that pain. With so many new programming languages popping up, I've been wondering if the next killer programming improvement isn't strictly a programming language at all, but rather something that rethinks the linker, manages execution, and facilitates interfaces between larger blocks of code (maybe in multiple languages).



Yep me too. People are too quick to dismiss the cross language issues which can in my experience can slowly erode the benefit. Typically you use an FFI to access particular functionality offered in libraries/classes only offered in another language. In my experience it is only a temporary solution, a does-it-work test. After that you need to recode. Having said that, in my experience Lua(JIT) does this pretty well with C libraries but Lua was designed as the scripting companion to C from day one.

The JVM offers a better place to tackle these issues. Scala and Java cross calling is often more than adequate. Perhaps a Julia compiler for the JVM could be a step in the right direction.


I've heard many very smart people (professors, leaders of large HPC efforts, "language geeks") express the same sentiment over the years. Unfortunately, it's a btch of a problem, as attested to by the veritable graveyard of half-baked solutions out there. Apple's "Bridge Support" is the closest thing I've seen to success (haven't worked with MS's CIL) and it leaves much to be desired.

I'm not sure there is any way around the impedance mismatches between languages. They're all slightly different for a reason. Perhaps clean C APIs are the best we can hope for.


I keep hoping that some accessibility upgrade comes to the linker akin to how LLVM made compiler infrastructure more accessible, might make FFI bridging more automated. For example, if GDB can access and take apart C structs an automated way, why is FFI coding always seem to have programmers do a lot of mechanical interfacing work.

Not that all the other JVM, CIL, etc aren't approaches that yield some improvements, but something that upgrades capability or accessibility at the level of the ABI linkage level is going to be a wider impact.


> I'm not sure there is any way around the impedance mismatches between languages.

CLR has an approach for that by defining what is known as CLS, Common Language Subsystem.

Likewise they have a similar approach on WinRT, known as Type Providers.

However they also have their impedance mismatches, as you are only allowed to use types that are usable by all languages that target such runtimes.

The benefit is that they still allow for an higher level of code abstractions than pure C functions.


You mean like OS/400 TMI, .NET, JVM?


COM was actually not a bad model. Sadly the closest thing is HTTP and JSON right now.


s/was/is/

COM is the basis for most Windows APIs since XP, and the basis for the new WinRT runtime.

Lets see how it might look like with Windows 9.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: