That's fair, I haven't tried D yet but I've heard good things about it. One thing Go's really good at is web services, and from what I've seen D seems to be a bit lacking here. But in general D seems more versatile than Go.
Actually yes I did forget about BetterC and it has been on my radar for a while. I have played with D before and honestly out of all the options in this space I've found it's probably the one I would go for on a project. It seems to strike the best balance between productivity and performance for me, the runtime seems much less magical than Go. I will definitely check out BetterC!
Anything of note between the two which you found favorable? I am early-days into designing a Dokku backed system. Dokku has a lot going for it that makes it appealing to me, but happy to learn what I am missing.
I'm fairly familiar with both V and D (even made some minor contributions to the V compiler), and I can't think of a single notable feature that isn't also available in D. V has a more modern and straightforward syntax, but that's the only major advantage imo. In terms of what you can _do_, I'm pretty sure D is almost strictly more powerful.
V can produce JavaScript, and it has an interpreter, but those are pretty experimental features. V has built in markup templates (like Mustache but worse), basic built in JSON reflection (D's CTFE can implement this), and built in portable inline SQL (for some reason), but that might be less desirable than targeting one specific ORM with its entire feature set. V also has a built in Sokol shader compiler, and can run `.vsh` files in a special script mode that works very slightly differently than normal V, but those aren't exactly killer features compared to D imo.
They're pretty equivalent though. I think DO has the advantage by providing a $5 plan as well for those that are new or what to experiment new stuff on smaller servers first (which is what I do myself).
Dyalog appears to be more popular with conferences and more products, but it costs $1k ish for a commercial license and nobody else can run your code without a license and server licenses aren't cheap. It also pretty much needs a special keyboard and a key mapping. J is free for pretty much everything and uses standard characters (although I really like the APL characters). I think they're both nice.
The beginner friendly is important. I use code-d because it provides a better out of the box experience, providing dub build and run tasks. In DLS I either only get the building task or have to set them up myself.
* vs Nango - we think they have great support for OAuth management and do support more APIs than ours on the surface (atleast at the moment).
Nango is based on Pizzly an existing OSS project which they built on top of. We're building it from the ground up.
Even though they seem to have more integrations, our integration support is better than them in terms of the depth of use-cases allowed (more standard objects supported, custom properties, field mapping support, custom objects (soon) etc).
A few prospects of ours tried out Nango for this use-case and then came to us eventually.
* vs Merge - we'd be able to fly past the number of integrations offered by them being an OSS product especially because of community contributed integrations. Being a developer first product, open-source is the way to build the best product in this category.
Integrations inevitably have edge cases that you would run into and you as a customer might require Merge to behave in a certain way. The typical response at a closed-source SaaS company would be that its on "their roadmap", never to get back again. This holds you tightly with their roadmap velocity and you're locked into a vendor.
Being an open-source product you, the engineer, will be able to fix or add integrations right away in the worst case if nothing else. This way of operating is very powerful we think.
I think they all serve different use cases. I'm not sure I could say one is more promising than another, because they're _all_ promising, and I don't see them as being in direct competition with each other.
I updated the comparison, I think you'll find it more compelling in terms of stability and performance.
To summarize, they're about equal in terms of performance but I'd argue my library wins on stability and maintainability as the minimal API enables a tiny codebase, which means less docs, less tests and most importantly, less bugs.
reply