afiori

In a sense I would expect C to be the most portable language ever* so I am not sure how good of a comparison candidate it is

* With some UB herbs and spices

that is even worse

no, it is the same idea, even if the excavator was magically free there are associated costs like keeping an industrial machine in your garden, danger or heavy machinery and possibly it is going to destroy you garden.

the analogy is not between each specific consequence/cost, it is relative to "single axis optimization" not being a solid strategy

Because that CSS can be evaluated with lower latency than the equivalent js

unsafe rust is still typed orders of magnitude better than C

Yep cost is the reason, allegedly the ts team found go a better language for a port and both using a less ergonomic language and switching target every six months have associated costs

Here the list is the "flattened” ast of (Node, slice of input corresponding to the node)

Pushing for shorter keys can be reasonable, otherwise we would all use 16 MB keys

this only warn that there is some implementation-defined stuff coming next, not that all these operator are free of undefined behaviour

Not everyone needs to care about everything and there is reason to say that a result like this one from openai is quite sterile and possibly damaging to the socio-cultural dynamic of the field.

I never did a blind test but I feel i get much improved writing for work stuff with instructions to use ASDSTE-100

I feel like solid-js is in a good place to be a platform

loadshedding is based on each load having an associated priority

I don't think that standards did anything wrong or incompetent, but with hindsight considering all the complexities they bring i am hot sure they have been worth it

If you are referring to how SSR pages need to download the serialised page "props" and not just the html+js then good news! Solid 2.0 is about to solve this.

If you are referring to having to download react itself then you have to download the WebComponents code too.

Actually with smart use of forms and links you could make a js free react page (using forms to submit state changes) more easily than for WebComponents

WebComponents are some of the coolest APIs on the web if you ignore all the ways they fall short and make everything else harder

This comment is at the same depth of analysis of saying that the only reason for python being successful is that universities started teaching it and then people no longer could do C++

The reason react sites are bloated is because there are a lot of things that are easy to do once you have better DX, there is nothing stopping you from making completely static sites with no js (solid-js 2.0 has a whole "htmx-like" mode that lets you have good interactivity even with js disabled).

WebComponents are useful for cases where you want something slightly more integrated than an iframe or want to make a library of small widgets

WebComponents were created out of spite for react and are the composability equivalent of medieval artist drawing horses that look like they had never seen an horse

I don't why a sha256 project could not support sha1 usages too: if you try to merge/rebase/cherrypick/whatever a sha1 commit in a sha256 project git could simply recompute the needed s256 data and keep old sha1 ids as validated metadata. you could even use either hashes as tree-like refs.

you could even do the same in reverse and "import" sha256 commits in sha1 projects. the only real difference would be which one is used as primary key in git's internal store.

The only alternatives to nuclear are coal and LNG

Or starting with solar more 20 years ago.

I think it is so that the server extensions can do stuff on the client, imo the weirder part is that it installs a bunch of stuff on the remote

> If you treat a branch as your unit of review, then it becomes super difficult for someone to submit a chain of related changes. You'll be constantly rebasing your pull requests onto each other as you get feedback from dependent branches.

> A rebase can introduce change to a commit in cases such as handling conflicts or squashing.

and with change ids you can quickly separate commits that changed from commit that did not.

> Also, a commit already retains it's commit message after rebasing.

but commit message are not ids, there is no command for checking out a commit by its message, nor any sense that commit with the same message are somehow functionally related

change ids are more analogous to commit messages than branches, eg suppose that in a feature branch you have a "Delete deprecated classes" commit; in git there is a clear idea of "cloning" this commit (eg rebase, cherrypicks, maybe reverts) and the common sense that the new commit inherits the same commit message. Change ids are the same thing but in hex id form that can be created for every new commit/stash/index.

They allow for example to identify all the clones of a commit and they allow to give stable identities across rebases eg suppose you rebase a typo at the beginning of a feature branch without change ids a reviewer sees n new unrelated commits while with change ids it is possible to clearly identify which commits where changed/added/removed since the previous review iteration.

IMO one of the main insight in the maxim is the importance to have the form communicate the function to the user.

my point is that that a lot of people shit on js for having "weird crazy stuff in it" and then the example is 0.1 + 0.1 + 0.1 !== 0.3 or NaN != NaN which has nothing to do with js semantics

JS is weird, and not having a stronger separation between ints and floats makes NaNs more common than in other languages (eg parseInt would not return NaNs in C or python) but for many "weird" examples people are making fun of normal stuff.

NaN means only NaN, 0/0 is NaN at the cpu level.

to my weak undestanding only pow and hypot behave like this; pow for math reasons and i could guess that hypot does that to sorta have |x| <= hypot(x,y)

yes, source release on day one, proprietary license valid forever, free license becomes valid after X time and users need to only satisfy one of them.

Many projects already do this; proprietary source does not mean closed source, it can simply be freely available but with no copyright concessions

> But using locks is bad for performance and latency and thus UX. yeah but this way you have only one lock, with free threads or preemptive multitasking you have to have them sprinkled into every data structure each with its potential for deadlock and livelocks.

Also look at single core focused systems like spacetimedb, sometimes if a workload is not embarrassingly parallelizable multithreading can make things slower.

JS needs some way to more easily push things off the main render thread, but i think that there is no easy solution for it. (maybe a model like iirc clojure had where "threads" would automatically rollback and retry in case a data race was detected could work to handle off-threads tasks in js, but it is a quite far off solution)