I don't think Zeta is quite up to windsurf's completion quality/speed.
I get that this would go against their business model, but maybe people would pay for this - it could in theory be the fastest completion since it would run locally.
> the fastest completion since it would run locally
We are living in a strange age that local is slower than the cloud. Due to the sheer amount of compute we need to do. Compute takes hundreds of milliseconds (if not seconds) on local hardware, making 100ms of network latency irrelevant.
Even for a 7B model your expensive Mac or 4090 can't beat, for example, a box with 8x A100s running FOSS serving stack (sglang) with TP=8, in latency.
Running models locally is very expensive in terms of memory and scheduling requirements, maybe instead they should host their model on the Cloudflare AI network which is distributed all around the world and can have lower latency
I think there is a good chance that this design is more suitable for power uses.
My hunch is that typing 5 words could be faster than going through 3 menus and screens. I don't see this as a replacement for normal UI, but as an optional shortcut - if you're happy typing.
Thank you for the references. I agree there is a lot of room for innovation in this space.
Main differentiator here is as-you-type UI customization, and also in this case the UI isn't generative in the sense the options are hard coded - the LLM just chooses between them.
I think we'll see a mix of all of the above in the future as we take full advantage of LLMs.
https://www.metabolicmind.org is a non profit, with many MDs and PHDs dedicated to researching the link between metabolism and mental health, with a focus on keto diets.
Spotify has its own App Store, with an even worse experience for developers in my experience.
Rather than a published set of rules and fees for commercial apps, instead Spotify requires you contact them, and fees and rules are done behind closed doors, if you even get that far.
Since Spotify is throwing stones here, what are Spotify’s commercial rates for Spotify integrated apps in their App Store?
They seemed to have recently removed it. The link below shows what it recently looked like.
The main issue was if you want to make a commercial app, there are no publicly available commercial terms, and it is easy for Spotify to not offer commercial terms to apps/companies that may in some way increase the chance of competition with Spotify. For example, if you wanted to make an app that would allow you to export your playlists, Spotify may offer you terrible commercial terms or none at all.
It's not an app store. It's not like throwing stones from a glass house, because it's not an app store.
Most of the integrations do not have anything to do with using the copyrighted music, e.g. a playlist export app
Most Spotify integrations literally involve playing music through Spotify, so it's curious that you pick one of the very rare integrations that do not.
Spotify has its own App Store, with an even worse experience for developers in my experience.
Rather than a published set of rules and fees for commercial apps, instead Spotify requires you contact them, and fees and rules are done behind closed doors, if you even get that far.
Since Spotify is throwing stones here, what are Spotify’s commercial rates for Spotify integrated apps in their App Store?
Advantages for using Postgres ( assuming a double entry schema[1] ) and you're using Postgres for your main app db;
- You can do financial transactions inside business db transactions, and roll back both atomically
- Adding up numbers is one of the things computers are best at, and Postgres can easily handle a huge amount of financial transactions
- Re-use PaaS Postgres hosting/scaling/clustering/backups
- Easier integration with the rest of your app with foreign keys to relevant records relating to the financial transaction
- Easy integration with BI tools given Postgres is well connectable
It's dated, the API is a bit messy and needs work, as it was initially written 10+ years ago, but for a web based app I would choose a v2 of it over a non-postgres ( assuming you are using Postgres for your app ) solution.
I blogged about this recently - here's a DB schema that can do all of the double entry stuff with about 2 tables. I also have example queries for balance sheets and other useful bits:
I hadn't seen that gem before! My comment on most accounting tools is that they ignore the concept of "normal" account balances, which means they don't really think about "debits" and "credits". This is fine mathematically, of course, but makes it awfully difficult for accountants to understand how the software is supposed to behave!
We're running on mid-sized Postgres right now, but find that clickhouse (or duckdb) are something like 100x faster once we do GROUP BYs on 5M+ rows.
Incidentally, I just came across Journalize. But I'm struggling to understand what it's for. It might be helpful to say - either here, or on your homepage - who or what it is competing with. I'm probably not the exact target audience, but it seems to do more or less what Xero does for us (but I don't want to rule out that I just don't understand the homepage).
If your business generates a lot of transactions, to the point that you have a full time accounting or engineering staff whose job it is to wrangle 200MB excel files or complicated sql queries, then Journalize is for you.
We’re basically BI tailor made to create outputs that are relevant to accountants (we know what “depreciation” is supposed to look like) and let them take a monthly ledger entry and drill down to a specific user’s impact on the GL and tie it to the line of source data.
In this way, we’re doing the data engineering work, helping accounting teams have BI type tools to set up accounting rules, and giving transparency to “why” an aggregate number is correct.
I think they key part is "distributed financial accounting database". For anything that didn't need to be distributed to handle massive volume of transactions I'd also pick Postgres, but I can imagine there's a limit where that wouldn't work, and as soon as you need to do this in a distributed database things get exciting.
No experience with the linked gem but the description states
> While this gem acts like a double-entry bookkeeping system, as it creates two entries in the database for each transfer, it does not enforce accounting rules.
And that seems like a far cry from things like "rejecting transfers if the accounts involved would exceed their net debit or credit balances".
>> While this gem acts like a double-entry bookkeeping system, as it creates two entries in the database for each transfer, it does not enforce accounting rules.
> And that seems like a far cry from things like "rejecting transfers if the accounts involved would exceed their net debit or credit balances".
The READEME needs to be updated[1] for clarity. It doesn't enforce "accounting" rules, however The DoubleEntry gem has rules to optionally ensure a balance cannot go negative, and it also has an allowlist of allowed transfers ( which are defined by source account, dest account and code ).
> I think they key part is "distributed financial accounting database". For anything that didn't need to be distributed to handle massive volume of transactions I'd also pick Postgres, but I can imagine there's a limit where that wouldn't work, and as soon as you need to do this in a distributed database things get exciting.
That is why I qualified my statement with "you're using Postgres for your main app db".
For every financial transaction you'd likely have many more business logic level transactions, and you would want your business transactions to be as consistent as your financial transactions. No point storing a financial transfer if you can't match it up with a purchase on your business db.
I guess half the internet?