A really great place to reach for this is Elixir/Phoenix now that the set theoretic type system is in place with LiveView. I have been doing some pretty large/complex codebases gradually working towards fully integrating working this way for the past 5 years and it has been great.
The general challenge becomes integrating the fractional front-end code written in your backend-language that compiles to JS with the rest of the JS ecosystem.
JaneStreet have a love of writing their own stuff from scratch so it doesn't apply to them but it might to you.
Hence most people end up with frontend-as-backend rather than backend-as-frontend.
> Is there some limitation that WASM has that JS doesn't?
You need a JS trampoline to call your WASM and make browser primitives available to it, and IIRC calls into browser code incur some extra overhead, but those are pretty manageable.
Additionally: for high level languages, source code is _much_ smaller than compiled binaries. If your initial needs are simple, your users are likely downloading more than 10x as much code.
WASM does not (yet) have access to the DOM or web APIs, meaning every direct interaction with the browser must first go through JS interop anyways, with a resulting performance penalty. There are proposals, and maybe we'll see it happen by 2035, but as of now WASM is best suited for heavier workloads where the edge in application performance outweighs the cost of JS interop with the browser rather than being a universal solution.
I’d be very surprised if any long time contributor to gcc would want to start pushing AI generated code. But even if that is the case, this is one of the largest and most complex pieces of software on the planet, and is used to produce the binaries of countless other pieces of software. I think this policy makes sense because of that. We want to make sure no inadvertent behavior is introduced (whatever that might be, from bugs to ~puts conspiracy theory hat on~ some kind of backdoor undetectable by humans inserted into every compiled binary allowing the authoring AI system (or the government behind it) remote access to every machine it runs on). Okay maybe that’s a little crazy
As a non-GCC compiler developer myself, there's a spectrum of AI use and the words "AI generated code" can mean different things to different people. At the extreme ends, nobody I know well objects to AI auto-completion in your editor, but neither does anybody want to let AI open pull requests autonomously.
Having a coding agent iterate on a well-defined narrow task in the background while I'm in a meeting or working on something else, and then doing a thorough, thoughtful, and active local code review (meaning, having an editor and the diff open side-by-side and liberally making edits to clean up the code) before pushing anything out for others to see feels like a reasonable point in the space right now. Nothing is perfect, but this style of active code review removes basically all AI smells in practice. The edit-build-test loop is fairly long (i.e., longer than a few seconds), so having AI babysit this loop for the initial development of a task is helpful.
> I know well objects to AI auto-completion in your editor, but neither does anybody want to let AI open pull requests autonomously.
I think it’s more about turning language models into your smart intern, rather than letting them do all your work or become your moronic boss.
In any case, I do think there could be room for AI in the future—for instance, in academic research. I recently saw a news story about an AI that managed to detect certain types of cancer based on a specific blood test; I consider that a justifiable use of AI. However, using it to autonomously send PRs? That strikes me as going too far.
> But even if that is the case, this is one of the largest and most complex pieces of software on the planet, and is used to produce the binaries of countless other pieces of software. I think this policy makes sense because of that. We want to make sure no inadvertent behavior is introduced
That would be an excellent reason to limit AI contributions if true. I am not in a position to judge the requirements of a compiler project so I do not have an opinion on whether that is a sound reason or not.
However, the reasons being given for the change (and the wording around "legally significant") seem to be about copyright law which I do not think is sound reasoning (see my other comments on this).
> ~puts conspiracy theory hat on~ some kind of backdoor undetectable by humans inserted into every compiled binary allowing the authoring AI system (or the government behind it) remote access to every machine it runs on). Okay maybe that’s a little crazy
Someone using AI code to introduce a back door will surely be willing to lie and say its human written so this policy will not help.
> However, compared to more specialized approaches for representation learning they produce less disentangled representations, which puts a ceiling on their usefulness for tasks that require world understanding.
Only an LLM would use a less disentangled representation of the concept “more entangled” when trying to explain to people in the real world why less disentangled representations are not as useful for modeling the real world.
We’re just pulling signs of LLM touched writing out of our ass now. Might be time to move on from the accusations, assume all writing is at least LLM assisted and judge it purely on the quality.
Bad news, humans write silly things all the time. If anything, LLMs are less likely to make awkward phrasings than people, because they aren’t found in the training data very often.
It also depends on what you consider to be “criminal.” I’d wager most shoplifters are dumb. Most supervisors who engage in wage theft aren’t dumb. But that’s not the kind of person who comes to mind when we think “criminal.”
Even if this was simpler and better than markdown, I’d purposefully avoid using it because I hate the name so much. A good rule of thumb I just though of: Do not introduce seafood into your branding if you are not a seafood vendor.
The HTTP standard does not define a body for GET requests. Therefore, proxy implementations will typically only copy the data from the request header when sending it off to its next destination. They don’t technically “delete” anything. This saves compute (and possibly bandwidth, if the request happened to have a body, although the whole point is that one can safely assume a GET request does not have a body per the standard).
Finally! I was waiting for this to become possible!
reply