Hacker Newsnew | past | comments | ask | show | jobs | submit | joonas's commentslogin

In similar vein, I’d always thought Redka (https://github.com/nalgeon/redka) was a neat idea since it gives you access to a subset of the Redis API backed by either SQLite or Postgres


Came here to post this. I’m wondering how Redka will compare with Postgres (and Redis) in terms of performance though.

Edit: https://antonz.org/redka/#performance


The timing of this release couldn't have been more fortuitous for me, I was just recently getting myself reacquainted with the options available for background processing in the Go landscape, and I was specifically looking for options that could be integrated as a library and were built on top of a RDBMS (specifically SQLite + Postgres for different use cases) as opposed to something like a redis/valkey.

Edit: I'm also curious if anyone is aware of companies or open source projects that are building with River?


As one of River's creators, I'm aware of many companies using it, including names you've heard of :) One cool open source project I've seen recently is this open source pager / on-call system from Target called GoAlert: https://github.com/target/goalert


Kudos for making this freely available, I was initially delighted to find out that there was a StepSecurity maintained alternative for the dorny/paths-filter action[1] as that seemed like a reasonable alternative to migrate to, but ended up being disappointed once I realized that it requires a subscription to use[2]

[1]: https://github.com/step-security/paths-filter [2]: https://github.com/step-security/paths-filter/blob/b251c10d0...


While edge functions and durable objects are both excellent examples of technologies that could be built using wasmCloud, they are (assuming we’re talking about either a CDN provider like Cloudflare, Fastly, Akamai or Cloud providers like AWS, Azure, GCP) not readily available in many environments.

An example brooksmtownsend linked to elsewhere in the thread is an industrial use case where one of the wasmCloud adopters is shipping a device running wasmCloud (and thus their Wasm components) locally within an industrial site: https://wasmcloud.com/blog/2024-10-22-webassembly-adoption-t...

So from a deployment perspective, not being tied to the public cloud/internet availability in general is a huge benefit.

But beyond deployment, due to the way wasmCloud is designed with the concept of capability providers and components, you are able to write providers that can integrate with any other existing protocols, services, software or hardware to make them available for your WebAssembly components to talk to.

In essence, you use WIT (think Protocol Buffers, but for WebAssembly) to describe the interface you would like your components to be able to call, and then you fulfill the interface from the providers and code generate the “guest” (or client-side) of the calling code for your WebAssembly components.

This means that you are not locked-in to the services and API's of your edge function provider and your function is portable to any cloud or edge.


Thanks, this helps a lot to understand it, feels quite exciting indeed.


One of the principles we do our best to follow as we build wasmCloud is the idea of "compatible with, but not dependent upon", and to that end we do in fact integrate very nicely with Kubernetes.

A recent blog post highlighted some of the work we’ve done to provide a Kubernetes Operator for wasmCloud: https://wasmcloud.com/blog/2025-01-09-wasmcloud-operator-bri...

This will provide you an equivalent experience to what you might expect from Kwasm, with the major difference being that you will not need to change the underlying Kubelet in any way while still getting the benefit of being able to deploy WebAssembly components natively on Kubernetes.


Congrats on the launch Bernard!

I've been keeping an eye on flawless since stumbling across your blog posts from last year, it's great to see more durable execution options entering the market.

Given that you're compiling functions down to WebAssembly, I was curious about which runtime did you end up going with for building out the platform?

I'm also curious about whether you had plans (or any that you would be willing to share anyway) around expanding the languages supported by Flawless beyond Rust any time soon?


All I can say is that my experience with Balanced has been most excellent, I really love what they do.

In my experience their team is extremely responsive and receptive to feedback, to the level customers can (and do) have impact on the product itself, that's pretty huge in my book.

Very happy to see them doing so well and growing.


As someone who has previously used Balanced and played around with Stripe enough to get a feel for it, I feel like I need to chime in here.

Balanced initially reached out to me, and I initially somewhat dismissed them, because I didn't have the time to look in to their platform as I was busy building a marketplace product for which we thought we had already picked the payment provider for, PayPal.

However, few weeks later I decided to take the time to investigate Balanced's offering and I was quite simply blown away by what they had to offer at the time (since then their offering has significantly expanded). As a result, I decided to make some time to rewrite our payments to use their APIs, because they solved the one hard problem I had yet to solve, which is the payouts.

I distinctly remember that I had just spent the earlier part of that week going over the various alternatives to how we could handle payout, and none of them seemed optimal. While paypal certainly would've gotten the job done, it was far from ideal especially considering that our merchants would've had to sign up for a paypal account and the fact that they have a track record of mistreating individuals and businesses by freezing accounts and funds. The other alternatives I had considered would've been much more work to integrate with and would've probably eventually driven me up a wall.

This was the first thing that struck me as the truly valuable feature of their product.

When I actually began integrating with Balanced, my "developer relations" experience with Balanced has been quite the opposite. Heck, I had a phone call with one of the Balanced founders (Jareau) where he took the time to answer all of my questions and explain to me how everything worked. In addition, I was able to simply hop on to Balanced's IRC channel (#balanced on Freenode) and talk to their whole team right there and then in real time. When I had questions about any of the functionality, there would always be someone from Balanced's team available to answer my questions. I should also mention that even some people outside of Balanced (i.e. customers) are also helping out on that channel.

Yet again, I was impressed. I never had issues with getting the kind of support I needed from Balanced, they are very responsive and helpful in solving any problems I have encountered.

Not to knock on Stripe or anything, but I never quite felt like their product was suitable for the situation that Balanced is suitable, a marketplace that needs to do payouts (or nowadays I suppose anything that needs to payouts). I feel like Balanced really hits the sweet spot when it comes to payouts, and they continue to work hard on making sure that their product is the best that there is in that category, and I certainly think that is the case right now.

One thing that I think bears mentioning is the fact that Balanced is also very receptive to customer feedback. In my experience, they are constantly weighing out what's the next thing they should be building/doing to make their customer's lives easier, and so their process is very much driven by the feedback provided by their customers (check out their API docs github to see the process in action, https://github.com/balanced/balanced-api/issues)

Overall, I do think that Stripe and Balanced to have overlap in what they do for you (charging a credit card), but I also feel like both of them have their strengths in differing features. I do think that for marketplaces that need payouts, Balanced is vastly superior because of the feature set that they have built, but if you had to something like subscriptions, then Stripe would be the way to go.


There's plenty of good people at Balanced, but Stripe's Payout API is very capable and, in my experience, much more elegant to work with. To imply that Stripe is built just for charging cards is no longer true, as you can see in my review of the two APIs:

http://blog.chriswinn.com/working-with-stripe-payouts


I've heard this is a really good introduction book, http://www.amazon.com/Objective-C-Programming-Ranch-Guide-Gu...

Having read their Cocoa programming for OS X book (http://www.amazon.com/Cocoa-Programming-Mac-3rd-Edition/dp/0...), I can wholeheartedly recommend their books.


Having used Balanced for a couple months, I can attest to this, they are a fantastic bunch providing support wherever, whenever and in whatever way they can.


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

Search: