BillyTheKing

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

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!

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.

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

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?

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)

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

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.

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.

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!

Would recommend to try out anthropic sonnet 3.5 for this one - usually generates decent unit tests for reasonably sized functions

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.

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

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

shipped extra fast!

We've been building a source/destination ledger at nxos (and I've worked with similar systems in the past). The relationship between debits and credits in such a ledger wasn't always clear to me. However, writing this post did help me to show how these concepts map and how it's fairly straightforward to model accounting standards on such a ledger. While exploring this topic, I also learned significantly more about why debits/credits affect different account types differently and why different account types exist in the first place. I hope you might find it as interesting as I did!

Hey everyone! I wrote a blog post about building a simple double-entry ledger using just simple SQL. It covers implementing a ledger with source and destination accounts, using a simple table structure and straight-forward SQL queries for balance calculations. I use negative and positive amounts instead of traditional debit and credit columns. In my opinion, this from/to model is easier to reason about and visualize in graph form, while still allowing credit/debit terminology to be built on top if needed. Would love to hear your thoughts!

maybe that's really where the business here is.. working through a whole bunch of custom data-sets and trying to generalise from there. It'll be hard to generalise all of it, but I'm sure there'll be pockets of functionality that can be shared across more than a single data-set.

And maybe that's at the core of the issue here, namely that this service in its current form doesn't scale like b2c internet tech

and once again - another year with a great iPad Hardware wise but essentially unusable for coding tasks software wise.. Would love a reason to buy one and use as a travel coding machine but without local support it remains a non-starter

GraphQL basically only really works with monoliths that share the same access-pattern (either everyone logged in, or everyone logged out), it's otherwise a pain to merge multiple different graphql-schemas into a single one (or at least I'm not aware of an elegant way to achieve that).. The worst of two worlds is a micro-services back-end with a graphql Api interface, it makes testing individual services and the Api as a whole quite annoying.

I do really like the Api definition part of it though - but I found something like typespec now to be the perfect middle-ground, it allows out you describe your apis similar to a graphql Api without enforcing the graphql engine on you though.

I can spend more times at my friend's place, maybe have a beer or two without having to worry about driving back - so I think it encourages socialisation

yes - and writing code also doesn't solve a technical problem, a computer runs fine with 0s and 1s, no need for code, in fact code produces a performance overhead - but it solves a human abilities problem, namely that 0s and 1s aren't particularly expressive for us. Almost everything we do solves for communication, some things on an individual scale, like programming languages, and other things on an organisational scale like micro-services (I'm also not blindly advocating for micro-services, but I do get why if done somewhat competently it's easier to organise a team of 1000 developers into 50 teams of 20 each responsible for one service rather than 1000 developers responsible for everything)

for Fintechs who're using Stripe as a way to allow users to purchase stock/remittances/e-wallet balances etc. instant payouts are very important since in most cases people who load with stripe also consume those funds on the platform instantly

what's wrong with Remix's fundamental architecture? I mean.. I generally also think that the overall state of the JS ecosystem is broken, but that's due to JS tooling modules vs commonJS etc (hope bun fixes all that). But as a backend-dev who primarily writes Go I round remix easy and simple to pick up and get started with when I had to use it this year.

exactly.. yes, I understand why ? is neat from a type POV since you specifically have to unwrap an optional type whereas in Go you can ignore a returned error (although linters catch that) - so at the end of the day it's just the same boilerplate, one with ? the other with err != nil

I agree, I don't really understand everyone's issue with err != nil.. it's explicit, and linters catch uncaught errors. Yes the ? operator in Rust is neat, but you end up with a similar issue of just matching errors throughout your code-base instead of doing err != nil..

yes, the whole world runs on nestjs

for internally consumed APIs I somewhat agree, but if you wanna expose APIs to external developers it usually does pay off to spend a bit of time on the API design itself, what APIs would you expect to see if you were the user of the your own service - and this is where tools like this really help imo - you could even preview your API in some openapi doc tool like readme or similar, in which case it's like previewing your product before releasing it

totally agree - the iPad Pro could be a great second coding/programming tool - I'd love to justify buying myself one, but.. I just don't see a use-case if I can't work on it. I don't design stuff, don't really feel like I need a separate browsing device either

not everyone writes Python, and not everyone starts code-first