Nice work, I did mine in C, using Termbox2, in a very suckless fashion (config.h & make install)

I like the idea of the daily digest.

That gave me a good chuckle:

    Starts in milliseconds and parses hundreds of items in seconds.

Consider having a shortcut to load a feed item's comments in the browser, if that's not already there.

They've given more lives to humanity than humanity itself (j/k)

An obvious regression, you hope they'll get it fixed soon.

Highly depends on what you're streaming. If you stream arcade 2D games of the past, or software development, it should be perfectly fine.

AAA titles with newer graphics, well, you can always send a capture the PC with the nvidia card's screen through a capture card.

Back in my days of streaming, macOS was no option, cca. 2017. Today I'd do it with any M processor mac without a second thought.

I actually used an M1 MacBook Air for encoding/compositing by sending the video/audio sources over from my main PC with DistroAV (LAN).

Worked reasonably well (you can send camera/VTuber output and captured video from game and any overlays separately, or just use the setup in a similar way to a capture card and run ONLY the game on the gaming PC and everything else on the Mac), but added some complexity to it all.

A beefy Nvidia GPU would make that setup not necessary, unless you want to directly play games on the Mac.

LMStudio and 32+ gb of RAM.

https://lmstudio.ai/models/nemotron-3

Simplest to just install it from the app.

If the author reads this...

I'd be very interested if the author could provide a post with a more in depth view of the passes, as suggested!

> Little side-note: If enough people are interested by this topic, I can write a (much) longer explanation of these passes.

Yes, please!

APL was pretty popular some 40 years ago among some people who didn't consider themselves programmers. An Excel of the time?

Indesign was such a satisfying way to layout documents. I just cannot reproduce the same feeling using affinity products. Shortcuts feels wrong, defaults feels wrong, etc.

I wish Adobe stayed the 2004 company version of Adobe. They were good.

I second that, even better would be if every type chart would be a folder, with a readme containing a screenshot and the code example. That would be top notch.

PS: looks great on the surface!

Next updates will include better docs and many screenshots/examples, thanks!

If you don’t already have a preferred workflow for autogenerating these, you might be interested in vhs https://github.com/charmbracelet/vhs

I am not affiliated, I just think it’s a neat tool

C is fun to write. I can write Rust, but I prefer writing C. I prefer compiling C, I prefer debugging C. I prefer C.

It's a bit like asking with the new mustang on the market, with airbags and traction control, why would you ever want to drive a classic mustang?

It’s okay to enjoy driving an outdated and dangerous car for the thrill because it makes pleasing noise, as long as you don’t annoy too much other people with it.

> I prefer debugging C

I prefer not having to debug... I think most people would agree with that.

I prefer a billion dallars tax free, but here we are:(

In Rust dev, I haven't needed Valgrind or gdb in years, except some projects integrating C libraries.

Probably kernel dev isn't as easy, but for application development Rust really shifts majority of problems from debugging to compile time.

My current project is C++ backend. I do a lot of debugging but all of it concerns business logic, some scientific calculations and the likes. In this situations having Rust will give me exactly zero benefits. As for "safety". I am a practical man and I pay my own money for development. Being able to use modern C++ I have forgotten when was the last time I had any memory related issue. My backends run for years serving many customers with no complaints in this department. Does not mean of course they're really really safe but I sleep well ;)

If it wasn't clear, I have to debug Rust code waaaay less than C, for two reasons:

1. Memory safety - these can be some of the worst bugs to debug in C because they often break sane invariants that you use for debugging. Often they break the debugger entirely! A classic example is forgetting to return a value from a non-void function. That can trash your stack and end up causing all sorts of impossible behaviours in totally different parts of the code. Not fun to debug!

2. Stronger type system - you get an "if it compiles it works" kind of experience (as in Haskell). Obviously that isn't always the case, but I can sometimes write several hundred lines of Rust and once it's compiling it works first time. I've had to suppress my natural "oh I must have forgotten to save everything or maybe incremental builds are broken or something" instinct when this happens.

Net result is that I spend at least 10x less time in a debugger with Rust than I do with C.

Do you also want some unicorns as well?