2,777 karma · joined March 29, 2011
Website: https://yorickpeterse.com
My honest advice: nothing. Going to the beach should be about enjoying the beach, the weather, etc; not about what some random person may think about your muscle or lack thereof. If that's really what they care about, they're probably not worth worrying about.
If your argument is that banks and savings in particular offer poor interest, the proper answer is to look into index funds and focus on long term growth, rather than short-term speculation.
I think at some point Azure announced $X in free credits for YC members, and GitLab determined this would save us something like a year's worth in bills (quite a bit of money at the time). Moving over was rather painful, and I think in the months that we used Azure literally nobody was happy with it. In addition, I recall we burned through the free credits _very_ fast.
I don't recall the exact reasoning for switching to GCP, but I do recall it being quite a challenging process that took quite some time. Our experiences with GCP were much better, but I wouldn't call it perfect. In particular, GCP had/has a tendency to just randomly terminate VMs for no clear reason whatsoever. Sometimes they would terminate cleanly, other times they would end up in a sort of purgatory/in between state, resulting in other systems still trying to connect to them but eventually timing out, instead of just erroring right away. IIRC over time we got better at handling it, but it felt very Google-like to me to just go "Something broke, but we'll never tell you why".
Looking back, if I were to start a company I'd probably stick with something like Hetzner or another affordable bare metal provider. Cloud services are great _if_ you use their services to the fullest extend possible, but I suspect for 90% of the cases it just ends up being a huge cost factor, without the benefits making it worth it.
There has also never been any evidence of e.g. state actors sneaking in backdoors and what not. The code review process is quite extensive (probably a bit too much even), so it would be difficult to sneak in vulnerabilities deliberately. It's much more likely these issues are caused by growing complexity and the amount of functionality that GitLab supports.
In my case I'm using Bubblewrap because Firejail was only used for Zoom, and this felt a bit of a waste considering Bubblewrap was already installed.
You'd use a custom vocabulary as well. So rather than "curly open" you'd use "heck", and instead of "enter" it would be "bark". I'm just making the actual words up here, but the point is to use a different/more simplified vocabulary that's also easier to understand by the computer.
https://talonvoice.com/ is also worth keeping an eye on.
One could consider https://rubygems.org/gems/oga, as it doesn't have any installation problems. It's not actively maintained though (mostly because the author considers it to be complete). I do think the author is a bit of a weirdo though :)
But what about existing and proven technology that has been around for decades? This whole "web3" thing seemingly focuses on problems nobody has, cares for, or can be solved with what already exists in far more efficient ways.
You can easily have tens of thousands of threads on Linux. Beyond 50 000 or so you may need to adjust some settings using `sysctl`, but after that you should be able to push things much further.
Task counts themselves are also a pretty useless metric. Sure, you can have may fibers doing nothing. But once they start doing something, that may no longer be the case (this of course depends on the workload).
> Threads are really hard to work with - race conditions everywhere. Async doesn't have this.
You can still have race conditions in async code, as race conditions aren't limited to just parallel operations.
This article reminds me of that. Facebook will never admit their services are harmful, as that would be in direct conflict with their business. And because of that I would treat any claim they make about how good their services are as nothing more than just bullshit.
I will say this: clicky switches serve no practical purpose. The same goes for tactile switches, _especially_ when using light springs as you'll bottom out most of the time. Whether you buy Cherry switches, Kailh or something else doesn't really matter either ergonomics wise.
Rayon is a library for running code in parallel. Typically you'll give it a (parallel) iterator of sorts, and it will distribute the work across a pool of threads.
Tokio is a library for async IO operations.
And do what exactly, go to prison? Expecting that is unreasonable at best.
Not sure what rock you have been living under, but the EU absolutely has its share of racial issues. Saying race doesn't matter is nothing but naive.
Moving objects between processes itself doesn't lead to fragmentation, as processes don't have their own heap in the data structure sense. That is, the structures representing a process don't have some sort of "heap" field. Instead, the OS threads running processes maintain the heaps (each thread has its own heap). This brings several benefits:
1. Since the heap is physically detached from processes, we can move without copying
2. Since the heap is still thread-local, allocations don't need synchronisation
3. Since the heap is detached from the processes, each process is smaller, allowing for more processes to run concurrently
4. Since objects (and their children) can only be owned by one process, we also don't have to worry about multiple processes trying to write into the same object
This is only possible because we statically guarantee that a value `T` can't be _shared_ between processes, and because we'll disallow sending references between processes.
Setting that aside, Servo and Firefox both implement the UI side of things from scratch I think. I think from a browser perspective that makes sense: you're already writing a rendering engine, so you may as well also use it for your browser UI.
My conclusion is basically "there's nothing viable". _If_ you are OK with basically limiting yourself to Linux/BSD, the GTK bindings are good. However, for a text editor you'll likely need a custom text widget (the GTK ones aren't very good), and that's where things (with basically any GUI toolkit) get tricky.
There are a few libraries providing Qt bindings for Rust, but they either focus on QML, are only infrequently maintained (e.g. Ritual), or seem to focus more on exposing Rust to C++; not the other way around.
egui looked really interesting, and the immediate mode GUI pattern is really nice to write. Sadly, it's still in the very early stages, and most notably is lacking support for displaying text with different colors/styles.
The rest isn't really worth mentioning I think, at least when wanting to write a text editor. They basically all suffer from the same issues, such as:
- It not being clear if the library will still exist 2 years from now
- Poor support for Unicode (especially Emoji)
- No support for assistive technologies
- Poor support for flexible text rendering (e.g. multiple colors and styles)
- Little to no documentation
For a while I thought about just using Electron, or maybe Sciter (that would at least need fewer resources). Technology wise I think HTML makes sense, as it's very flexible (e.g. many GUI toolkits struggle the moment you want to mix text and e.g. images in the same widget) and quite easy to work with. Sadly, Electron is a fat pig and the last thing I want to do is write Javascript in my spare time. Sciter is proprietary, and you can't distribute the binaries yourself (from what I understand). That basically means your project is dead on arrival, at least if you intend to open source it.
So for now I shelved my idea. Maybe in a year I'll take another look :)
So basically you get all the drawbacks of developing for different web browsers, without really any of the benefits a cross-platform GUI gives you.