crabby is a language, like c++, offers zero cost abstractions. unlike c++, crabby has linear and affine types, and there's a single ownership model for data, enforced by the compiler. crabby even has a macro system, too.
for some reason, crabby is very popular with both socialists who like the gift economy, and libertarians who really like bitcoin, but i digress, i really want to talk about the zero cost abstractions bit, but first let me talk about qt
to say "qt is a cross platform gui c++ library" is to misunderstand qt. it's more than just a library, or even a framework, it's a whole runtime.
there's strings, lists, and other collections, there's an event loop and message framework, and a network io library that's tightly integrated. there's a metaobject library that provides reflection, amongst other things, and there's also a gui library that even has a web browser component. this is why qt is so big.
when you use qt in a project, the actual language you're using with it doesn't matter as much. it'll be easier to work with other qt projects than ones written in the same language, as their code will also be full of QStrings and QLists and QFiles
in some ways, this is a showcase of zero cost abstraction in C++. you can build a wholly new language runtime, if you need it, and there isn't a performance overhead for doing it your own way either.
on the other hand, maybe qt could have been written in something like java, and might have been a bit less work. there's an object system, there's reflection, there's even common types for iterators and observers and collections that all work together. qt wouldn't have needed to implement the universe if most of it was set out in the standard library.
anyway, enough about qt, let's go back to crabby.
let's think about a world where qt was implemented in crabby, not c++: ahhh. we could enforce ownership on qwidget dom trees, we could use macros instead of a preprocessor to annotate objects, and maybe we could even use async and await for the event loop and message processing. lovely.
since crabby also touts zero cost abstractions, our crabby runtime wouldn't be at any major disadvantage to a c++ version. strike one up for the crabby strike force. pew pew. just one small detail to note:
much like the c++ version, the zero cost abstractions are only being used to provide features that you can take for granted in other languages: like objects or reflection. if crabby provided those features out of the box, qt wouldn't really need much in the way of the zero cost abstractions.
still, the idea of rewriting qt in crabby isn't half bad. writing safe components in a larger framework is one of the places where crabby has made an impact before. crabby doesn't come with an object system or reflection, because it's more often than not, embedded into a larger system with it's own rules and ideas about how those things work.
crabby is was designed around building components and [hold up i'm just getting a text message] i've been informed that many people now assert crabby to be a language for application development and there's at least two competing event loops wait no there's a new one on the front page of hacker news. no idea how many json libraries.
anyway, my point is this:
zero cost abstractions make sense when people are building runtimes in your language, and zero cost abstractions make sense when you're embedding your language into a larger system, but sometimes when you cut out a feature, you'll end up with fifteen different incompatible ones in the gap.
c++ spawned a thousand object and event systems and it's highly likely that crabby users will tread the same path, footstep by footstep.
i really do wish rust came with some opt-in reflection and object models, but then again, it's kinda funny that when a language is proud of not having a feature, the first thing any serious user does is add it back in.
either way, i'm glad qt could be implemented in c++, but i'm even happier that i can use qt in a language that isn't c++
