> The first thing that I dislike about this is that it encourages thinking of semicolons being inserted instead of statements being terminated
It might, but that's irrelevant since you never think about semicolons in Go at all.
> I like these formatting choices, but I'd prefer if the "wrong style" was still syntactically valid and a formatter would be able to fix it.
Your preference likely comes from some idealistic idea of "cleaniness" or similar, which isn't very convincing. Forcing everyone to use the same style is a huge win, to the point that it's a mistake to do anything else, as seen in the description of what Odin does. Completely wrong priorities there and refusal to learn from the past.
"Code formatting" isn't some inherent property of code that we must preserve at all costs, just a consequence of some unfortunate syntactical choices. There's no inherent reason why a language needs to allow you freedom to choose how to "format" your code. And there are in fact a lot of reasons why it shouldn't.
EVs are only quieter at very low speeds. If they're going 20 mph or less, they're great, but any faster and air and rolling resistance is most of what you hear.
It's also just as easy for a sociopath in an EV to roll down the windows and blast the neighborhood with noise from the stereo.
EVs are better in the sense that the mufflers of ICE vehicles can be deliberately defeated by twits.
The starting point is anti-anything-but-a-car, so it's understandable that in the process of getting to any sort of parity you'd feel like it's "harassment".
It's like claiming getting rid of slavery is "harassment", because your unfair privileges are being taken back.
No, just a 20+ year C++ and Java developer, while you clearly haven't used modern Java. Now, I admit that because I have a lot of experience in low-level programming, I am often able to beat Java's performance in C++, but not without a lot of effort. I can do better in Zig when arenas fit, but I wouldn't use it (or C++ for that matter) for a huge program that needs to be maintained by a large team over many years.
> Parts of the GC language crowd in particular have come to hold some false optimistic beliefs about how well a GC can handle allocations.
Yep, the idea is "we've made allocations fast, so allocate away!". But that's a trap — every allocation puts pressure on the GC, no matter how fast you've made the very act of allocating. It's a terrible mindset to encourage the users of your language to have.
Then there's the more insidious problem — to make allocations fast you must have traded something off, like GC throughput. So now your GC is slower and encourages programmers to allocate, which makes it even slower.
This is very dependent on the environment. I would not be so confident saying this about the USA in particular.
If you can stick to at least half-decent dedicated cycling infrastructure separated from cars, sure. If riding alongside traffic, I wouldn't be surprised that, depending on the exact route, the gains wouldn't outweigh the risks.
Generally speaking, operating a bike safely is considerably more difficult than a car and the margins of error are tiny.
That combined with the parent's post is, perhaps counterintuitively, somewhat concerning.
The proper technique for yielding to pedestrians wishing to cross is to start slowing down early, as if you were planning to stop before the crossing. That sends a clear signal to the pedestrian they're good to start crossing. Then you're free to speed back up. This is very comfortable for the pedestrian and the vehicle never needs to stop, so the slowdown is minimal.
That Waymos apparently don't act this way and seem to need to send an explicit signal to pedestrians sounds concerning to me, even if its ultimately safe.
Waymo does slow down as it approaches stop signs (usually where crosswalks are) and it will slow down if there is a pedestrian entering the roadway (crosswalk or not) since it doesn't want to crash into them.
The explicit signal of a driver noticing you (eye contact) is replaced by the signal above the vehicle. Are you not equally concerned that pedestrians have to get an explicit signal from drivers who are legally required to yield or stop??
Ah, so this particular pedestrian crossing wasn't at a stop sign (we were at the big historic army place out by the Golden Gate bridge) so that might explain it.
It might, but that's irrelevant since you never think about semicolons in Go at all.
> I like these formatting choices, but I'd prefer if the "wrong style" was still syntactically valid and a formatter would be able to fix it.
Your preference likely comes from some idealistic idea of "cleaniness" or similar, which isn't very convincing. Forcing everyone to use the same style is a huge win, to the point that it's a mistake to do anything else, as seen in the description of what Odin does. Completely wrong priorities there and refusal to learn from the past.
"Code formatting" isn't some inherent property of code that we must preserve at all costs, just a consequence of some unfortunate syntactical choices. There's no inherent reason why a language needs to allow you freedom to choose how to "format" your code. And there are in fact a lot of reasons why it shouldn't.
reply