packetlost

I just... don't agree. Every pitch in baseball is exciting and there are almost 300 thrown in an average game, even if most end up with no progress. Meanwhile I find "fragile equilibrium" games to be boring as hell to watch, there's hardly any progress being made! I don't want to watch an abstracted tug of war drawn out over 3 hours.

It depends on if you have parens for (explicit) modules like some Lisps do.

I find this to be completely the opposite of my recent experience. The games are fast and with much better, consistent payoff than other sports such as football and soccer. Progress is far more discrete and there's basically always something happening except during inning or player changes. I agree that there are a lot of games, but that's a feature: you don't have to pay attention to every game. Because of the discrete nature of progress and the number of games you can get meaningful statistics out of a single season. I say this as a relatively young person (<30) who only loosely follows other sports.

I just started getting into baseball this year because of the Brewers stellar performance (I'm from Madison).

That has to be a nightmare for parsers lol

> Rust will never replace C/C++ with regard to high performance computing.

I don't buy this. Rust is a lot easier to make more performant than C++ and doesn't really trail behind C in anything but .text size last time I looked. Considering you can easily write C-like Rust that ends up in the same LLVM stack as Clang (more or less) I just don't think this is true outside of some very specific contexts.

Maybe you can theoretically encode arbitrary (but not infinite) information, but there are still discrete underlying states.

Formula 1 cars also have massive amounts of heavily engineered downforce and negative camber to give them insane amounts of grip. Pretty much every street car has enough braking power to lock its brakes in almost every condition but doesn’t have nearly the grip to utilize it.

Bigger brakes != more stopping power.

Too bad this didn't make it into the new Kindle Colorsoft. Oh well

> Once the models are good enough

That's a big "if".

Even for coding these things are not ready to take away real decision making and it's not clear they will ever get there.

I've worked with neutral atom QCs before (though am not a laser tech): keeping lasers locked is a massive pain in the ass.

> more so effort should be spent on making the technology cheaper and more accessible

Lasers are weird because the techniques to generate light at different frequencies differs a lot. "Telecom wavelengths" used in, say fiber optic networking, is super cheap and widely available, but these QCs often need different wavelengths that aren't mass produced. Some systems even need the ability to tune the wavelength precisely and the range of that tuning is another spec that can matter. I'm sure these QC companies would love for this to be more stable and cheaper, but the reality is without demand (of which there is little), it's just not going to happen.

Pretty much any bluetooth headphones work connected directly to the AppleTV, not just Airpods

For tech especially I don't think that's necessarily true.

Yeah, it's pretty extreme. To be clear, I'm not saying it's a good thing, just that chan culture is so much worse across that and many other dimensions

An JavaScripts is? Rust is probably a more performant target regardless

Yes, that's my point.

I feel like Go would be a great backend target for Gleam

> But it got sad when the whole internet became a chan

I honestly do not see how you could go from talking about self censorship in the context of institutional censorship and then go on to say the whole internet has become a 'chan', it absolutely has not even if the current zeitgeist doesn't fully align with your particular ideals.

Polished turds maybe. Making something actually good (stable, intuitive, not lying to you in some way) still requires a lot of attention and effort.

PlexAmp is a good experience too, but not free.

Most times I've seen complaints about it, it boils down to "XML being yucky" and the extension component model being difficult to write clients for, which is true but not really a fault of the protocol, it's more of an inherent tradeoff of supporting opt-in extensions at all

I firmly disagree, they are not a continuum, they are binary properties of what they describe. Code can have concurrency primitives, but parallelism primitives must necessarily come from the environment the code executes in, whether it's multiple code streams on a multicore processor or process parallelism provided by an operating system. Programs that are parallel are necessarily also concurrent (if they must communicate between parallel executions), but the inverse is not necessarily true.

If this distinction wasn't important, Python's infamous GIL would not be an issue.

Frankly the software industry suffers heavily from a lack in standardized terminology. The precise definition of parallelism vs concurrency is one that I think is incredibly important. You are doing your peers a disservice by using them interchangeably, they are not.

Testing is not a replacement for use, but it can help exercise code to the extent that the author can predict how the software will be used. A significant source of test cases come from using code and finding defects. No amount of auditing or proactive testing replace real world use.

The only way to know if software does what is intended is to use it. IMO that's the real value of OSS: software that has been executed many times by many people in many different environments, which overall increases the trust in the correctness of the system(s).

Oh fully agree. I hate reading LLM generated text, just wanted to provide a counterpoint to GP.

While I generally agree, the difference is I can also hand an LLM my pile of code and documents which is... a lot more information dense than basically anything I could write. Sure, a one-off prompt in a chat window isn't very helpful.

> it has no hidden memory allocation or control flow

Rust had like 3 allocating types total. If you aren't working with extremely deeply nested 3rd party types it's trivial to identify when allocations happen. Hell you could throw a lint rule together in like 5 minutes to warn on it if you're really worried. Besides Drop (excluding async) is there even any hidden control flow?

> Im speculating here, but I believe its advantage over Rust for that specific application is that you have tighter control over exactly when memory is allocated and deallocated, and how data is laid out in it.

Rust has almost exactly the same semantics for controlling allocations and deallocations, it just prevents you from screwing it up and not freeing something or using the allocation after freeing it. You still have to pass around your reference in your call stack until you no longer need it.

> Rust wants to tie allocation lifetimes to scope in a very fine grained way that I would guess is beneficial the vast majority of the time, but does still make it harder to reason about when you’re about to stall out the CPU while the allocator does its thing.

It's really not substantially different. You allocate ahead of time or don't allocate at all. The only real difference is you might want to use an Option instead of an uninitialized pointer because it's semantically more correct and harder to screw up.

Well for one I wouldn't design it so both the LSP and the editor need a synchronized view of the underlying file.

Smoking