I fall somewhere in the middle these days- I really like knowing in advance that I have a place to sleep each night and that I have a way to get there, but then just do whatever I feel like in the moment for everything else.
Who said anything about GDPR? If someone reveals to you that they are in some kind of protected class, then there’s a risk that anything you do they don’t like could see you tagged for discrimination even if it’s how you’d treat any customer in the same situation.
That's also an option available to you: Mutex::new() is const, so there's no trouble putting one in a static variable. If the inner value can't be const-constructed, you'll need a way to prevent access before it's initialized; for that, you can use a OnceLock or just Box::leak() the Mutex once it's constructed and pass around a simple reference.
There's some precedent for this: Back in the 40s, the movie studios were forced to sell their stake in theaters due to antitrust issues around exclusivity. Streaming services owning studios feels like the essentially the same situation.
> Are the users freeloaders, or is the product just not compelling enough to attract paying users?
There’s no cognitive dissonance in believing both of these things at the same time. The non-paying users are freeloaders because they’re gaining value with no intention of paying for it. The service isn’t compelling enough because, despite all of the attention it’s getting, it can’t attract paying customers.
They’re both causative to some degree, but from the entrepreneuer’s perspective, there’s nothing that can be done about human nature— you just have to account for it when designing your offerings.
> I'm still unclear about what it was supposed to be able to do that an electrified scooter or bike couldn't.
Segways have much better low-speed handling characteristics than bicycles, which makes them safer to intermix with pedestrians: Travelling at a slow amble speed in a crowded environment is extremely difficult on a bicycle, but no big deal for a Segway (or similar)
Make is an incredibly powerful tool for managing any automated process, not just software compilation. It doesn’t know how to do any of the individual steps itself, of course, but it lets you break down a process into indivdual small pieces that can be automated separately.
If none of the more complicated strucures will provide the liability protection that you're going to need, there's also the possibility of doing business as a sole proprietor/DBA. You get no protections at all, but the reporting requirements are much reduced (in some cases, just filing a 1040).
Piercing the corporate veil is a thing, though. I don’t know the details as I’m neither a lawyer nor a company owner, but my understanding is that you have to keep your and your company’s assets and activities completely separate, which requires a level of discipline that many people don’t have.
Similarly, as a single-person company, any action that could cause liability was presumably performed by you, personally. That makes it much easier for a litigant to sue you personally instead of/in addition to your company.
It doesn’t ensure that there’s a null terminator in the resultant string. This may potentially lead to a later overrun when the copied string is read back.
Take two nominally identical physical products (from IKEA, for example), one that’s on the shelves today and the other produced several years ago. There’ll be lots of subtle changes that got made as the manufacturer figured out how to improve the product, by cutting costs or improving reliability.
The frameworks you mention are great prototyping tools but as a community, we’re missing the knowledge of how to take a proven prototype and continue improving the quality rather than bolting on questionable new features.
“Free nights” from rewards programs also sometimes require the payment of the resort fee, even when some of the items included in that fee (like internet access) are also included in your status level.
I’m saying that pushing your developers to improve will increase their market value, possibly outside your personnel budget. One possible outcome here is that they decide to leave and join a company that will give them a higher salary to reflect their increased skills.
On the other hand, withholding opportunities for growth is also a way to frustrate employees and cause them to leave. Know your people, and take their changing needs into consideration when planning business strategy. There’s lots of strategies that can work here, but not all of them are right for every company. A few off the top of my head:
- Build a training pipeline so you can regularly hire promising young developers for cheap and help them grow into a more senior position elsewhere.
- As your developers improve, be prepared to give raises and promotions to reflect their increasing value.
- Hire experienced developers with the skills you need at a fair price and offer stable employment instead of fast-track growth.
> But you will, over time, run into edge cases and problems that a mature library has already solved for
It’s entirely possible that the new problems you encounter will be different than the ones the mature library was designed to address, and then you end up hacking around solutions to problems you don’t have in order to fix the ones you do.
That someone may be a direct competitor to you. Giving them access to your R&D may let them undercut your prices and make it harder for you to find clients.
I heartily agree with all the concerns here, but there are also business and professional development factors to consider, in addition to your present situation:
- How stable are your needs? Will your ideal setup be the same 6 months from now?
- Is this a core piece of the business or a peripheral concern?
- Which is more valuable: developers that understand the underlying theory, or developers that are familiar with the preexisting library?
- Will the act of rolling your own library make your team more valuable? Will it make them too expensive?
- How will this choice affect developer retention? Your ability to hire new developers?
The feel of the thing is determined by end-to-end latency, not the latency of any individual part. Without knowing that, we can’t evaluate how much of an improvement this is in relative terms— is the overall latency 50% of what it was or 95%?