It's not, because most languages don't have an `else` clause in their for loop (and in my experience with Python that clause is quite confusing so its use is not common).
And a for loop can be executed 0 times, so without a mechanism for a fallback it might not have a value to yield.
I think a language where it is an expression should also let the loop accumulate a value. In those cases you could just have it return the identity/base type of whatever you are accumulating.
Can someone confirm what intensity is high intensity?
E.g, I have a rowing machine that leaves mildly out of breath and makes my heart beat quickly, is that HIIT? Or is HIIT more like stair climbers, which cause me to almost collapse after doing them for 12+ minutes.
If you can do it for more than 1 minute, than it's not high intensity.
Not to say it's not a good-great workout, but it's not the HI in HIIT.
Also - hello fellow punishment lover! I rowed in high school & college & used to own an erg and am considering buying another one. They are so. fucking. time. efficient (HIIT evangelism be damned).
I've used Prisma before, and I will note that there pace of feature development seemed mind numbingly slow for a company as large as they were. Entirely possible I'm missing a lot of things, but it was just a big disappointment overall.
The good thing about all of this is that the law doesn't really matter. People will complain about copyright, but the tech is here and the law will follow.
Does anyone really thing this anti-Copilot case has a chance of winning when my guess is that Copilot adoption is exponential over time.
Strongest counter argument is the Supreme Court struck down abortion even though abortion was rising in popularity. So that's a bit worrisome.
It's a good question, and a very mature/well-engineered Docker dev environment probably gets you near-parity with an equivalent nix setup. That said, my reasons are:
- Although not _all_ of our projects need nix builds in the end, at least a few do, and acquiring their devshells is essentially zero-effort (you just ask nix for the devshell for the package instead of the package output itself)
- As some other commenters have noted, dealing with large container contexts can get hairy/slow. A devshell just tweaks a few environment variables, which is less of a tangle when working on the various projects (I use direnv, so my emacs session hooks into `flake.nix` and finds everything in-path automatically)
- While you could get a bit-for-bit identical dev environments by pushing a built container image to a registry that all devs pull from, I think most people would write a `Dockerfile` once and let folks build it locally before hopping in, which leaves a small (but extant) possibility that some environments may be subtly different (shifting container tags, ad-hoc apt-get commands, etc). A flake.nix coupled with a flake.lock means all devshells are lock-step identical.
This makes sense but also seems very annoying to do? E.g let's say you are storing state in the URL, and now the user wants to save it to their profile. You need to upgrade the state from "encoded into the URL" to "stored in my database", which seems annoying.
Simply put, it makes logs unreadable for humans without tooling. Things primarily touched by humans should be as friendly as possible to them. Prior to the advent of structured logging, every log message had a unique visual 'fingerprint' that the eyes and brain could grok at a glance, and spot anomalies really quickly. With structured logs, everything looks the same and so you can't use the brain's inbuilt abilities to process them.
And if you did want tooling to help, then typically the formats were regular and so you could use ordinary text processing tools to help. sed, awk, grep. With structured logging putting everything into nested balanced expressions, you need parsing. Parsing works until you run across something the parser can't figure out. Say you have some Go code with a JSON logger object you're passing around. What if you want to log something but your logging object isn't passed to that function. (you could pass it everywhere but that increases the arity of every single method by 1, and are also reinventing global state poorly) You're SOL, now you're stuck with fmt.Println() and you just broke jq. No, jq does not handle this failure mode. No, Golang does not let you just spit out arbitrary JSON. Thy must use the logging object.
The only thing it helps is ingestion into databases for heavy machine processing. Which is fine, but don't make it the only or even default way software tools spit out logs. In every other way, introducing parsing into your workflow just slows it all down. The only way I can see structured logging making anyone's job easier is if they never understood how it all worked before.
I have the same question! I understand parent's criticisms of context objections and logging boilerplate, but I'm not following the "fight against structured logging." What are the alternatives? No logging? Unstructured logging? Why would either of those be better than structured logs?
While I personally favor no logging, almost everyone who criticizes structured logging would prefer unstructured logging so they can make it someone else's job to restructure it (i.e. index and query it).
I was investigating doing a typescript compiler speedup.
I think the time might have finally arrived where we can use ML to generate a faster compiler in a language like Zig.
Probably not for all portions of the compiler. But I think with some reinforcement learning, it ( ... might ...) be possible to automatically generate a robust Typescript parser in Zig.
