> I like Max Bittker's framing that models are very good at counterfeiting and the level of expertise it takes to distinguish a counterfeit from the real thing has been increasing as models improve.
Is it just me or is this analogy completely missing the point of why we care about detecting counterfeits in the first place? Poor craftsmanship of all things is not really the reason counterfeiting is illegal!
> I have never encountered a program that couldn't have memory be explicitly tied to lexical scope, but it can result in less efficient use of it in some cases.
> Goose is honestly the most exciting language I've seen in quite some time.
I took a look at its home page [1] and I immediately see red flags:
- Over sixteen benchmarks Goose runs at 3.3x the speed of idiomatic C++, 1.16x hand-optimized C++ and 1.12x the best safe Rust, and uses 1.9x, 1.3x and 1.2x less memory (results). These gains come from Goose's data layouts and memory model.
- push returns a reference to the new element, so a program can link elements while building the array. A vector<T> or Vec<T> may reallocate and cannot provide this guarantee. Stable references account for several benchmark gains.
You're suggesting a performance loss (as expected), but they're claiming a (rather incredible) performance gain?
And they're claiming their vector stable and doesn't reallocate, yet without a performance loss, which makes no sense... it's not a vector anymore. And if you want a non-vector then you can do that in C++ too.
The whole LLM vibe doesn't help inspire confidence either, but even ignoring that, the technical claims themselves are incredible and bizarre, and I'm only a few paragraphs in.
It might be worthwhile to balance these positive claims against the language's own stated limitations [1].
Also, I took a closer look at the actual benchmark results [2]. For memory usage, at least, the median would show Goose using slightly more memory than the well optimized C++ and Rust. It looks like the mean is skewed in Goose's favor by a couple of benchmarks where it does extremely well due to its variable-length enums.
> You're suggesting a performance loss (as expected), but they're claiming a (rather incredible) performance gain?
I think part of the reason they’re getting higher performance is that they accept higher memory usage. Memory can be ‘freed’ later than in traditional languages, and the combined size of all stacks will be larger (maybe even much larger) than maximum memory usage.
The language likely also has limitations in that some constructs are hard or impossible to express (similar to how Rust has memory safety safer, but pays for it by having problems implemented doubly-linked lists)
That's great, but it doesn't explain anything I'm seeing. I'm just commenting on the (presentation of) the project. It's entirely possible they have something awesome that just isn't presented well, or that I'm just too dense to grasp the awesomeness of what's before me. Whatever it is, I'm just saying I can't make sense of what I'm being sold.
Goose is a weird language. It uses a pile of pre-allocated datastacks, enforces lexical lifetimes for all data, and has first-class syntactic support for capped, growable, and shrinkable arrays. It also spits out a pile of C that gets all the optimization benefits of <insert C compiler of choices>.
Goose in particular excites me because I have done similar design work over the years.
It can be a bit of a gamble (the sellers usually don't specify the exact SOC on the description) but given the price you're not taking that much of a risk.
Worst case scenario you end up with a backup 4G dongle.
Oh I see, that sounds like a gamble. Another question if you don't mind - were you worried about security at all? Like what if there's something vulnerable (or worse, backdoored) in there?
It's runs a mainline Linux kernel so it's possible to compile everything from source without any issues of you want to be absolutely sure. I haven't done so but I did asked Claude to check for anything suspicious and it did not find anything.
I guess a big advantage of constrained hardware with a minimal surface is that there's not that many places to hide something.
Obviously I would not recommend running this if you're in charge of Cybersecurity for Fort Knox but for a Homelab the risk seems manageable.
I have about 300 that I need to sell and I have some software that can run a “factory” to flash and restore your Linux distribution while preserving the IMEI.
They are all the same board variant on which the SIM works and have the msm8916 chip.
They are not part of any existing writing scheme. I think they could be a different standard like ":+1:" and ":chainsaw:" but it makes no sense for them to be built into text rendering.
> They are not part of any existing writing scheme
They are today, and there is now orders of magnitude more writing that uses emoji than the entire corpus of many of the scripts covered by Unicode.
Language and writing have always been continuously evolving and that process didn’t magically stop when the Internet was invented. The first emoji preceded their inclusion in Unicode, humans used them in writing, therefore they belong in Unicode.
Correction: Unicode emojis are, because they got added to Unicode.
>Language and writing have always been continuously evolving and that process didn’t magically stop when the Internet was invented.
Okay but why should Unicode be a part of it, and a judge on what to include? That sounds like linguistic prescriptivism, while the original role of Unicode was descriptive and the evolution was happening outside of it. Emojis before Unicode were perfectly fine as composites that weren't mandated by committee.
> Okay but why should Unicode be a part of it, and a judge on what to include?
How could it be otherwise? These debates have been a part of Unicode since the beginning, such as which Chinese characters to unify, which ancient scripts to include, which attested glyphs get their own code points etc.
That’s simply what it means to be a standard: Decisions need to be made, and not everyone will agree with all of them.
Ancient glyphs and Chinese characters existed before Unicode, the committee didn't conjure a new form of language out of thin air. The decisions with Chinese writing were necessary due to practicality (there are various composable encodings, including IDC in the Unicode itself, but they're not very practical for a general-purpose text processing encoding).
Unicode emojis did not exist before Unicode, the existing composite emojis/kaomojis/etc were already perfectly expressible in existing symbols, and were nothing like Unicode emojis. This was a huge distraction from their mission, and definitely not inevitable.
Today's emotes became customized, and it's impossible to express them in any encoding. They diverged too much from writing to be called writing, it's a volatile signaling system at best. You can literally make an AI generation or upload your picture, how do you even encode or standardize that? But because of their blunder Unicode got stuck with its role of a judge and censor of a new entirely synthetic language it created, which wasn't the original purpose of the consortium.
It’s for many, many things besides letters, and was designed to be so from the beginning. Pictograms of various types have always been in Unicode, and even in many predecessor codesets.
Unicode is for text symbols, some of which represent one word (e.g. &, U+2116) and some of which represent multiple words (e.g. U+FDFD). Other non-letter characters include numbers, punctuation, and so on.
Can not speak for the original poster, but I tend to agree in that it greatly limits the speed of creativity due to the integration process, creates a very subjective bureaucratic process for inclusion, and that frankly emoji are not a script (yes yes, you can make an argument that they are akin to ideograms, but this analogy breaks down rather quickly). Thus, I think a different technological solution could have been warranted. The story I keep hearing is that it was necessary to get the Japanese telephone companies on board with Unicode rather than their own emoji hacks combined with local Japanese encodings, which I can sympathise with as a necessary (but unfortunate) evil. A word of caution though that I find text with heavy use of emoji largely unreadable as my eyes fixates on the emoji rather than following the text; thus I am likely biased (but possibly still correct).
All things aside though, Han unification [1] remains the worst part of Unicode to me as it makes it impossible to know whether the glyph I am seeing is the one intended by whoever wrote the text (Chinese names in e-mails for example is an utter mess for someone like me that has to have their system set up to mostly handle English and Japanese). The whole Han unification mess more or less necessitates markup and sometimes even the insertions of raster image glyphs for historical and regional texts which is just bloody daft. Yes, Unicode language markers do exist and can resolve this in part. But, they are invisible to the end user, can disappear while copying and pasting, and you have to rely on the original author even putting them there in the first place! Whenever someone struggles to see the issue, I usually propose that we unify the common subsets of the Cyrillic, Greek, Latin, and Mathematical glyphs which usually finally drives home the point.
> I usually propose that we unify the common subsets of the Cyrillic, Greek, Latin, and Mathematical glyphs which usually finally drives home the point.
That would be an awesome compact encoding scheme (and also help with the next 4million emojis)! And given the relatively higher importance of those CyrGrLat, it would force wider proper support that would resolve the issues you raised, which are all app-dependent
> But, they are invisible to the end user
Apps make them visible, some even do that for whitespace chars to highlight the difference
> can disappear while copying and pasting
broken clipboards can be fixed? They somehow manage to retain rich text formatting, surely they cna retain language markers?
> you have to rely on the original author even putting them there in the first place!
Nope, the author's input app can handle that just like the original author doesn't need invisible joiners to use composed emojis
I think that Unicode should have been limited to only depicting existing writing systems. Anything else is imo out of scope for a text encoding format.
So what about ASCII control codes? They are non-printable characters that are part of Unicode, grandfathered in, yet aren’t part of any writing systems.
And home computers have had pictograms as part of their character set since the late 70s/early 80s. For example code page 437 (MS-DOS) had smilies, card suites, and other emoji. Likewise for the PETSCII (Commodore Pet) too.
And not just emoji’s, but full on drawing characters. In fact that was the only way to draw graphics on some early systems, such as Teletext, in the early 70s.
And then you have the question of what pictograms are part of writing systems. For example the media control symbols (play, pause, fast forward, etc). Or how about the fact that some emojis had been part of written text long before Unicode, in the form of “smilies”, eg :-)
I hope this illustrates that the problem was never an easy one to define boundaries for inclusion.
What exactly do you mean by sending that $30k at your own risk? Like are you suggesting if you sent it to the wrong entity (say they turned out to be a scammer) and the bank shrugged, you'd be fine with it because you took the risk? If yes, do you think most people would? I feel like most people expect more safeguards and recourse when the transaction amount is higher, not less.
The search model is not the same model, and it's quite obviously worse when you use it, so that's not quite a reason I would personally find the hostility excessive.
If by "hopefully they were awesome already" you mean "hopefully deserved gaining widespread traction in the first 6h", then absolutely no. Try the analogy with something physical (like an airplane) to see how ridiculous it sounds. No passenger should've gotten on $the_absolute_most_awesome_vehicle until it had passed the stress and crash tests, been certified, etc.
On the contrary - this is explicitly the mission of most military organizations. There are countries in the world today where every day their bridges and buildings face adversarial attacks from state level threat actors.
The difference is, people who build civilian bridges and buildings are not actually generally expected to build structures that can withstand such attacks because preventing those attacks is considered the government’s job.
So no, they typically don’t undergo ‘more rigorous testing’ than software against security threats. The fact that governments make no effort to protect networked systems from being attacked places the burden of withstanding those attacks fully on the private civilian operators.
Is it just me or is this analogy completely missing the point of why we care about detecting counterfeits in the first place? Poor craftsmanship of all things is not really the reason counterfeiting is illegal!
reply