Rust is not race condition free, it guarantees no data races though.

> That's an interesting view. I tend to use Live Components whenever I'm rendering a list, because if you don't, you'll quickly notice how the entire list gets re-rendered and sent over the wire whenever one of the elements on the list changes.

That's what streams are for https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html#s...

That's new! I'll go have a look, thanks.

Came here to ask the same. kx.com is just some marketing page. I still have no idea what kdb+/k/q is.

The app probably uses something `navigator.language` to determine which unit to use. Unfortunately the browser doesn't expose any API to get the user's preferred measurement units. I assume it works for you because your browser locale is not en-us.

Downloading roms is certainly not illegal, sharing them is. From my experience most older Nintendo games are not available for purchase. I would gladly pay to play classic Pokémon for example games on the switch (or on Steam).

And nintendo will later rerelease those classic pokémon games in some form and rake in money off people like you (and me). Waiting is part of their market strategy. The NES and SNES classic editions sold out quickly iirc; when the time is right, a gameboy classic might do the same.

I had the same exact same experience. If the uninstallation wasn't such a pain in the ass I might even give nix another try in the future.

It looks really nice but it's a usability nightmare in my opinion. Swiping back with the touchpad doesn't work. Pinch to zoom doesn't work. Page up/down and home/end don't work. Most clickable elements are not focusable I'm not trying to shit on the devs here. I just wish more developers were more mindful of usability/accessibility. Bonus: Press tab a couple times to break the scrolling.

Hi, I am the developer of the PolarBear. Thanks for your feedback. I agree with you and tried to add some shortcuts. But I am not a website developer. I can do website. But It is not my profession. I tried to do a nice website in a short time and I used a library named swiper.js I hope soon I can find more time and improve the website or have more funds and hire someone.

Oh yeah, I see what you mean and I agree with you!

Torvalds and the OP are talking about userland software.

Wow I forgot how unergonomic go can be. And that example even is a potential memory leak...

> And that example even is a potential memory leak…

Yup more generally a slice is not an actual vector, the backing array lives independently from the slice, meaning if you "reset" a slice

    a = a[:0]

all the elements are still part of the backing array, and thus still referenced.

That's also why write-sharing (which is trivial in Go) is super dangerous e.g.

    a := GetSlice()
    b := a[:]
    a = append(a, 1)
    b = append(b, 2)

depending on the size of the backing array associated with slice `GetSlice` returns (aka the cap() of the slice), the last element of `a` might be 1 or 2.

Um, what? My impression was always that the last line would copy the underlying slice since someone has already appended to the original backing array. That's the whole point of why append is not in-place. You get a new slice value back because the extension may have happened by copying data into a new backing array.

> My impression was always that the last line would copy the underlying slice since someone has already appended to the original backing array.

Nope. append only copies if there’s no room in the backing array, if there is it will just extend the slice in-place and set the new elements.

So if there’s room, a will be extended in-place, with the new element set, then b will be extended in-place, overwriting the element set by a.

Hell, how would append even know that somebody else appended to the backing array? As far is it can see that might as well be leftover garbage.

> You get a new slice value back because the extension may have happened by copying data into a new backing array.

That only happens if the backing array is full aka len() + new > cap().

> how would append even know that somebody else appended to the backing array? As far is it can see that might as well be leftover garbage.

Well, the backing array knows its length and capacity, and the slice knows its length, so it's quite trivial to see that there are elements in the array beyond the length of the slice.

EDIT: I'm shocked and appalled by the fact that you're completely right. https://play.golang.org/p/UZSlBMUlc_E

> Well, the backing array knows its length and capacity

arrays don’t have capacity. The capacity of a slice is the length of its backing array (minus the offset of the slice in the array, which is why slices do need to store a cap separately).

> it's quite trivial to see that there are elements in the array beyond the length of the slice.

There are always elements in the array beyond the length of the slice (unless the slice is « at capacity »).

> EDIT: I'm shocked and appalled by the fact that you're completely right. https://play.golang.org/p/UZSlBMUlc_E

Yup. Go slices are fun. And by fun I mean error-prone.

Well most of the trouble really comes from them having double-duty as actual slices and add-hoc pseudo vectors.

> - Low res analog video -> high res digital video

> - Modest transmission range -> long range

Those are not really new. DJI has been selling their standalone digital FPV system for a while now. And there are lot's of different long range radio systems available.

But I agree that this is impressive. I wonder if Betaflight, etc. will also implement some kind of bail out feature.

Betaflight already has very rudimentary RTH / "GPS Rescue" functionality, obviously without ground/forward sensors it's not as good, but it does work pretty well for "oh no something has gone wrong" in the form of video or control link loss.