Recent submissions

Comment · 1 year ago
The reasoning might not sound crazy, but the result is that a founder based in Hong Kong, opening a holding in Singapore, and creates a subsidiary in Germany is much much better off than a founder running the same business out of Germany - and that's before considering personal income taxes or similar
Comment · 1 year ago
how did you do it? My co-founder is in a similar situation, and his tax-lawyer said the only way was via a trust - they also have a German holding. Do you have to declare that somewhere? or how does this work? Thanks!
Comment · 1 year ago
This means the person has to move to a country with 0% income tax for this to make any economic sense, so that's either Monaco or the UAE then. Very difficult for me to understand why someone is supposed to pay this tax in the first place, the business paid a whole bunch of other taxes in its lifetime.

I would understand if they'd tax the sale of the business.

Comment · 1 year ago
apart from those weird file attach issues I actually think they've got a much better UI than anthropic as well - much much snappier even with extremely long chats (in addition to much higher limits obviously, totally different league). I love using it
Comment · 1 year ago
just a question for understanding - if we say 'it learns', does it mean it actually learns this as part of its training data? or does this mean it's stored in a vector DB and it retrieves information based on vector search and then includes it in the context window for query responses?
Comment · 1 year ago
yes, it's a form of double-entry bookkeeping - that's the base. If it weren't double-entry then indeed it would be a pretty poor choice. This design enforces double-entry at a fundamental level, it's never possible to create a record that doesn't affect 2 accounts - and that's actually the whole point of it :)

You have a single USD (or other) value - so in the simplest form it just looks like this:

From: Alice To: Bob Amount: 10 Currency: USD

And the balances are simply sum(transactions where account is receiver) - sum(transactions where account is sender)

Comment · 1 year ago
you simple create two records linked by one 'transaction', the source in both cases is the same account, while the destination for one of those postings is the fee account and the other destination is a merchant or similar account. And you can link as many of those postings under a single transaction
Comment · 1 year ago
yes, agree, I think a 'source' 'destination' model is significantly more straight-forward. Just record the 'source' account and the destination account and you essentially end up with a ledger as a directed graph (Martin Kleppmann wrote a great post on it)

I also wrote a super short post on how to model such a system on postgres https://blog.nxos.io/A-simple-double-entry-ledger-with-sourc...

Blockchain actually kinda nails it, that's in essence a source/destination ledger, no 'postings' or similar needed, and from a balance calculation POV has been working pretty well

One reason this model isn't applied in accounting, in my personal view :), is simply historical and the fact that the number 0 didn't exist when accounting principles were created.

Wrote another post on how to model debit/credits on a source/destination ledger here: https://blog.nxos.io/Debit-and-Credits-on-a-Source-Destinati...

It's very straight-forward, you just have to accept that asset accounts have negative balances and present the absolute amount instead of a negative amount in a view.

Comment · 1 year ago
absolutely not true btw - the largest use-case for stable-coins atm are people evading capital controls in emerging markets, including China, India, Nigeria, and similar, and in many latin American countries.
Comment · 1 year ago
or just use bun? used to also face all these issues - but with bun it's mostly gone for now (and for newer projects) - hope it stays that way!
Comment · 1 year ago
Would recommend to try out anthropic sonnet 3.5 for this one - usually generates decent unit tests for reasonably sized functions
Comment · 2 years ago
this is the thing with JS and TS - the types and stuff, it's all good until you realise that all integers are basically int 52 (represented as float 64, with 52 bits for the fraction).

Yes, it's nice and flexible - but also introduces some dangerous subtle bugs.

Comment · 2 years ago
People just have less tolerance for errors using apple products.. that doesn't mean that other LLM companies sell snake-oil, people just have a higher error tolerance for them and are learning to work 'with' those LLMs
Comment · 2 years ago
Yes, all true - apart from treating errors as values and including them function signatures... That should simply be something every modern language should ship with
Comment · 2 years ago
shipped extra fast!

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton