@BordedDev Ill give you that, but reconciling the two approaches in code creates a new language with its own logic that has to be learned, whereas in React you can just use familiar Javascript techniques that work exactly like they would in vanilla to connect the tools the framework provides. I'm not making a broad value statement, just saying that Vue takes significantly more explanation than React.

@retoor I don't even know what you're talking about, Vue literally changes JavaScript way more than React

Or it's a drain of the recommendation graph for you like Fucking House of the Rising Sun is for me.

I mean React is 90% of all programming content on YouTube, from the perspective of the algorithm that probably makes it a public concern that is relevant to everyone in the field whether they like it or not.

Then again, there's probably nothing useful to be said about batching protocols on general, they're pretty much all unique to the level of regularity in, and frequency and nature of changes to your data.

These are the times when I feel like REST was naiive for a methodology that claimed to be built on 10 years of experience maintaining legacy software.

My previous employer used Sentry SaaS and I never fully understood why literal batch scripts with rotated file-based logs couldn't serve the same purpose.

Also, aren't both of them maintained by companies that aren't even slightly incentivized to make self-hosting easy?

Aren't both of these designed for extreme scale and resilience combined with relative ease of use?

These cycles have been faster for me, I change my mind at least yearly on these topics.

Not to mention that most of my tests are integration tests spanning constellations of 3 or more binaries with a specific input and cwd, so I tend to fiddle with those on the command line too.

@cprn well yeah, but IDEs cache all that crap and anyway rust-analyzer uses a different implementation of most of the compiler which supports partial recalculation better but isn't perfect, so a bunch of errors - typically related to infinite series of types or lifetimes that depend weirdly on themselves in a different stack frame - are only raised at build time.

Also, filtering test cases is easier on the command line.

Coffee only ever tends to cure my headaches, unless I'm already severely dehydrated.

@BordedDev I think the latest version of Vue did some interesting things with static analysis and transpilation, but as I said the topic bores me so I only keep up with it on a yearly basis.

The episodes of /dev/voices that aren't about langdev are mostly about those interesting bits of webdev I listed above. The host is a Kafka expert so he likes to invite people from that space.

@BordedDev Well, the web deals with standards so in a sense even HTTP problems are invented, as in they're not inherent to the premise of a networked application.

There are some really interesting problems IMO. For example, large scale application backends deal with massive streams of data that can only be handled with a lot of consideration. There are interesting architectural questions around caching and efficient use of the network, and UI-UX is cool although arguably programming-adjacent.

The endless discussion of frontend frameworks bores me to death too, but since newer frameworks do actually have better features that make development faster with fewer performance and flexibility concessions, I have to think that it's not pointless just not interesting to me.

Faster than lime - Rust and systems deep dives. Web is often the framing but rarely the main topic

Developer Voices - half web, half langdev, new guest each episode

Two's Complement - Matt Godbolt (of compiler explorer) and Ben Rady talk mostly about project management, code quality and various topics

All three update very very rarely

oh wow the necrobump reminded me that I used to be a globalist. So naive!

Okay so Github allows you to configure tab sizes, so does a decent editor. Compiler messages on the command line can be wrong, but it seems that Rust converts tabs to 4 spaces for that, and anyway it's not devastating if those are indented a bit differently IMO, it's not like there's a lot of code to read.

too late to edit but even I was too permissive up there, actually splitting strings by codepoints is incorrect. For transmission and storage count bytes, for display count graphemes. I meant to talk about a "contains" check, but since equality is meaningless, so is "contains". So instead I'll point out that you can split graphemes and normalize strings without specifying a locale, and on this level both "starts with" and normalized equality are meaningful operations.

Absolutely not. No pre-trimming, no case-insensitive storage, no length limits, no grapheme normalization. Text is hard and we suck at it. By default they're an optimized sequence of 32bit codepoints that you can split and compare, where inequality guarantees that two strings can't have been created the same way (NOT that they represent different text), and less-than is an arbitrary total ordering for algorithms (NOT alphabetic order).

For all other purposes you should use a Unicode grapheme library with a specific locale. Many programming languages also choose to provide broken operations that only work on English and partially on some latin text, because they're made by Americans with deadlines.

Happy birthday, you're gonna make everyone skim your profile.

30?

What's next, laundry? Damn the Psycholonials soundtrack is a vibe. Am I being weird? Lol what a question, I'm always being weird. Did anyone see that? Eh, they probably didn't. Eventually I'll have to do that DB cleaning task, we should send it this week. When did I vacuum last? Well it's 11pm, shouldn't wake up the neighbors. Did I file my taxes? Oh yeah, I've not had contract work in years. Wasn't it Matthew's birthday this week? I should respond to the D&D scheduling convo. Why did I stand up? Oh yeah, laundry.

I love Diesel. I think the ideal solution to the problem that's SQL is a very elaborate query builder.

It's not that SQL is difficult so I need to use an ORM, it's that SQL fucking sucks so bad that a runtime library that doesn't implement all of the features and borrows the syntax of a less insane programming language is better.

Furthermore:

- The Sun is bright, and people generally can't turn it off. This should probably advise the top of the brightness ramp more than the battery. When your users are outside in glaring sunshine, they hopefully won't look at the phone that much anyway.

- The lock screen has a very large clock that I may want to look at, or show someone, without randomly revealing the screen below, so mechanisms that cleverly skip the lock screen like combining the power button with a fingerprint sensor are actually removing functionality.

- Weight has benefits; the only phones I ever accidentally left somewhere prided themselves in being exceptionally light. Also, you can literally always trade more weight for more battery life, so it's not like it's ever wasted.

I will say though, I think there were some good ideas along the way that we should reconsider for future phone designs

- curved glass is more expensive, harder to protect, and less convenient to control as a touch surface

- If the outermost rim of the front face is plastic, the phone will practically never hit the ground screen first because of aerodynamics

- If the back of the phone is plastic, I don''t have to wrap it in an extra 3mm of plastic and rubber

I think it should be possible to catch a HUP and convert it into a program-specific cancelation event, no?

@retoor Didn't Xamarin work fine?

@retoor No major preference either way really. I like standardization though, I think the current smartphone format is really good and engineering the fastest, cheapest, least fragile palm-sized touch screen Android device is a worthwhile competition.

I really liked the sharp angles of Lumias as well, Windows Phone was doomed but the design was miles better than the bubbly / neumorphic look Android is going for

My hubris betrays me yet again, for some reason I decided to connect it to the network. I don't think I'll be able to unlock the screen or even turn it off for the next 20 minutes while it chews through 3 years' worth of "super urgent" events.