rfiat

I think a much bigger downside would be its effect on the price of your insurance. I can't speak for any other country but in the UK insurers have a reputation for being petty about modifications. Even something as minor as a DIY heated seat switch would have to be declared to your insurer who could refuse to cover you or charge a silly premium for cover.

> For the opposite word, "expensive", it all depends on the word before it: "as expensive" or "more expensive".

Frustratingly, I find this isn't always true in practice. Lots of people use "x times as y" and "x times more y" interchangeably. To avoid ambiguity I try to only use the former in any context where precision is useful.

I don't think the distinction you're trying to make is helpful here if I've understood you correctly. A good faith interpretation of haastad's comment would be that they were thinking of "insertion order" when they said "a deterministic ordering". Even if we were being pedantic, their comment is still correct - for iteration order to be the same as input order then deterministic iteration ordering isn't sufficient (this seems to be the point you're making) but it is necessary.

Their first sentence:

> I bet it's an artifact of Go having a randomized iteration order over maps

is correct per Gojq's author [0]:

> gojq cannot implement keys_unsorted function because it uses map[string]interface{} to represent JSON object so it does not keep the order. Currently there is no plan to implement unordered map so I do not implement this function.

It would of course be possible to work around this limitation of Go's built-in map type but that's not the point. The author makes it clear that this limitation is the cause for Gojq's behaviour.

[0] https://github.com/itchyny/gojq/issues/50

GP is correct, per the README:

> gojq does not keep the order of object keys. I understand this might cause problems for some scripts but basically, we should not rely on the order of object keys. Due to this limitation, gojq does not have keys_unsorted function and --sort-keys (-S) option. I would implement when ordered map is implemented in the standard library of Go but I'm less motivated.

And later in the same file:

  gojq does not support some functions intentionally;
  <snip>
  --sort-keys, -S (sorts by default because map[string]interface{} does not keep the order),

What you're describing is named the "curb cut effect" [0].

> The curb cut effect is the phenomenon of disability-friendly features being used and appreciated by a larger group than the people they were designed for. For example, many hearing people use closed captioning.

[0] https://en.wikipedia.org/wiki/Curb_cut_effect

What you say about traction is a good point. I think "will it be successful?" is a very different question to "will I like it?".

At one end of the scale for me is Rust. I discovered it through organic hype and I like the language but it's not successful enough for me to have found a job writing Rust.

At the other end is TikTok. I saw many ads for it before anyone I know ever talked about it. It's massively successful but it doesn't appeal to me in the slightest.

> It has been so energetically hyped. Real standards don't have to be promoted

I find this interesting because it's the first heuristic I use to judge anything new, technical or otherwise (e.g. TV shows or games). Did someone pay to put it in front of me?

It turns out to be a mostly true assumption that you'll hear about good things organically.

You're absolutely right, there are about a million and one rabbit holes you can go down if you _really_ want to understand the tools you use but in the vast majority of those cases you're better off relying on a higher level abstraction.

The interesting part to me of your analogy is that it can demonstrate how having an understanding of what's going on under your layer of abstraction allows you to generalise.

To wring the last bit of life out of the gearbox analogy: if you tell a mechanically inclined driver that blipping the throttle will make their downshifts smoother, they'd hopefully understand how rev matching can be generalised to upshifts too. If you tell a "black box" driver then they probably wouldn't be able to do the same. Of course, the analogy falls apart a bit because understanding rev-matched upshifts isn't particularly useful :)

I've forgotten most of the "advanced" git knowledge I ever learned but I get a lot of value out of the (admittedly not very advanced) understanding that, as you said, commits are a DAG and that branches are just named pointers to nodes on the DAG. That understanding lets me generalise to, for example, backing up a branch (with git branch/tag) before doing a tricky rebase so I can restore it (with git reset --hard) if I need to undo.

I agree that exploring every rabbit hole to the end isn't beneficial - understanding the DAG is typically the only "advanced" git knowledge I need and I've only very rarely had to peel back more layers. I think this:

> It's good to know they exist and be able to dig in when needed/wanted.

