You still get that by using the same Rust frontend and using GCC instead of LLVM as the backend. A parallel reimplemented from scratch front end at best lets you find under-specified aspects of the current implementation. Not sure it actually helps the ecosystem though.
Discovery and improvement of "under-specified aspects of the current implementation" can have a large practical impact, and implementing a standard (the Rust language) more than once so that it ceases to have a dominant "current implementation" (rustc) is even more important.
That’s me being very very generous and just restating the supposed goal of this effort since rust_codegen_gcc provides a much better solution to the “I want to be able to hit all the gcc targets”.
I’m not actually convinced that a new fronted actually helps as much for that effort especially when weighed against the very real downsides we see in c and c++. I have a strong suspicion that addressing under specified parts of the current implementation can be done more cheaply and effectively using other mechanisms.
Indeed, I don’t see the typescript community really complaining that there isn’t another implementation of typescript. And cpython remains the de facto Python implementation with other distributions seeing less adoption due to network effects and I don’t really see cpython benefiting from the existence of the other frontends.
> Indeed, I don’t see the typescript community really complaining that there isn’t another implementation of typescript.
There are actually numerous third-party implementations that can take TypeScript code and compile it to JavaScript. Babel can do it in pure JS/TS, SWC can do it in Rust, and ESBuild can do it in Golang.
The catch is that AFAIK none of these implementations enforce the actual type checks. This is usually called "type stripping" within the JavaScript community, but it's basically equivalent to the "Rust without the borrow checker" implementation that gccrs is working on.
Well, except that the Rust community is extremely ideologically opposed to "Rust compiler without the borrow checker" existing as a viable product, so you end up with the situation described in the article where that implementation is just used to compile a hybrid compiler with all the hard-to-implement type-checker stuff copied verbatim from rustc. That erases most of the spec-robustness benefits of doing a full third-party implementation, but there are still some practical benefits, like being able to bootstrap the compiler more easily.
And who knows -- if you hack the build to re-disable the borrow checker, the resulting compiler might run faster. (That's the main benefit of the third-party TypeScript implementations in practice.)
Typescript was written very intentionally to be really easy to transpile to JS which is why you see so many solutions. The type checking piece remains not reimplemented despite high profile third party attempts to rewrite it in a faster language. The type checking piece is exactly the thing that makes typescript typescript. And the reason the external frontend attempt failed is that it can’t keep up with mainline development which is also true for CPython and its offshoots. In fact, TS is so easy to strip that the syntax is being standardized within official ecmascript so that any type checking annotations could be layered into JS code and engines would natively strip without needing transpolation in the first place.
As for “rust without the borrow checker” it’s very much not the same thing as Typescript transpilation for many reasons among which are that there are many other language rules would still have to be enforced. It’s akin to making a TS type checker that didn’t validate 1 of the language rules but enforced the others.
I’m not opposed to a compilation mode that didn’t enforce the borrow checker but repeated tests of compiling various software packages reveal that the borrow checker is within the noise performance wise. So you’d need a more compelling reason than “maybe it runs faster”.
> repeated tests of compiling various software packages reveal that the borrow checker is within the noise performance wise.
Out of curiosity, do you have a source for this? The stuff I remember reading on the topic is from back in 2018 where they managed to get the NLL borrow checker to be not much slower than the old borrow checker (https://blog.mozilla.org/nnethercote/2018/11/06/how-to-speed...) -- but that took a concerted effort, and the borrow checker was overall a large enough contributor to compilation time that it was worth spending a bunch of effort optimizing it.
I think "sick time" or "sick days" is a very US-centric thing. In good chunks of the EU, medical leaves (approved by a doctor) are a legally protected concept.
I wish people who linked to Wikipedia articles would leave a comment saying what they particularly liked about it and why they thought others would find it interesting.
> You want a place that allows all speech, but is moderated?
Freedom of speech != "all speech".
A platform with heavy moderation is required to actually enable the highest degree of freedom when it comes to speech, otherwise you allow people to impede others freedom for speech.
We make correlations based on experience of reality. They make correlations based on experience of text. Text is only meaningful when it is correlated with reality.
An LLM will see that "Dog" and "Woof" occur near each other in text a lot, but it doesn't know what a dog is or what a woof is. You do know that, because you have experienced an actual dog and heard it go woof.
But there's also plenty of things I haven't seen in real life and have only read about in books or text. Does it mean that I wouldn't know what they are as well?
In addition you can feed LLMs image, audio input as well, and in theory you could feed any sensory data that we get.
In fact it can describe what is on an image, to quite a lot of detail.
Is knowing what a dog is being able to recognize it on an image, and is knowing what a woof is being able to recognize it in an audio?
Ultimately, after all, all of it can be represented as input tokens, binary data or otherwise. We also receive constant input from the World, which could be represented in any various different forms and processing layers can transform it into different helpful symbolic things to problem solve based on that. LLMs in order to be able to logically consider what a dog might do given certain situations, would have needed to build some form of neural representation of the idea to be able to produce the output it can, that goes beyond parroting the training data in my view. I can give it an input in some interesting configurations and permutations and it's able to logically use the concepts to figure out what might happen.
"Does it mean that I wouldn't know what they are as well?"
Are they explained in terms of things that you have seen in real life? Or in ways that build on that? Then you can certainly gain that by building on those models.
And yes, if you can feed an attention-based neural network (not an LLM, those are specifically Language-based) sense data (and preferably action data too, for how it interacts with the world) then that would give it a picture of the world. And once it can recognise a dog then you can say "And we call this a dog!".
These “vision-language-action models” (VLAMs) take in text and images, plus data relating to the robot’s presence in the physical world, including the readings on internal sensors, the degree of rotation of different joints and the positions of actuators (such as grippers, or the fingers of a robot’s hands). The resulting models can then answer questions about a scene, such as “can you see an apple?” But they can also predict how a robot arm needs to move to pick that apple up, as well as how this will affect what the world looks like."
Grounding the model’s perception in the real world in this way greatly reduces hallucinations (the tendency for AI models to make things up and get things wrong).
And connect the dots in such a way to develop this interesting scenario and at the same time consider so many different interactions between the room and the animals.
Because it knows which text is associated with which other text, in quite complex and subtle ways. It's exceptionally good at analysing text without needing to understand anything more than which words are seen in proximity to which other words, and how their placement in relation to each other affects other bits of text.
It is amazing how well this technique works. But at no point has it linked the word "cat" to real actual cats, because it has literally got no access to any real actual cats. It has had no access to any information beyond the word "cat" and its relationship to other words.
You are calling it text associated with other text.
But I think it has to have internalized it in a much more complex way to be able to produce output like that to any arbitrary configuration of different things.
This internalization and ability to apply that internalization to produce scenarios like that tells me it must have enough understanding, even if it hasn't been able to "see" a cat, it has an understanding of its characteristics and description, and how the same thing can interact with other things. To me that's understanding of the object.
Alternatively, if we are talking about a blind and deaf person, and that blind person hasn't ever seen any cats, would they be unable to understand what a cat ultimately is?
If all their input is in braille and tactile sign language?
"it has an understanding of its characteristics and description"
It has no access to the characteristics. It literally only has access to text. It knows that some text is associated with the word "cat", but it doesn't know what "fluffy" means, because it has never seen fluff. There is literally an infinite regress of meaning, where you never get out of language to actual meaning, unless you have some kind of experience of "fluff" (or something else which can be related to "fluff").
A is a bit like B which is a bit like C, which is like D, which is a mix of B and E, which is quite F-like. This never gets you to meaning, because the meaning is the sensation, or the experience. And it doesn't have that.
(Blind people would be able to understand the physicallity of a cat, because they can still experience them in a variety of ways. Whether they can understand that the cat is white is down to the kind of blindness, but if they've never seen colour then probably not.)
And for us humans, the way I understand fluffiness, is about
the sight and the touch senses. We have associated this sight input and this touch input with the label “fluffiness”. Now we throughout our life have experienced this input a lot, but technically this input in its original form is just lightwaves and a combination of our nerves physically touching the fluffy object. This could in theory be represented in many data formats, it could be represented as a combination or group of input tokens. So the understanding for us is just the association of this input to this label. I don’t see how this in particular would give us any special understanding over if just raw input was given to an LLM. It’s just a special case where we have had this input many times over and over. It seems arbitrary whether LLM has been fed this data in this format or in some other format, e.g. text as opposed to lightwaves or touch feedback.
This extra input could make those models more intelligent because it could help it uncover hidden patterns, but it doesn’t seem like it would be the difference between understanding and not understanding.
Text is just a meaningful compression of this sensory input data.
You need to lift a ton by a meter to store the same energy as an AA battery. This scales badly unless your ton is made of water and so can be easily pumped up a hill.
>This scales badly unless your ton is made of water and so can be easily pumped up a hill.
Or your Ton can sink into a body of Water/Mine/Mountain, pumping Water up a hill is a bit less effective (friction in pipes) if you have Water (however still more effective then loading a AA battery). And Pumping water uphill is a Gravity Battery too (PSH).
>>EnergyVault is designing a LWS system using a tower built from 32-ton concrete blocks, stacked with 120-meter cranes. One commercial unit is expected to store 20 MWh of energy, or enough to power 2,000 Swiss homes a day.
You only have that control because of the government. Without the chunk of the legal system devoted to it you wouldn't have any control of your own creation at all.
If I take your physical thing away you are left without that thing.
If I copy your thing you still have your thing.
While property ownership and restrictions on being able to say or write something are both constructs governments apply, they are very different principals
Ultimately they rely on same principle: this is mine. I made this, it's product of my work. It's mine to do as I please.
Government made laws to put this into practice.
Edit: Ultimately, to say you don't protect IP in some reasonable form is to say only work that produces physical stuff has value and is worth protecting. That all thinking is not a work worth protecting.
It's not like there weren't systems trying to make a different concept of material ownership. Communal ownership mean the thing is never yours in the first place. You never owned and thus it was never taken away. It mostly didn't work.
reply