Clicking a button that says "I register" or "I want to pay for a parking ticket", feels so bizarre to me. It's like the website telling you what to click. Like it's holding your hand.
I don't usually get mad at petty stuff like this, but this one just pisses me off somehow.
To give a concrete example, you said that javascript does not have a definition of a "package" in its langauge. But what does that really mean, and why should it lead to package manager managers? Because for me, a person who has worked with javascript just a little bit, I know package.json exists and most of the package managers I've worked with agree on what the contents of this file mean. If we limit our understanding to just npm, yarn and probably bun, we don't see how that causes or contributes to the dependency hell problem (sure it exists, but how?).
You said that Go mitigates the issue of dependency hell to some degree, but this is an interesting thought, give it more exploration! Why should something like Go not have this problem not be not as severe as in Javascript?
I may not remember the details of what you said in the article and I would like to check, but currently I can't access the site because it times-out for me.
Once I complained about this to the community someone suggested a clever gitignore hack:
*
!*/
!*.*
This by default ignores all files, except those that have a suffix and directories. I think this is a useful lesson - if you flip which files you ignore you can change the failure mode from "I accidentally committed a huge file into a repo" to "why isn't it working?". The latter can be pretty much be answered by good CI testing (maybe not always though).I programmed in C for over 30 years and was a member of the C Standards Committee, which originated the language about undefined behavior ... I know what I'm talking about.
> To point out that use after free is possible in Odin is not really a gotcha unless you really are just arguing semantics. That's by design, just like use after free is possible in C or C++ or Rust too.
This completely misses the point and is a failure to understand at every level. Being able to use memory after being freed is not by design -- no one intends it, no one wants it. It's undefined behavior, and a program that does it is buggy. The reason that it's possible is because it's so hard to detect or prevent. To do so requires escape analysis, lifetime declarations, borrow checking, etc. etc. And no, use after free is not possible in Rust--not in safe code. It's hard to respond to that statement without being rude, so I will say no more.
Because as far as I know both undefined behavior and unspecified behavior are the behaviors that aren't specified in the language standard nor the implementation. So what's the difference?
select *
from (
delete
from users
returning id
)