Sometimes we do things just for “the love of the game” and learn something along the way but I couldn’t help scratching my head the entire time while reading this
158 karma · joined January 7, 2019
Sometimes we do things just for “the love of the game” and learn something along the way but I couldn’t help scratching my head the entire time while reading this
$1200 per day.
Your estimation is 50*11 days so $660,000. That’s 4x what Claude cost.
That’s assuming that you actually get those 50 people to work without blockers, stepping on each other, or other coordination issues. The coordination complexity alone is astounding.
I don’t like it necessarily, but Claude wins here, easily. It’s not close.
> So much precision is required that session musicians are playing most of the things you hear, not the actual artists
I’m sure the session musicians don’t appreciate this statement. Just because they can play with high precision and reliability doesn’t mean they are playing without soul.
If the featured artists can’t do so on their own, that’s sort of a knock on them, isn’t it?
So you have available all of the original Pokémon
I have a hard enough time getting humans to write tests like this…
Your code ends up using the driver raw in these cases, so why not just use the driver for everything? Your codebase would be consistent at that point
Perfectly fair. I shouldn’t have stated it as an absolute. If I could still edit it, I would change my statement to “don’t default to a mock”
> Would you mind explaining what you mean here
Gladly. Martin Fowler provides really clear definitions for the different types of test doubles.
https://martinfowler.com/articles/mocksArentStubs.html
Maintaining that your Fakes are correct takes work. An easy way that I’ve found to do that is to run the tests against a “real” component and the Fake component with the exact same set of assertions and set up. If that test breaks, then you know that consuming code should also break
This problem is exacerbated if B is a popular object used by many components.
IMO if you own A and B, never use mock. Possibly write a Fake B if B is non deterministic or slow. Then write a parity test for B and Fake B
You can disable it like any other plugin though? Really easily? And it’s a paid service. Just don’t pay for it.
Seems like rage bait that a lot of people are falling for.
Of course, if it turns out it’s phoning home with training data by default then I will also change my tune, but it doesn’t seem to be doing that
To make an analogy to music, I see it like brass players at the advent of the valve.
It’s a new way of playing the instrument. The old ways and new ways aren’t congruent in all ways, but the new way does seem to have a higher skill ceiling
The go ecosystem frequently utilizes `go generate` to handle boilerplate code generation. That’s the exact same way `thiserror` utilizes macros to generate plain error structs. While macros can do more, in this case it’s the same.
The former is just macros for error definition
The latter is just a wrapper around box dyn error
Here is a slightly different version I wrote that has 0 allocations per loop.
Took about 26 seconds.
I'm welcome to suggestions on how to make it more readable! Its been a few years since I have written Go professionally
A bit of an understatement. The author is the current Golang project lead and a member since it’s inception
If your past experience involved people comparing error.Error() strings I’m sorry. That’s awful and I can see why that would be a nightmare