From what I can tell, the new HDK replaces most functions from the previous HDK with macros. Besides potential (small) performance improvements, does the macro-ization of the API serve any purpose? Macros are harder to predict and provide much less type information to automatic documentation tools and language servers. Even if macros are the most efficient way to make direct calls into Wasmer, I still feel like functions wrapping those macros would be a better ergonomic choice for the HDK. Just wondering what the rationale was behind making everything a macro.
4 Likes
@MightyAlex200 I was wondering this myself. The lack of all the Intellisense features for the api itself seem like a real let down.
1 Like
what are you comparing to?
the latest version of the HDK has less macrology than previous versions
we will probably get everything down into functions at some point
I meant comparing the new hdk3 from Holochain RSM to the hdk currently on docs.rs (hdk2?) from Holochain Redux. It looks like nearly every function from hdk2 which has been implemented in hdk3 is implemented as a macro.
I’m glad to hear that it’ll all be turned into functions eventually, though. IMO, the developer experience when compared with frameworks for creating client/server applications (e.g. Ruby on Rails) will be a huge factor in Holochain’s adoption. It’s advantages from the developer’s point of view are stated very well in the current developer docs website: “no infrastructure to support, no databases to secure.” And a big part of reducing developer friction is having a simple and ergonomic hdk.
But I’d still really like to know why the current API was created this way, if you happen to have any insight on that.
i wrote hdk3 so i have some insight 
of course, dev experience is critical, i appreciate the feedback
hdk2 only works if you put everything inside a single root macro, and it doesn’t work at all if you don’t have a running conductor underneath it (hdk3 should be able to mock the conductor in the future) - it’s monolithic and inflexible under the hood, regardless of what the end-user-dev-experience looks like
hdk3 is a layered approach, going from messing around with raw binary data across the host/guest, up to serialization allowing for rust types and Result return values, up to the ribosome that dispatches arbitrary host functions, up to thin sugar macros (which is what you’re seeing) that wrap that
one of the main things that has been a pain is juggling trait implementations across the host and guest boundary, while respecting the need to allow for wasm development without the HDK - there is the rust orphan rule to deal with, and also i didn’t want want to force too much high level stuff outside the HDK, because technically all you need is the holochain_wasmer_guest and holochain_serialization crates if you want a more minimal interface into the host
if there’s pull for it from devs, i can add another layer that would look something like what you’re expecting, probably as an extension trait in the HDK so the functions would be methods on the types themselves, something like this (off the top of my head):
let foo: MyType = ...;
let entry: Entry = foo.try_into()?;
entry.create()?;
let fetched_entry = Entry::get(entry.hash()?)?;
let fetched_foo: MyType = fetched_entry.try_into()?;
assert_eq!(fetched_foo, foo);
it’s not just the macros getting in the way here, there’s a bit of outstanding awkwardness about moving between Element and Entry because the former represents the mapping between source chain and DHT behaviour, but the latter is what you need for app-specific types/values
but yeah, no fundamental reason not to do it, just time and prioritisation like anything else 
2 Likes
I would like that extra layer very much, but I’m sure you have much more important things to be doing than that, don’t let me stop you! 
And it’s very nice to hear that hdk3 is so much more flexible. This whole rewrite seems like a huge weight lifted off everyone’s back. Thanks for taking the time to explain this stuff to me, I really appreciate it.
2 Likes
i don’t use an IDE so i’m not feeling the pain, but you’re not the first to complain about the macros and likely not the last haha, i’m sure it will happen sooner or later 
currently working on exposing the keystore to wasm and removing libsodium to make it easier for mac os developers to work with core if they don’t know how to install/configure libsodium themselves, also getting a benchmarking server deployed so we can track performance of system components against github PRs - probably need to live with the macros a little bit longer til these things land at least
3 Likes