I haven’t read the whole thing, but it starts off talking about a gene mutation in our ancestors species 10 million years ago that lets us process alcohol. So they are taking a little artistic license.
Their wikipedia page says they announced “a partnership with RepairPal, a network of certified auto repair shops and dealerships across the US, to give owners access to 4000 service points from day one”. I don’t know if a “service point” is the same as a mechanic shop though.
RepairPal is just a rent seeking middleman like Angi's list. I don't see what that partnership will provide, certainly not shops that are trained to repair the truck.
I've been using it through this and it occasionally stops with an error message saying something like "repeated 529 responses". Kind of annoying but it's fine.
I think I would like a “stackvar” declaration that works the same as “var” except my code won’t compile if escape analysis shows it would wind up on the heap. I say that knowing I’m not a language designer and have never written a compiler. This may be an obviously bad idea to somebody experienced in either of those.
I commented elsewhere on this post that I rarely have to think about stacks and heaps when writing Go, so maybe this isn’t my issue to care about either.
Go has been my primary language for a few years now, and I’ve had to do extra work to make sure I’m avoiding the heap maybe five times. Stack and heap aren’t on my mind most of the time when designing and writing Go, even though I have a pretty good understanding of how it works. The same applies to the garbage collector. It just doesn’t matter most of the time.
That said, when it matters it matters a lot. In those times I wish it was more visible in Go code, but I would want it to not get in the way the rest of the time. But I’m ok with the status quo of hunting down my notes on escape analysis every few months and taking a few minutes to get reacquainted.
Side note: I love how you used “from above” and “from below”. It makes me feel angelic as somebody who came from above; even if Java and Ruby hardly seemed like heaven.
For me, avoiding heap, or rather avoiding gc came when I was working (at work) on backend and web server using Java, and there was default rule for our code that if gc takes more than 1% (I don't remember the exact value) then the server gets restarted.
Coming (back then) from C/C++ gamedev - I was puzzled, then I understood the mantra - it's better for the process to die fast, instead of being pegged by GC and not answering to the client.
Then we started looking what made it use GC so much.
I guess it might be similar to Go - in the past I've seen some projects using a "baloon" - to circumvent Go's GC heuristic - e.g. if you blow this dummy baloon that takes half of your memory GC might not kick so much... Something like this... Then again obviously bad solution long term
The content of the stack is (always?) known at compile time; it can also be thrown away wholesale when the function is done, making allocations on the stack relatively cheaper. These FOSDEM talks by Bryan Boreham & Sümer Cip talk about it a bit:
What is especially bad about this ad? To me it seems no worse than the infernal Paintin Manning ad from last year or the State Farm Megan Trainor ad this year. If this was on rotation in NFL games it wouldn’t make me scramble for the mute button any faster than other ads.
It almost seems intentionally AI? If anything, if my job at Maccas…ahem, McDonald's (sorry, spot the Aussie) is in marketing, I’d expect to to be promptly fired if this wasn’t expected to pass for anything less than satire.
Have you ever ridden a bike over a canal? The ad was pushed in front of a lot of people who have. I thought it was creepy throughout, but I can't believe they used that clip up front.
Well, for a start it's a bad concept, but also the actual images are kinda nightmarish. The living teddy bear is particularly off-putting. And it's very obviously AI slop; physics is at best a mild suggestion.
I have taken it as a tongue in cheek reference to the current AI slop discussions, so like purposefully made sloppy. Appropriate joke? Apparently not, according to the masses. Well, just a matter of taste.
I mean, it's _possible_ they were aiming for "so bad it's good", missed, and ended up at just "really, really bad", I suppose. In practice, conscious attempts at "so bad it's good" virtually never work out; it is a thing which happens, not which is deliberately done.
Yup, so I'm not against fixtures per se, they have their uses and can be a pragmatic choice. I just often don't like when I have to use them, as it's often to patch over something else. But things are never perfect.
I use the pattern you describe, but not in Ruby. I use code to build fixtures through sql inserts. The code creates a new db whose name includes a hash of the test data (actually a hash the source files that build the fixtures).
Read-only tests only need to run the bootstrap code if their particular fixture hasn’t been created on that machine before. Same with some tests that write data but can be encapsulated in a transaction that gets rolled back at the end.
Some more complex tests need an isolated db because their changes can’t be contained in a db transaction (usually because the code under test commits a db transaction). These need to run the fixture bootstrap every time. We don’t have many of these so it’s not a big deal that they take a second or two. If we had more we would probably use separate, smaller fixtures for these.
reply