In _theory_ using a thin-client and booting into a cloud machine means you can "upgrade" your machine in a couple years w/o having to replace the thin-client.

Could be easier for grandma, could reduce e-waste, will definitely be used to pigeon-hole us into an endless hell of subscription software.

In practice it means your compute time is being micro-time sliced to the maximum so it will probably perform incredibly bad.

I also think "adoptability" should be a consideration. Perhaps AsciiDoc would be a slightly better fit, but every developer I know is already familiar with MarkDown and at the end of the day convincing people to write good docblocks is easier if they don't have to pick up new syntax.

I use VaultWarden to store my 2FA info which (aside from being very handy) replicates the codes offline on each device I sync my vault to.

Not sure if apache or systemd are to blame, or security extremists, but I hate this kind of magic, please crash my app with a clear message instead of doing shit behind my back and showing me fake reality.

I think Go's generics are reasonable, but not quite powerful enough to scale.

It's all well and good to generalize basic containers and functions (good, in fact), but I wish the language was better at inferring types.

I'm sure this is something that will improve with time, but a bit after generics were released, I tried to build a type-safe language evaluator in Go using generics and found them lacking the kind of type-narrowing necessary for fully-generic architecture.

Short write-up of my conundrum on SO, if anyone is interested: https://stackoverflow.com/questions/71955121/how-to-type-swi...

TypeScript has me spoiled. :)

I haven't looked into Go's actual implementation but isn't this kind of downcasted better suited for interfaces. Your code, as is, wouldn't translate to something like Rust which uses monomorphization; you are doing a runtime "inspection" of the types. This looks more in the domain of duck-typing than something that generics handles.

Here's a writeup exploring this very topic, and showing how Go's generics will currently give worse performance than just using an interface.

https://planetscale.com/blog/generics-can-make-your-go-code-...

Yes, I was trying to get it to infer the types for some code I was writing as well (a generic funcopt for two different types) and it couldn't - made me specify the type manually.

I think I am glad that kind of stuff doesn’t work, because that was pretty hard to read. Go is trying to keep things simple.

If you want a sophisticated type system with a language they complied to native code then use Swift or Rust.

I personally think it is good to have some choice in complexity level and that at least one language, Go, tries to carve out a niche in simplicity.

I am only barely convinced that generics was the right choice for Go.

IME complexity is mostly a feature of intention and business logic and will usually creep in all the same, it just manifests as tons and tons of for loop spaghetti, duplication and code generation. You may not have to actually learn any "hard" language features, but instead you get a large amount of moving parts that can't be abstracted away cleanly and that you need to mentally track. I've just ported a relatively complex bit of business logic from Go to Scala and while the result is definitely not as "simple" in terms of language features used, it's a lot less code in a structure that I can actually keep in my head a lot more easily than reams upon reams of low-level imperative details that are kept consistent only by the implementer's self-discipline. Forcing code to be easily digestible by limiting the language feature set doesn't seem to work too well outside of a relatively limited space of straightforward applications.

I think this is an interesting idea, though I suspect "on net the status quo is worse environmentally" is a hard question to answer w/o the aforementioned in-depth reviews (at least to an extent; obviously the current system has problems).

The concept sounds good in theory, but I think it's going to be nigh unworkable in practice. The NCLB/high-stakes testing era exposed many problems with tying educator pay to student outcomes -- chief among them that student outcomes didn't improve.

As I recall they had the teachers themselves graded those tests, so naturally they cheated.

It's not needed right _now_, perhaps, but wait a few months or a few years. Next time the job market shifts back to the employers, the incentives will align the other way.

The auto-completion alone is worth it IMO. I've been using fish for 6 or 7 years now, and having it hint ahead some obscure command that I only use once a month saves me so much time reading MAN/searching online.

Pair that with tldr and it's a really good experience.

Surprised I had to scroll this far to see this. It's an objectively cool project, even if it doesn't make the most financial/business sense. Doesn't seem like that's the point.