is a good way of putting it. My ideal low-level understanding of most tools is knowing just enough that I know what to search for if I ever need to go deeper.

The reflog is very helpful but I don't think it counts as an "undo". Some operations (like git add or git push) won't show up in the reflog.

Even the operations which do show will often require more thought to undo than a hypothetical "git undo" would. I know how to use the reflog but I often go out of my way to avoid it because "git branch tmp HEAD; git $POSSIBLE_MISTAKE; git reset ---hard tmp; git branch -D tmp" requires less effort than deciphering the reflog's output.

> Do I need to know how a gearbox works to drive stick shift?

No, but it helps. If I treat my car's powertrain as a black box then it won't be intuitive that:

  * I shouldn't slip the clutch to hold my car on an incline.
  * Blipping the throttle gives me smoother downshifts.
  * Double clutching lets me shift from 2nd to 1st while rolling.
  * I can use the engine to slow my descent on longer hills and avoid brake fade
  * I should park the car in gear for safety
  * etc.

Whether it's better for a given person to memorise that list of facts or to understand the concepts behind them would depend on how much they drive. As a developer I've found it helpful to gain an understanding of the tools I use daily beyond "here's the commands to copy/paste when you want to do xyz".

I disagree. It has a formal grammar so at least in a CS sense [0] it's a language. Why is JSON not a language but e.g. TOML or YAML are?

[0] https://en.wikipedia.org/wiki/Formal_language

I appreciate your comment. My intention wasn't "Go is dissimilar because it's bad and Rust is good" but I can see why you'd think that. I'll attempt to clarify.

The reason I like and recommend Rust is the number of decisions it gets right which are completely orthogonal to the borrow checker. It's clear that a lot of thought was put into the unexciting parts of the language. That's why I like using it even though I don't particularly need the borrow checker and I'd be happy with GC. Some examples off the top of my head:

  - Expression-oriented nature makes code easy to write and nice to read
  - Compilation errors are as clear and helpful as possible
  - Comprehensive yet skimmable API documentation

In short, Rust is a nice language outside of the borrow checker.

A lot of the things which strike me as nice about Rust can't be said about Go. For that reason I think Go is a surprising suggestion for someone who likes Rust but doesn't care about ownership and lifetimes.

There are a number of minor but valid frustrations I encounter when writing Go which are completely orthogonal to the brief of "C but with GC and easy concurrency". I'd understand if these problems were a result of the language's goals but often they seem to exist for no particular reason. In that regard I think Go is quite dissimilar to Rust.

I hope that explains my viewpoint more clearly :)

As the sibling commentor said, syntax highlighting is only one example meant to illustrate Go's sometimes unnecessarily frustrating design. In case it wasn't clear, the example wasn't that Rob Pike doesn't like syntax highlighting. The example was that Go's playground doesn't have syntax highlighting (even as an option) for a reason as arbitrary as "because I said so".

That is why I find Rust and Go to be dissimilar. Rust is a language full of good ideas, almost all of which didn't originate in Rust. Go feels like it was designed with a very specific brief - "we want C but with GC and easy concurrency" - but whose designers otherwise had an NIH syndrome-like aversion to good ideas and common sense.

It's interesting that you find Go to be Rust-adjacent. Setting aside the USPs of each language (goroutines and borrow checker respectively) and just speaking about the general experience of writing code, I find Go painful for all the reasons that I find Rust pleasant.

The best summary I can give of Rust is that it was designed by people who learned from the mistakes of the programming languages that came before it.

The best summary I can give of Go is to quote Rob Pike's response [0] to a request for syntax highlighting in the Go playground:

> Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods (http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I use monochromatic numerals.

[0] https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...

It should be noted that it's possible for electric (~heavy) vehicles to emit less brake dust than conventional vehicles due to regenerative braking

If you don't mind a comment about your English, I'd suggest that what you wrote seems like it's better described as "tongue in cheek" than "sarcastic". "Sarcastic" can have connotations of meanness or snarkiness whereas "tongue in cheek" suggests good-natured joking, which seems to match the tone of the original post better.