sping

I remember it as just beer and cider, with the addition of blackcurrant making it a Purple Nasty, and all sorts of tales of how they allegedly reacted to make a vicious drink more than the sun of the parts that I am sure was fiction.

And for Americans, this means alcoholic ciders, since they also call raw apple juice cider, and most Americans have no idea what a blackcurrant is (a delicious intense berry that was illegal to cultivate in the US for a lot of the recent past).

Looks like they have reasonable height windows, unlike the weird little slit windows that Amtrak typically has for some reason. I've always assumed it's to minimize greenhouse effects, because maybe nobody was able to imagine blinds or heat-reflective glass used elsewhere.

While Amtrak trains always seem crude and old fashioned compared to modern trains in other countries, one thing they've always been is very comfortable and spacious. I'm a little concerned by 27% more seats - is that the end of the generous space?

I'm probably unlikely to find out for a while, because faced with the usually dramatically higher prices for ~20% shorter journey times, I usually choose the cheaper, slightly slower standard Amtrak service instead of Acela. It's a testament to the benefits of rail that even the rickety slow Amtrak trains are often still a good option for the few journeys they serve.

Well yes they are more efficient than butyl for drag and weight, it's just a very small amount that would be hard to detect. And it's only for acceleration that rotational weight counts extra - up to double at the tire edge. Climbing at constant speed it is just simple weight.

And if course on the flat at constant speed weight is irrelevant, which is why a few kg of weight has a small effect on times, and 100-300g less tube weight is barely measurable, being a fraction of one percent better some of the time.

I don't think so. I think they're better but it's a very small percentage in terms of times. Close to latex IIRC.

I do believe there is a solid benefit in comfort compared to typical butyl with supple tires but that's pretty subjective.

The only downside in my mind is they're slightly loud. I'm very happy with them, and recently had a puncture and was happy that the patch seems to hold.

There are lots of cyclists in the photos. We're you expecting them to all crowd together in one spot?

I wasn't trying to give you advice, I was describing the situation in general. 🤷

It's very hardware dependent with a few problem's like Nvidia. For Best results go established brands that support Linux like thinkpads.

Steak fries are not shown here. They're bigger again.

I'm now 1 year in to working in Go having been mostly C++ and then mostly large-scale Python dev (with full type annotation).

Frankly, I bristle now at people giving Python a hard time, having worked with Go and I now hate Go and the de-facto ethos that surrounds it. Python may be slow, but for a lot of use cases not in any way that matters and modern computers are very fast. Many problem areas are not performance-limited, and many performance problems are algorithmic, not from raw statement execution. I even rewrote an entire system in Python and made it use 20% of the CPU the former C++ solution used, while having much more functionality.

The error returns drive me nuts. I looked around for explanations of the reasoning as I wasn't seeing it, and only found bald assertions that exceptions get out of control and somehow error returns don't. Meanwhile standard Go code is very awkward to read because almost every little trivial function calls becomes 4 lines of code, often to do nothing but propagate the error (and errors are just ignored if you forget...). With heavy use of context managers, my error and cancellation handling in Python was always clean, clear, and simple, with code that almost read like whiteboard pseudo-code.

The select statement can be cool in Go, but then you realize that literally 98% of the times it's used, it's simply boilerplate code to (verbosely) handle cancellation semantics via the context object you have to pass everywhere. Again, literally code you just don't need in exception-based languages with good structures to manage it like Python context managers.

And every time you think "this is stupidly awkward and verbose, surely there's a cleaner way to do this" you find people online advocating writing the same boilerplate code and passing it off as a virtue. e.g. get a value from a map and fall back to a default if it's not there? Nope, not offering that, so everyone must write their own if foo, ok := m[k]; !ok {...} crap. Over and over and over again the answer is "just copy this chunk of code" rather than "standard libraries should provide these commonly needed utilities". Of course we can do anything we want ourselves, it's Turing Complete, but why would we want to perpetually reinvent these wheels?

It's an unpopular language, becoming less popular (at least by Google trends) and for good reason. I can see it working well for a narrow set of low level activities with extreme concurrency performance needs, but it's not the only language that could handle that, and for everything else, I think it's the wrong choice.

Go code is always an abomination.

Along with "it's sometimes hard to detect your own stink"