BreakfastB0b

Except that's not from the frame of reference of the photon. At the speed of light, the Lorentz transform shows that 1) Time stops completely, 2) All distances in the direction of travel collapse to zero. So in a very real sense, "from the photons perspective" it never exists and the point it is emitted from and the point it is absorbed at, are the same point.

Experiencing time and having mass are linked in a very deep way. Objects that experience time, i.e. have some kind of state evolution, must have mass, this is how we know the neutrino has mass even though it's smaller than we can measure, because we measure them oscillating between the various flavours of nutrinos.

This is also how the Higgs mechanism gives rise to "rest mass" in most particles, by constantly exchanging weak hypercharge with them. This oscillation back and forth gives them mass.

I participated in the most recent Bevy game jam and the community has a new tool that came out of Dioxus called subsecond which as the name suggests provides sub-second hot reloading of systems. It made prototyping very pleasant. Especially when iterating on UI.

https://github.com/TheBevyFlock/bevy_simple_subsecond_system

Try writing Go without generics. No typed maps, arrays, slices, channels or function types. Only `interface{}`. Go always had generics, you just weren’t allowed to write your own until recently.

Because go doesn’t have exhaustiveness checking when initialising structs. Instead it encourages “make the zero value meaningful” which is not always possible nor desirable. I usually use a linter to catch this kind of problem https://github.com/GaijinEntertainment/go-exhaustruct

Nix has two types of derivations (builds). Input addressed, and content addressed.

An input addressed derivation’s hash is based on the the hash of all its input derivations and its own derivation. Therefore trusting the association between the cached binary and the derivation requires trusting the builder and a signature. All non-derivation inputs like source code, must be content-addressed.

A content addressed derivation can then be produced easily by rewriting all the derivations with `nix make-content-addressed`. This doesn’t require trust / signatures as every stage of the build is now content-addressed. The final hash could be confirmed through social consensus of multiple distrusting parties.

There’s nothing in theory stopping you from starting with a content addressed derivation other than it being a pain in the ass as you’d have to know the output hash before you built it, or TOFU (trust on first use) it which is then just the same as using the `nix make-content-addressed` approach.

I’m not sure why you think commit signatures are required. Git is content addressed, you can’t tamper with the derivations without changing the hashes and nixpkgs is primarily developed through GitHub. If someone has access to your SSH keys or GitHub account password it stands to reason they’d have access to your GPG keys too.

You’re confusing Outer Worlds with Outer Wilds, both confusingly released around the same time.

Outer Wilds is an indie game where exploration and knowledge is the entire point of the game. It unfortunately has zero reply value as once you’ve pieced together the mystery and how to end the game it’s over. I say unfortunately because it’s honestly the best game I’ve ever played and I sometimes wish I could receive just enough blunt force trauma so I could experience it for the first time all over again.

I really hate this kind of micro-analysis when it comes to health. The human body is really really complicated and getting fixated on things like oxalates is in direct contradiction to longer term studies on overall health that show that eating mostly plants is a good thing.

Go functions are coloured as well. context.Context proliferates everywhere IO takes place to handle cancellation / short circuiting because goroutines can’t be sent signals to die like threads. They have to exit themselves.

I have zero trouble doing that in vscode without vendoring.

If this were true, wouldn’t all corporate profits be next to zero as companies compete on the slimmest possible margins?

Folding Ideas released an excellent video essay recently examining the concept of the metaverse and how it suffers from somewhat of a “No True Scotsman Problem” https://youtu.be/EiZhdpLXZ8Q

That attitude assumes that the go standard library is the global maximum for Getting Stuff Done, and because of backwards compatibility guarantees ensures that it’s difficult to innovate on.

I think having a small standard library is actually a good thing because it encourages exploration of the space of possibilities.

For example Go’s stdlib http.HandlerFunc sucks, people instead opt for leaving it behind entirely in favour of Gin or trying to work around it with bad patterns like interface smuggling.

Not OP but at least for me, over time meat, dairy, etc become so deeply associated with the nightmare of industrial scale animal agriculture that they loose their aesthetic appeal. I know it’s surprising, and it happens slowly, but it happens.

Meaning is use. “Milk” is a fuzzy collection of properties and use cases. Which is why when you say “coconut milk” or “oat milk” people aren’t confused.

Hell, cows aren’t magic. Even “real milk” is just a collection of sugars, proteins, etc. If there’s no difference between the two then what’s the distinction?

But the whole point of "I, Robot" is that the three laws are incomplete and insufficient! That's literally the whole point of the book.

How do you square that away with its use in the standard library, and many third party libraries? Someone’s gotta write the reflection code.

> Go keeps my coworkers from writing code that's too clever for me to understand

Until someone whips out `import “reflect”`.

I’ve always found it confusing that people claim Go is simple when it contains runtime type reflection, which is hiding just under the surface of lots of the standard library like `json.Marshall`. Trying to explain to a new Go developer why []int isn’t assignable to []interface{} is always fun.

The phenomenon of “coloured functions” is usually derided because of the way it infects the call tree. In this sense context proliferation is the same phenomenon. Otherwise no one would really care about coloured functions.

> There has to be a better solution other than needlessly copying data.

Sorry I don’t think I explained myself very clearly.

What I’m saying is Rust allows you to optimise FP style patterns by replacing copying data with in place mutation because the control flow required for handling the flow of immutable data is also well suited to satisfying the borrow checker i.e. explicitly returning the data back to the caller. Because FP patterns can’t automatically communicate through shared mutable references they also lend themselves well to Rust but without the overhead of copying data because an in place mutation can be used instead.

