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

Not answering your question directly but accounting and taxes are a thing everywhere. EU rules make accounting for companies quite complicated.

Focus on your business, open the smallest and simplest entity you can to validate your product before spending time and money optimizing or scaling things. That being said, I’m familiar with GmbHs in Germany and I would advise against going this route unless funding is available. Try a sole proprietorship instead if possible.


"accounting and taxes are a thing everywhere. EU rules make accounting for companies quite complicated" >> this is the most wrong thing ever. You cannot compare the one click accounting in estonia with german kafkaesk absurdity designed to grind you down. How things are implemented are drastically different in countries even if both in the EU.

If you have a company in estonia but you reside and fully control it from Germany, you might be liable for taxation in Germany due to CFC laws.

Thank you! Yes, that's why I'm looking for a simpler and less bureaucratic alternative. I'm totally fine with general accounting and taxes. But I would be happy if there was an alternative somewhere where you don't have to go to a notary for every little change and don't necessarily need a tax advisor because you have to talk to five different tax offices. Germany really makes it more complicated than it needs to be.

edit: just stumbled upon this really good blog post about the topic, in case anyone is interested: https://eidel.io/posts/estonias-e-residency-is-awesome-and-s...


Haha, thanks for linking to my website! Happy to answer any questions.

Skimmed this thread and I'm quite surprised how few people are aware of the permanent establishment problem.

Quick primer on the permanent establishment problem: You would technically have to pay taxes for your company in the place you're living (not Estonia). For example, if you're living in Germany, your Estonian OÜ would technically have to file for German taxes, too, because it's being run from Germany and it now has a permanent establishment in Germany.

So, roughly speaking, the Estonian OÜ is only useful if:

- You are in a country which doesn't have a permanent establishment problem and maybe even offers tax benefits for foreign companies (e.g. the non-dom rules of Malta, Cyprus, etc.)

- You are in a country which doesn't have a permanent establishment problem because they don't crack down on foreign company ownership (e.g. most developing countries)

In all other countries, the Estonian OÜ is likely going to cause you many tax headaches in the long run. In practice, this means:

a) Your local tax authorities don't notice or don't understand, and you're still fine, even though you'd need to file for taxes;

b) Your local tax authorities crack down on you and you need to go looking for a very expensive international tax advisor versed in Estonian and your local tax law.


It should be noted that this is about text editing specifically, and for other use-cases YJS is using other code pathways/algorithms, but you have to be careful how you design your data structure for atomic updates.


Thanks for reporting, I'm looking into it.


Go away


Good one


In simpler terms

1. You must implement a move constructor or a move assignment operator in order for std::move to do anything

2. The moved object could be left in an unusable state, depending on your implementation, after stealing its internal resources.


I never understood move semantics until I learned Rust. Everything is move by default and the compiler makes sure you never leave things in an unusable state.

This was a difficult mental hurdle to get over with Rust, but once you do, move semantics make a lot more sense.

edit: When I said everything is move by default, I mean everything that isn't "Copy", such as integers, floats, etc.


What Rust loses with that decision is the ability to program the "semantics" in move semantics. Rust has no distinction between hypothetical place constructor and value constructor.


I sure don't miss the footguns and raw boilerplate that is having a copy constructor, move constructor, copy assignment operator, move assignment operator, and destructor, per class.

Yes, you should avoid the manual memory management that necessitates writing them. But work with a team of developers fresh out of school and next thing you know your codebase will be brimming with this kind of busywork.


A loss of functionality, but arguably a good thing, e.g. moving will never throw an exception/panic so you don't need an equivalent to is_nothrow_move_constructible


> You must implement a move constructor or a move assignment operator in order for std::move to do anything

Bit of a nitpick, but there are sometimes other functions with overloads for rvalue references to move the contents out - think something like std::optional's `value() &&`. And you don't necessarily need to implement those move constructor/assignment functions yourself, typically the compiler generated functions are what you want (i.e. the rule of 5 or 0)


> The moved object could be left in an unusable state, depending on your implementation, after stealing its internal resources.

The "proper" semantics are that it leaves the object in a valid but unspecified state. So, invariants still hold, you can call functions on it, or assign to it.


> you can call functions on it

Only functions with no preconditions, unless the type makes more guarantees as to the moved-from state.


The guarantees is that a moved-from state is in an otherwise valid state.

So, you can do things like check if a moved from std::vector is empty (often the case in practice), then start appending elements to it.


Too little too late. Used to be a JetBrains user and subscriber when IDEA was the best Java IDE. They lost me with the excessive product segmentation in the pursuit for profits.

For example, Python is heavily used for web dev where you need to do both backend and frontend. Neither PyCharm nor WebStorm alone offers what I need in one app.

VS Code with clangd is what I use now when I need to code C++.


Next I want to run WASM inside CSS. W3C, please don’t disappoint.


JabbaScript


Java no barter


I wonder what’s wrong with Firefox? What is the bottleneck? The JavaScript engine? I’m guessing the thing is compiled to wasm anyway.


The bottleneck is webgl. I'm not sure why exactly but firefox is pretty well known to have significantly worse webgl performance than can be achieved with chrome.


"I'm not sure why exactly"

I would guess because the GPU world is messy and full of broken drivers full of hacks and workarounds, so it is rather a miracle that FF works so good, with the few engineers they have left.

(If you are on a chrome based browser, open chrome://gpu to get a glimpse into the work they have been doing just for your GPU and plattform)


Which is why sadly Web 3D never took off beyond ecommerce and visualisation tooling, with game studios rather focusing on streaming.

While on native games the engine can workaround the driver issues, Web 3D APIs are at the mercy of the browser sandbox, where studios don't have access to possible workarounds due to lack of feedback on API performance.


It’s RA2. If we could run it on a P2, then surely we can run it in a modern browser even on pure CPU?


Exactly what I was thinking.

Minimum specs: Memory: 4GB (8GB recommended)

The original ran on 128 MB or even less.


32MB under Win95


Probably even with pure software rendering in WebAssembly, most likely.


This. I was researching uv to replace my pipenv+pyenv setup, but after reading up a bit I decided to just give up. Pipenv is just straightforward and “just works”. Aside from being slow, not much is wrong with it. I’m not in the mood to start configuring uv, a tool that should take me 2 minutes and a “uv —-help” to learn.


What doesn’t just work about uv in particular? You basically need three commands - uv add, uv sync, and uv run. Forget about virtual environments, and get back to working. No configuration necessary.


Slow doesn't really begin to do justice, I'd have to wait for >5 minutes for pipenv to finish figuring out our lock file. uv does it in less than a second.


> Pipenv is just straightforward and “just works”

I have worked on numerous projects that started with pipenv and it has never "just works" ever. Either there's some trivial dependency conflict that it can't resolve or it's slow as molasses or something or the other. pipenv has been horrible to use. I started switching projects to pip-tools and now I recommend using uv


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

Search: