I’ve found it hard to apply this pattern in Go since, if Username is embedded in a struct, and you forget to set it, you’ll get Username’s zero value, which may violate your constraints.
But if you then create a constructor / factory method for that struct, not setting it would trigger an error. But this is one of the problem with Go and other languages that have nil or no "you have to set this" built into their type system: it relies on people's self-discipline, checked by the author, reviewer, and unit test, and ensuring there's not a problem like you describe takes up a lot of diligence.
It only relies on unit tests. The people can fail all day long and the unit tests will catch it every single time. Not special unit tests that attempt to seek out such issues, the same unit tests you are writing in languages that have a stricter type system.
If you forget to initialize a field and the tests don't notice, you didn't need the field in the first place, so it won't matter if it is left in an invalid state.
You just don't get the squiggly lines in your text editor. That's the tradeoff.
The pattern sounds nice in theory, but very cumbersome since now you have to obsessively ensure you have NewX calls everywhere or some form of "validated bool". In the end, you're just validating in a roundabout way and calling it "parsing".
I personally find being robust to errors and having clear error messages is the best option.
Don't focus so hard on getting things right, but rather dealing with things when they go wrong.
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
GitHub don't host runners for Linux × arm64, so if you need this, you need to self-host. You can also run custom AMIs with pre-installed packages, which can speed up workflows that depend on those packages.
> When things go wrong, you need people going through logs working out that there's nothing actually wrong with CI…
I'm on a small team who've been running the Philips Lab self-hosted runners for the past year. It hasn't been difficult to operate. Once deployed, it pretty much "just works".
In my experience, the things that go wrong originate from the GitHub workflows themselves. We usually have to review workflow logs regardless of whether the workflow uses a self-hosted runner or not.
Andrus, thanks for all of your original work! We're currently using this for some automated testing with some additional use cases planned in the future. If there is some other way that you'd prefer us to work with original repo we'd be happy to, i.e. submit PRs, take over some management of it on your original org, etc.
Hey, you're welcome! And actually, yes — I reached out to @duvallj from GitHub regarding this earlier today. He has my original email, or you could email me at my address in my HN account info.
is a type signature for a function, `app`, which should append a vector (`Vect`) of length `n` to a vector of length `m`.
What's cool about Idris and other dependently-typed languages is that the length of the resulting vector, `n + m`, can be tracked in the type. This can prevent a whole slew of errors.
The theory here is good, but I think the implementation is lacking. Haskell's QuickCheck is one of the most mature frameworks for doing what the author calls "data-driven testing", so It might be worth mentioning one of the JavaScript ports compatible with Mocha: node-quickcheck, JSCheck, etc.
ORTC can interop with WebRTC, so you could create a an Edge to Chrome or Edge to Firefox scenario. In fact, you can implement (to some degree) the WebRTC APIs in terms of the ORTC APIs.