> Not true in my experience. You would use context.Background in a test situation. It's also commonly used for short-lived applications like a CLI. You can see kubectl uses context.Background quite a lot:

My experience with Go is entirely within the context of API and microservice design where circuit breakers are very important which is why my experience with context propagation may be different than your own.

It’s also not surprising to see context.Background() used within tests because it’s being used precisely as I described above to “discharge the constraint” because you can’t propagate the constraint to the caller because test functions in go can only take one parameter `*testing.T`.

You’re correct that they’re fundamentally different things, I didn’t mean to draw a false equivalence between them.

The comparison I was trying to draw between them was the way they infect the call tree and usually demarcate impure functions.

When I said that context.Background() discharges the constraint I meant in the sense that the caller doesn’t need to propagate that argument to its caller as it can just pull a context out of thin air.

However I’ve seen a lot of new go devs confuse context.Background() for forking things into the background.

For what it’s worth, I think coloured functions are actually a good thing. If you’re following clean architecture or something similar coloured functions help you easily distinguish what layer in your application something belongs to.

context.Background() is typically only used when one doesn’t care about the result. If you did care about the result, you should be passing the parent context to preserve the circuit breaker timeout in case the operation takes too long.

I think the level of pain you experience from mutable references in Rust depends on if you’re coming from an OOP or FP background. I have a FP background and so the patterns I use to build code already greatly restrict mutation. You can usually change code that updates data immutably (creating a new copy of it) with mutable code in rust because the control flow of your program already involves passing that new version back to the caller which also satisfies the borrow checker in most situations.

It’s like the ST monad in Haskell; if you modify an immutable value but no one is around to see it, did you really mutate it?

> Go decouples all that coloring away.

Go does have “coloured functions”, it’s called `context.Context`.

Any function in go performing IO usually has to take `context.Context` as its first argument so it’s cancelable. Which then propagates that requirement to the caller just like `async`.

That constraint can be discharged with `context.Background()` just like the async constraint can be discharged by not `await`ing the future in Rust.

I would agree if it weren’t super easy to cause a panic in go.

Index slice out of bounds? panic. Close a channel twice? Panic. Incorrect type assertion? Panic. Dereference nil pointer? Panic.

I would argue that all of these examples which are the most common in my experience are “goroutine scoped” because the goroutine was aborted before they potentially modified the application state in an unknown way.

It’s like not in C, or C++ where out of bounds access has now put the entire application into an unknown state.

You would age the same amount during deceleration that you did during acceleration.

I think your misunderstanding comes from the relativistic twin paradox.

From the perspective of the twin on the spaceship accelerating away from earth, the twin on earth seems to age slowly as well until the space ship twin decelerates and then turns around, during which they perceive the twin on earth to age rapidly.

The acceleration / deceleration of the space ship twin’s frame of reference is what breaks the symmetry of the no-preferred frame of reference during flight.

I don’t remember exactly since it’s been a while since I read it, but in Scott Aaronson’s Book “Quantum Computing Since Democritus” which is about how physics informs what’s computable. He talks about how the behaviour of quantum mechanics follows fairly straightforwardly from considering how probability works with complex numbers / bloch spheres. You can’t properly reproduce Bell’s Inequality without them I think?

This PBS Space Time video does a good job of explaining it https://youtu.be/1Z5fnwUmTSY. tl;dr the inner and outer event horizons of spinning black hole cancel out leaving a naked (ring) singularity which is believed to be prevented by the “Cosmic Censorship Hypothesis”. In the math it causes the event horizon radius to become complex which is believed to be “unphysical”. However maybe not, many “unphysical” mathematical objects have later turned out to be real such as black holes themselves (Einstein thought they were just a mathematical artefact) and anti matter (a result of negative roots of the Dirac Equation). Complex numbers are also an intrinsic part of the way Quantum Mechanics works, so perhaps there are naked singularities.

I have a Physics degree for what it's worth. Though I'll admit I didn't articulate what I meant clearly.

The electron example was assuming that the increasing magnetic field was part of this hypothetical toy universe that violates time translation symmetry. Obviously constructing such experiment in our universe it's not surprising that the electron gains energy because as you said, it's not an isolated system. When considering the system generating the magnetic field it becomes obvious that the overall system does not gain energy.

However our actual universe, at the galactic scale, is just like the toy example. New Space / Energy is created out of nothing as the universe's expansion accelerates. There is no paradox here because conservation of energy is not fundamental but emergent from symmetries via Noether's theorem. Space is a "material" that is not "diluted" by expansion and contains energy.

The inflaton field at the heart of hyperinflation / big bang theory also expands without dilution.

Perhaps there is some larger system our universe is embedded in that does respect time translation system / conservation of energy and the expansion is being driven by a larger process loosing energy but we can't observe it.

Conservation of energy is not fundamental. Noether’s Theorem shows that Conservation Of Energy only arises in systems that exhibit “Time Translation Symmetry” i.e. conducting an experiment now, and conducting an experiment later always are the same.

If you fling a charged particle like an electron through an increasing magnetic field, it will appear to gain energy.

Locally our universe seems to obey Time Translation Symmetry and thus also Conservation of Energy. However the expanding universe is not Time Translation Symmetric, at the scale of galactic clusters new “energy” is created all the time just like the electron in the magnetic field. That’s what “dark energy” is.

All the different conservation laws have roots in symmetries of the system.

Go always had generics, map, slice, chan are all generic. Go just didn't let the user write any generics, so fuck you if you want any other data structure until 1.18.

If you really think you don't need generics, take your code code and replace every

  []int{}, []string{}, map[string]string{}

with

  []interface{}{}, map[interface{}]interface{}{}

and see how much you "don't need generics"