Given that most string implementations have both a `len` and `cap` field (or eve just `len`), means that for every string data type, there is one more integer variables being used.
So integer definitely gets used more than strings, and I'd argue way more than floats in most programs.
In CPython, a string's length is stored internally as a machine integer (`Py_ssize_t`); when the `len` builtin is called, the corresponding integer object is created (or more likely, retrieved from cache) on the fly.
Ints probably get a big boost in languages where the only built-in for-loop syntax involves incrementing an index variable, like C. And, speaking of C, specifically, even the non-int types are actually ints or isomorphic to ints: enums, bools, char, pointers, arrays (which are just pointers if you squint), etc...
But, otherwise, I'd agree that strings probably win, globally.
Actually because of provenance the C pointers are their only type which isn't just basically the machine integers again.
A char is just a machine integer with implementation specified signedness (crazy), bools are just machine integers which aren't supposed to have values other than 0 or 1, and the floating point types are just integers reinterpreted as binary fractions in a strange way.
Addresses are just machine integers of course, but pointers have provenance which means that it matters why you have the pointer, whereas for the machine integers their value is entirely determined by the bits making them up.
It's been a long time since I've done C/C++, but I'm not sure what you're saying with regard to provenance. I was pretty sure that you were able to cast an arbitrary integer value into a pointer, and it really didn't have to "come from" anywhere. So, all I'm saying is that, under-the-hood, a C pointer really is just an integer. Saying that a pointer means something beyond the bits that make up the value is no more relevant than saying a bool means something other than its integer value, which is also true.
That's defect report #260 against the C language. One option for WG14 was to say "Oops, yeah, that should work in our language" and then modern C compilers have to be modified and many C programs are significantly slower. This gets the world you (and you're far from alone among C programmers) thought you lived in, though probably your C programs are slower than you expected now 'cos your "pointers" are now just address integers and you've never thought about the full consequences.
But they didn't, instead they wrote "They may also treat pointers based on different origins as distinct even though they are bitwise identical" because by then that is in fact how C compilers work. That's them saying pointers have provenance, though they do not describe (and neither does their ISO document) how that works.
There is currently a TR (I think, maybe wrong letters) which explains PNVI-ae-udi, Provenance Not Via Integers, Addresses Exposed, User Disambiguates which is the current preferred model for how this could possibly work. Compilers don't implement that properly either, but they could in principle so that's why it is seen as a reasonable goal for the C language. That TR is not part of the ISO standard but in principle one day it could be. Until then, provenance is just a vague shrug in C. What you said is wrong, and er... yeah that is awkward for everybody.
Rust does specify how this works. But the bad news (I guess?) for you is that it too says that provenance is a thing, so you cannot just go around claiming the address you dredged up from who knows where is a valid pointer, it ain't. Or rather, in Rust you can write out explicitly that you do want to do this, but the specification is clear that you get a pointer but not necessarily a valid pointer even if you expected otherwise.
it is kind of fun to me that most C programmers believe that ISO C exists/is implemented anywhere, when in reality we have a bunch of compilers that claim to compile iso C, but just have a lot of random basically unfixable behavior.
I do believe the C standards committee got it completely backwards with regards to undefined behaviour optimisations. By default the language should act in a way that a human can reason about, in particular it should not be more complicated than assembly. Then, they can add some mechanism for decorating select hot program blocks as amenable to certain optimisations[1]. In the majority of the program the optimisation of not writing a single machine word to memory before calling memcmp is not measurable. The saddest part is that other languages like Rust and Zig have picked all this up like cargo cult language design. Writing code is already complicated enough without having to watch out for pitfalls added so the compiler can achieve one nanosecond faster time on SPECint.
[1] As an aside, the last time I tried to talk to a committee representative about undefined behaviour optimisation pitfalls, I was told that the standard does not prescribe optimisations. Which was quite puzzling, because it obviously prescribes compiler behaviour with the express goal of allowing certain optimisations. If I took that statement at face value, it would follow that undefined behaviour is not there for optimisation's sake, but rather as a fun feature to make programming more interesting...
A pointer derived from one allocation and a pointer from another allocation does not need to compare the same, even if the address is. And you will likely invoke UB. This is because C tries to be portable and also support segmented storage.
A pointer derived from only an integer was supposed to alias any allocation, but good luck discussing this with your optimizing C compiler.
I have never written a program where you truly need floating point numbers. They are basically only useful for storing unprocessed real world data. I only ever use them for function calls to libm functions and immediately cast back to an integer. It think floats are overused.
They wouldn't have time to hear it because they'd be trying to fix their local dev environment.
I worked for a company that had done pretty much that - not fun at all (for extra fun half the microservices where in a language only half the dev team had even passing familiarity with).
You need someone in charge with "taste" enough to not allow that to happen or it can happen.
Probably =), or Conway's law was always about the lower ends of the communication nodes in a company graph. I think it's time we also always include the upper ends of our cognitive limits of multitasking when we design systems in relation to organization structures.
Community is also about communication. In fact, that's a primary aspect of a community.
Yeah, Mozilla introduced a bot that's stomping on things. Are they malicious? Twirling neatly waxed mustaches as they cackle gleefully as the little ants scurry about in a panic?
Or is this a case of humans doing what humans do: Screwing things up.
The first step is to open communications, and the most effective form of communication is face-to-face (the way we've evolved to do it).
Getting to the bottom of the issue in 1-1 communication with a representative of the community should be the common approach when complex problems arise, because then you can be sure that you're on the same wavelength before you do your mass communication with the rest of the community. Saves a TON of time and heartache and ill feelings.
Community is all about open communication, and cultivating it through active participation. There is no need to take further first steps here, as support.mozilla.org is the open platform that community agreed upon. For face-to-face communications there seems to be All Hands meetings, as mentioned by Michele.
This communication in particular is about how one member is sharing their "discomfort" of the non-communicated automation efforts done by Mozilla, and is also expressing their resulting action - leaving that community.
Please don't conflate the efforts of institutions (Mozilla) with the ones of communities (SUMO). Transparency is a big factor that marks their difference. So yes, community is also about communication.
As an unpaid volunteer to a multimillion dollar corporation that has just erased a huge collective volunteer effort, listing in writing the reasons I'm unhappy is already way too much effort.
Asking that same volunteer to hop on a video call is just insensitive. They're the one providing free work; if you care about solving the problem and not losing the volunteer force, you should go where they are (the forums) instead of asking them to come to you (video call). They probably don't want to take time out of their schedule to waste their time talking with a community rep. And they probably don't even want to do a voice/video call.
> Yeah, Mozilla introduced a bot that's stomping on things. Are they malicious? Twirling neatly waxed mustaches as they cackle gleefully as the little ants scurry about in a panic?
> Or is this a case of humans doing what humans do: Screwing things up.
Whatever else they might be, they're clearly out of touch. You'd have to be living under a rock to not realize that AI is controversial - especially in the more OSS/FSF parts of the internet - and rolling it out like a bulldozer is going to create outrage.
If they're just screwing things up, they're not learning from their mistakes. They already introduced the bot to the Spanish and Italian communities, with the same issues. To the roll it out further to the Japanese, and who knows who else, without fixing the issues is not speaking to their competence.
But if they had rolled-back the 2 languages and paused on the third, thr team behind this will have little to show during end of year reviews. So onwards the wheels turn, to show a large and growing rollout supporting millions of users across Europe and Asia in 2025
Yeah exactly. I understand you may feel that I bulldozed your house, but it was an honest mistake. I deployed an AI bulldozer. Some communities are very happy with the results. Others may need time to adjust. Look, I want to talk. First and foremost this is about communication.
As soon as you get Wi-Fi back up, let's hop on a call.
Except it’s not a screw up, is it? I’m not saying it’s malicious, and I feel your caricature of “twirling mustaches” is useless and detracts from the point.
It’s not a “screw up”. It’s also not malicious per se. It’s insensitive and shows a lack of care for the community. They deliberately turned on a bot that would overwrite work done by people, and make these people work with diffs and proofreading, without them having a say in it. In production!
It’s not like they can’t test it. Or involve everyone. There are locale leaders, as the Italian person alluded to.
This is shitting on community, and then going “sorry not sorry”, because they’re not rolling it back and they’re saying “I’m sorry you got your feelings hurt, wanna talk”?
This CAN be sorted out. And I believe it will. But it WAS insensitive and it WAS a case of not caring for the people who put their time and effort in voluntary work that benefits you. It’s really bad, no matter the intentions.
"Are they malicious? Twirling neatly waxed mustaches as they cackle gleefully as the little ants scurry about in a panic?"
Where are you getting this from, specifically? The claim I can see is that Mozilla didn't care enough to check first. So this looks as if it might be a straw-man argument. I think those are specifically prohibited in the FAQ.
>but where is this reductionism-to-rationalize-trend coming from lately?
It's always been in the community. I think this decade really showed that these weren't just stellmans to understand perspectives, but die hard conservatives (in the literal sense of the word) who want to maintain decorum over anything else. No matter the situation. Google can announce a hostile takeover of a government tomorrow and such folk will react "well let them talk it out. Google is a big company after all".
Non-native here. People "hop on a call" to have a personal guide that helps in stepping through tasks of a proposed solution. Such a call is made to remove ambiguity and provide immediate feedback, to apply the solution as seamless as possible. Used in the context here (without a proposed solution) it just screams "let's avoid public outcry" with a touch of "why don't you overthink your annoyances with me".
> Perceived performance is one of these tradeoffs.
Perceived performance should never be a tradeoff, only the measured performance impact can be one.
My iPhone SE from 2020 has input delays of up to 2s after the update to iOS 26 and that's just really disappointing. I wouldn't mind if it'd be in the 0,3ms range, even though that would still be terrible from a measured performance POV.
Especially if you use any of the features that make Postgres nice to work with (For example good jsonb handling) these are immediately different than on sqlite and then won't work for development. Don't think there's a good reason for not running the same DB in both environments.
I think you'd need to give answer to your own questioning here... why did you take "Rust haters" as "Rust-language haters", and not as "Rust-community haters"?
> I think you'd need to give answer to your own questioning here... why did you take "Rust haters" as "Rust-language haters", and not as "Rust-community haters"?
Because it literally says "Rust haters"; not "Rust community haters".
Are you saying that when someone refers to "Rust", they mean the community and not the language?
Am I the only one that interpreted OP in a way that they weren't opposed to neither CLIs, TUIs, nor GUIs at all? The topic wasn't "textual interface VS graphical interface", but "undocumented/natural language VS documented/query language" for navigating the internet.
In addition to the analogy of the textual interface used in Zork, we could say that it'd be like interacting with any REST API without knowledge about its specification - guessing endpoints, methods, and parameters while assuming best practices (of "natural-ness" kind). Do we really want to explore an API like that, through naive hacking? Does a natural language wrapper make this hacking any better? It can make it more fun as it breaks patterns, sure, but is that really what we want?
I'm not focused on this particular browser or the idea of using LLMs as a locus of control.
I haven't used it and have no intention of using it.
I'm reacting to the OP articulating clearly dismissive and incorrect claims about text-based applications in general.
As one example, a section is titled with:
> We left command-line interfaces behind 40 years ago for a reason
This is immediately followed by an anecdote that is probably true for OP, but doesn't match my recollection at all. I recall being immersed and mesmerized by Zork. I played it endlessly on my TRS-80 and remember the system supporting reasonable variation in the input commands.
At any rate, it's strange to hold up text based entertainment applications while ignoring the thousands of text based tools that continue to be used daily.
They go on with hyperbolic language like:
> ...but people were thrilled to leave command-line interfaces behind back in the 1990s
It's 2025. I create and use GUI applications, but I live in the terminal all day long, every day. Many of us have not left the command line behind and would be horrified if we had to.
It's not either/or, but the OP makes incorrect claims that text based interfaces are archaic and have long been universally abandoned.
They have not, and at least some of us believe we're headed toward a new golden age of mixed mode (Text & GUI) applications in the not-so-distant future.
CLIs are still powerful and enjoyable because their language patterns settled over the years. I wouldn't enjoy using one of these undiscoverable CLIs that use --wtf instead of --help, or be in a terminal session without autocomplete and zero history. I build scripts around various CLIs and like it, but I also love to install TUI tools on my servers for quick insights.
All of that doesn't change the fact that computer usage moved on to GUIs for the general audience. I'd also use a GUI for cutting videos, editing images, or navigating websites. The author used a bit of tongue-in-cheek, but in general I'd agree with them, and I'd also agree with you.
Tbh, I also think the author would agree with you, as all they did was making an anecdote that
s/Take/Pick up/
is not that far off from annoying its users than
s/atlas design/search web history for a doc about atlas core design/
is. And that's for a product that wants to rethink the web browser interface, mind you.
We are more rapidly heading towards (or already in) a future where the average household doesn't regularly use or even have a "computer" in the traditional sense, and a CLI is not just unused but entirely non-existent.
AFAICS this has nothing to do with "open-source personal AI engines".
The recorded history is stored in a SQLite database and is quite trivial to examine[0][1]. A simple script could extract the information and feed them to your indexer of choice. Developing such a script isn't the task for an internet browser engineering team.
The question remains whether the indexer would really benefit from real-time ingestion while browsing.
Due to the dynamic nature of the Web, URLs don't map to what you've seen. If I visit a URL at a certain time, the content I see is different than the content you see or even if I visit the same URL later. For example, if we want to know the tweets I'm seeing are the same as the tweets you're seeing and haven't been subtly modified by an AI, how do you do that? In the age of AI programming people, this will be important.
I'm confused, do you want more than the browser history then? ...something like Microsoft's Recall? Browsers currently don't store what they've seen and for good reasons. I was with you for a sec, but good luck convincing Mozilla to propagate rendered pages to other processes then!
> Integers are likely the most used data type of any program, that means a lot of heap allocations.
I would guess strings come first, then floats, then booleans, and then integers. Are there any data available on that?