7 ms·
FIDL could become the defacto standard for cross language communication. I really like where fuchsia is headed. Edit: I say this because fuchsia seems to be an
by isaacimagine 5y ago
FIDL could become the defacto standard for cross language communication. I really like where fuchsia is headed.
Edit: I say this because fuchsia seems to be an attempt to build an OS from scratch. Introducing a new IPC layer built specifically for the permissions-based language agnostic model of the zicron microkernel will make cross language/cross application interoperability way easier.
- pjmlp 5y agoIt is just yet another IDL. Sun RPC, DCE, CORBA, COM, D-BUS, gRPC, AIDL, XPC,.....
- amitport 5y agoWSDL
- raywu 5y agohttps://xkcd.com/927/ https://xkcd.com/927/
- salgernon 5y agoMIG for mach
- zeusk 5y agoCOM uses MIDL btw
- pjmlp 5y agoSure, I should have been more precise.
- helloooooooo 5y agoCOM/MS-RPC/MIDL are all different things. COM is build on top of MS-RPC and MS-RPC use MIDL to describe their protocol
- __d 5y agoAnd MS-RPC and MIDL are derived from DCE's RPC and IDL. DCE's RPC and IDL were derived from Apollo's NCS RPC and IDL. I'm unaware of a direct link between NCS and Mach, but Mach's RPC and Matchmaker IDL (and the 'mig' tool) I think pre-dated NCS? Ironically, they're the basis for Apple's XPC today.
- hestefisk 5y agoXML-RPC
- wiz21c 5y agoI thought I would be old when I would be able to understand such a statement... I'm old :-)
- deleted 5y ago[deleted]
- pantulis 5y agoASN.1
- spacemanmatt 5y ago...will be around when roaches and x509 certs inherit the earth
- jra_samba 5y agoUgh. An utterly unparsable language designed to insert security-holes into applications using it :-).
- pantulis 5y agoI had to decode an ASN.1 message and I remember it was easier to reverse engineer the bytestream rather than understanding the spec.
- nly 5y agoCapn'Proto would be the closest thing to FIDL that I am familiar with. It has a capability / interface passing mechanism. DBus as well, but DBus is horrible.
- Cthulhu_ 5y agoUnfortunately in a lot of microservices architecture, there's REST/JSON as well. Wouldn't be surprised if that's used on local machines as well.
- sreevisakh 5y agoA lot of terminal programs already use json over stdin and stdout, making it possible to create very long chain of piped programs. Besides the power of jq to filter that data, jc makes it possible to convert output of many classic program to json.
- throwaway4good 5y agoYep. And now there is a fun build step for translating these interface definitions into C++, Dart, Java ... plus a ton of glue code, some of it probably generated. Instead of creating a new language for interface definitions; why not just use an existing general purpose language? C++, Objective-C, Java, TypeScript ... Or take this new language you have created and extend it with control structures and other basic language features, and write the OS in that.
- Too 5y agoHehe, this is the opposite route, with same destination, as the rant on C headers as an IDL, from todays front page. https://news.ycombinator.com/item?id=30704642 https://news.ycombinator.com/item?id=30704642 “C Isn't a Programming Language Anymore”
- throwaway4good 5y agoSure - that is why I would go for last suggestion if I were to build a new OS: Build a new language first.
- throwaway4good 5y agoFor an example of a language made for building an operating system / an operating system made for a language: https://en.wikipedia.org/wiki/Oberon_(programming_language) https://en.wikipedia.org/wiki/Oberon_(programming_language) https://en.wikipedia.org/wiki/Oberon_(operating_system) https://en.wikipedia.org/wiki/Oberon_(operating_system)
- ptsneves 5y agoTempleOS and HolyC: https://en.wikipedia.org/wiki/TempleOS https://en.wikipedia.org/wiki/TempleOS
- throwaway4good 5y ago
- michael_j_ward 5y agoDon't forget Amazon's IDL smithy [0] https://awslabs.github.io/smithy/ https://awslabs.github.io/smithy/
- _448 5y agoAnd Dropbox's https://djinni.xlcpp.dev https://djinni.xlcpp.dev Now maintained by independent developers.
- deleted 5y ago[deleted]
- stusmall 5y agoWhat they are doing here isn't radically different or new. At the high level it looks very similar to Android's AIDL[1]. That said, I loved AIDL and had the same impression. I'd love for something like this become the new standard in IPC. It was such a pleasure to work with and I've missed it since I left Android OS work. 1. https://developer.android.com/guide/components/aidl https://developer.android.com/guide/components/aidl
- nyanpasu64 5y agoDoes FIDL have no more overhead than a non-inter-process statically dispatched C function call to a non-inlined destination? Does it enable the multi-language equivalent of allocating freely mutable data structures (like structs and std::vector and Rust enums) in one file, and accessing its fields or calling inlined methods in another file in the same language? One thing I've observed is Protobuf has caveats when mutated in-place (used as in-memory mutable application state) and Cap'n Proto is effectively impossible to resize objects, whereas std::vector<complex struct> is difficult to access across languages without treating it as a pointer to opaque type.
- surajrmal 5y agoNo, FIDL is optimized for IPC, not in process communication. That said I think it can be used quite well for use cases where you can stomach the overhead of an in process channel such as go channels or rust mpsc. Personally, I think channel based communication is one of the more viable cross language communication strategies.
- kentonv 5y ago> One thing I've observed is Protobuf has caveats when mutated in-place (used as in-memory mutable application state) and Cap'n Proto is effectively impossible to resize objects To clarify slightly: Encoded Protobufs cannot be mutated in-place at all. You have to parse into language-specific in-memory objects, mutate those, and then serialize again. Cap'n Proto does support in-place mutation, with the caveat that if any object changes size, it'll be moved to the end of the message, leaving behind a "hole". You can "garbage collect" the holes by copying the whole tree into a new message, which should be much less expensive overall than parsing and serializing the whole message as Protobuf would require.
- nyanpasu64 5y agoSorry for that. In any case, is it practical to design cross-language FFI ABIs with a "wide" API like C++ or Rust code, without constraining interaction through a narrow inexpressive waist like text over HTTP, bytes or serialization over system calls or IPC, or arguably COM opaque objects?
- riedel 5y agoThis is very much like the DICE idl for the l4 kernel [1] . [1] https://wiki.tudos.org/Dice_IDL_compiler https://wiki.tudos.org/Dice_IDL_compiler