tele_ski

I found that confusing personally, seems like it's just unnecessary and just seeing the raw number that you're missing out on would be easier to reason about.

I came here to post this so glad I'm not the only one looking for specific time of day. Or at least give the user the estimated time they can be outside before getting burned? The timer feels great to fire and forget but I might want to plan and I couldn't figure out from the UI what the duration is "safe"

It's a joke/sarcasm

https://xkcd.com/1053/

Relax, not everyone sees every article everyday

It is a table stakes missing feature.. for a long time. Clown seems appropriate, every project I've worked on in github we end up copying a github yml action to allow us to do this with one comment '/fast-forward', just is silly at this point that github doesn't natively support it.

Very nice, the movement and snapping of the tiles is very nicely done, enjoyed today's puzzle!

This sounds like running an event loop per thread instead of 1 event loop with a backing thread pool. Or am I misunderstanding you?

It works great for small tasks but larger tasks block local events and you can get weird latency issues, that was the major tradeoff I ran into when I used it. Works great if your tasks are tiny though, not having the event loop handoff to the worker thread is a good throughput boost. But then we started having latency issues and we introduced larger tasks which would hang the local event loop from getting those events.

I think Scylladb works somewhat like this but does message passing to put certain data on certain threads so any thread can handle incoming events but it still moves the request to the pinned thread the data lives on. One thread can get overwhelmed if your data isn't well distributed.

Been using valkey streams recently and loving it. Took a bit to understand how to to properly use it but now that I've figured it out I'd highly recommend trying it. It's very easy to setup and get going and just works.

The suggestion is c# class vs struct basically, with explicit globals which are just class with synchronization

reminds me of the classic https://xkcd.com/927/ not exactly identical to Bjarne's quote but similar.

I'm quite familiar with C++ as well and this just jives so much, each standard is just almost exponentially more complicated than the last, and while there are good changes they don't necessarily fit well with the prior version and its just a mess, I still maintain two OSS libs but I don't use the language anymore.. so its a question of how long I put up with it at this point.

Rust is such a breathe of fresh air coming from c++11/14/17/20 but its still a behemoth if you don't know the entire thing, I think this article is pretty spot on with that.

https://danluu.com/everything-is-broken/

Always has been and always will be. This article was eye opening to me because I didn't even realize how often I was working around buggy software.

I've always thought that it seems like a silly way to measure it.. Everest also goes to the sea floor, technically.

It's an interesting idea, but reactive, and could cause big delays due to bisecting and testing on those regressions. There's the 'old' saying that the sooner the bug is found the cheaper it is to fix, seems weird to intentionally push finding side effect bugs later in the process because faster CI runs. Maybe AI will get there but it seems too aggressive right now to me. But yeah, put the automation slider where you're comfortable.

Isn't it both on LLMs? The input is your ability to craft a prompt, the output is checking if the prompt worked.

It's a decent idea, but it's weird reviewing code you wrote in saying GitHub, it looks totally different. Imo not a show stopper but a side effect you have to get used to.

We interestingly ran into issues with actix and the AWS lb. The lb takes some liberty with how it handled connections and actix seems to be "to the spec" so we were seeing a lot of dropped connections. Placing nginx between the two resolved the issue but it's fairly disappointing that we need that layer when it should be unnecessary overhead. I'd love to give axum a try if we could find time and see if it behaves better.

I do appreciate that you write tests. I find it's like pulling teeth with most devs to get them to write anything but the most basic of tests.

I tend to think more than write code, so usually my first go is reasonably close to what I need. But there are always edge cases you just never think about. I'd rather have a strong debugger than a repl imo

I like you're analogy, but I do think there are features of c++ that are big hills as well. To me it would be SF to LA with some big ups and downs on that long ride.

I'm also curious what's difficult about pin in rust? It basically just disables moving of the object for the lifetime of the pin.

Yikes, I was so excited for modules back when I was still writing C++17 and a bit of early 20. Sad they have so many problems with them and/or are just plain not implemented still. Honestly I'm happy I'ved moved on from the language

What if you had to earn your undos? As opposed to starting with N of them in the beginning.

What if you scored like wordle but based on undos? 1 undo used, 2 undos used... Up to 5 undos used. This incentivizes the user to try and not undo if possible.

I think the eliminated score method is kind of redundant with the wordled scoring, just make the player guess the 1 word left and be wordled?

Really cool and fun idea, we had a great time playing with it and probably will add it to our daily rotation.

I've used both very extensively and while I like the direction c++ is headed, I know a lot of people don't, I couldn't disagree with you more. Writing reasonably fast rust that doesn't crash is far easier than writing any kind of c++ that doesn't crash. Copies are a real problem in rust though, they are definitely difficult to avoid without jumping through hoops sometimes but I haven't hit any yet that are a real world show stopper with good upfront design and architecture. C++ just has too much baggage and footguns to make it truly productive on larger teams osit

Anecdotal but my company is using it for a new project and we just hit production about a month ago. So far it's been great with 10+ million requests handled per day. Looking forward to upgrading to 4.0

I think you're point is correct around rust in that writing rust is harder than writing C due to the constraints the compiler places on what you can do. So far I'm happy with this tradeoff because I've had some very gnarly C concurrency bugs that took weeks to understand and debug. If the rustc compiler can point out that I'm doing something stupid and save me two weeks for a bit of pain immediately I'm all about it.

I've been on teams that haven't used docker for dev envs and teams that do in the last 5~ years. The teams that used docker were significantly more productive since each dev env was a replica and forced the team to maintain a common env. The dev env drift without it is huge and causes so many "it works on my machine". I can see a one man show or maybe two not needing a docker dev env but any sizable team IMO it is absolutely required now. You're absolutely right that it is a hoop to jump through, but its a hoop I find very necessary.

As much as I like deving only on Linux, this I'm pretty sure would be awful for rust's continued adoption.

The faq says they'll support main distros, but power management with Linux is always not great in my experience, hopefully it works out!

I'm not the parent poster but I think this question might be more interesting in 10 years when rust possibly has a larger industry foothold? I agree and I am actively trying to move my career from C++ towards Rust but its slow and Rust isn't particularly heavily used outside of crypto, which is something I am not interested in, from looking at openings for Rust over the past year. I do think it is great that larger companies like FB/Microsoft are now starting to invest in the language though.

My biggest issue with C++ is that although it does seem to be adding lots of good quality of life changes with the recent standards for developers it has inherit flaws that without breaking backwards compatibility it can never be as safe as Rust. And I think C++ is probably right to not break backwards compatibility, it has too large of a user base that will most likely splinter, it reminds me of the python 2/3 problems.

Thanks for your detailed thoughts on this, I am definitely not involved at all and just onlooking from the sidelines. The name does initially seem quite esoteric but I can understand why it was picked. Thinking about it more 'io' rather than 'syscall' does make sense, and Windows also does use IO in IOCP.

What you're describing sounds awesome, I hadn't thought about being able to string syscall commands together like that. I wonder how well that will work in practice? Is there a way to be notified if one of the commands in the sequence fails like for instance the buffer wasn't large enough to write all the incoming data into?

I think this might be the best explanation I've read of why io_uring should be better than epoll since it effectively collapses the 'tell me when this is ready' with the 'do action' part. That was the really enlightening part for me.

I have to say though, the name io_uring seems unfortunate and I think the author touches on this in the article... the name is really an implementation detail but io_uring's true purpose is a generic asynchronous syscall facility that is currently tailored towards i/o. syscall_queue or async_queue or something else...? A descriptive api name and not an implementation detail would probably go a long way in helping the feature be easier to understand. Even window's IOCP seems infinitely better named than 'uring'.