sapiogram

Their font rendering looks awful on non-high dpi displays, and the devs don't seem to care at all. https://github.com/zed-industries/zed/issues/7992

> Giving us $50 trains to Tromsø instead of $500 planes.

It's only $50 if the government pays for the rest of the ticket. $50 per passenger won't even cover track maintenance. Source: My ass, but I still think I'm right.

Making drivers miserable is part of the intention, they want people to drive less because it's annoying as hell for everyone else.

In Norway, C# seems to have surpassed Java in the finance sector several years ago. C# is also much bigger than Java in game development.

Because people think Golang is immune to bugs that it's not immune from.

> The violation occurs if the program keeps running after having violated a memory safety property. If the program terminates, then it can still be memory safe in the definition.

I don't know what you're trying to say here. C would also be memory-safe if the program just simply stopped after violating memory safety, but it doesn't necessarily do that, so it's not memory safe. And neither is Go.

"Memory safety" has a specific, binary definition.

"Crashing" is a very positive spin. "The heap getting the corrupted until it was killed by the operating system" is another interpretation.

> I feel like x86 itself is kinda legacy tech.

The impact of ISA is overrated, it's much more important that the ISA continues to grow and adapt as CPUs get larger.

> For the few that can, it's going to cost >$50,000 just to refill the liquid helium

In this case, they were going to have to do that anyway. Might as well shut it down right away.

Copy is already banned for any type that directly or indirectly contains a non-Copy type, and Vec contains a `*const T`, which is not Copy.

This is why I've completely stopped using the term, literally everyone I talk to seems to have a different understanding. It no longer serves any purpose for communication.

> Afaik it's the only way to early-abort an operation since Goroutines operate in a cooperative, not preemptive, paradigm.

I'm not sure what you mean here. Preemptive/coorporative terminology refers to interrupting (not aborting) a CPU-bound task, in which case goroutines are fully preemptive on most platforms since Go 1.14, check the release notes for more info. However, this has nothing to do with context.

If you're referring to early-aborting IO operations, then yes, that's what context is for. However, this doesn't really have anything to do with goroutines, you could do the same if the runtime was built on OS threads.

Very cool benchmark, thanks!

Yeah, not the entire northern sky at least. It's located only 30 degrees south though, so its coverage will be pretty damn good.

ELT will not discover many new objects, it's built to do deeper followup observations of known targets. On the other hand, Vera Rubin was designed to be a survey telescope, repeatedly imaging the entire night sky to discover new objects. It will not do targeted observations, or at least very few.

That's a reasonable assumption, but given Sedna's unusual orbit, its origin could also be quite different from Pluto's.

> Modern GPUs have a rated lifespan in the 3-7 year range, depending on usage.

That statement absolutely needs a source. Is "usage" 100% load 24/7? What is the failure rate after 7 years? Are the failures unrepairable, i.e. not just a broken fan?

It's probably something in the rendering pipeline. What operating system?

It's so incredibly frustrating. Text rendering is the primary feature of a code editor, but no one on the Zed team seems to use a non-retina screen.

Github issue for context: https://github.com/zed-industries/zed/issues/7992

Are you using dark mode? To me, text looks absolutely awful in light mode, but okay in dark mode. Still noticeably worse than any other editors, though.

AAA games are not even close to being write-able by one person, what are you talking about. You couldn't even write AAA games from 20 years ago.

Some options:

- Make sure no one mutates the slice ever, making it safe to read

- Guarding the slice behind a mutex, requiring anyone who reads or writes it to lock the mutex first

- Using some kind of thread-safe slice implementation

> You must clone the slice on both write and read, right?

I haven't looked at the code, but that doesn't make sense to me. If you can't read the slice safely, you also can't clone it safely.

They do, there's a concurrent hashmap in the standard library. It doesn't get posted here or on Reddit, though.

Thank you for debunking it so I didn't have to. I don't think I've ever seen someone post a low-level/concurrent data structure in Go that wasn't wildly unsound, so I assumed this was too.

> (if I recall correctly JPEG as a format can encode an image with a higher fidelity than PNG, at least in some circumstances)~

PNG is a lossless format, so I don't think that's possible, unless there's some specific feature that is not available in PNG.

Note that `go clean` doesn't actually clear dependencies, which are stored globally. It's possible that your initial compile also wasn't a true clean compile, because some modules were already cached globally.

My build times also included fetching dependencies, which only took a few seconds on my modestly fast 8 MB/s network.

Thanks for actually including the slow repo in your comment. My results on a Ryzen 5900X:

* Clean debug build: 1m 22s

* Incremental debug build: 13s

* Clean release build: 1m 51s

* Incremental release build: 24s

Incremental builds were done by changing one line in creates/symbolicator/src/cli.rs.

It's not great, but it sounds like your experience was much worse for some reason.