> the “equation of capitalism and markets” is a tragic misconception
Must be a big city isolation thing? In rural areas co-ops are a common part of every day life. The internet is provided by a co-op, the store is a co-op, the gas station is a co-op, etc. It is impossible in that environment to not see that shared ownership and markets fit together just fine.
I think what they’re getting at with this is that markets can exist without some of nastier parts of capitalism (e.g. a co-op operates in a market economy) but so much of the prevailing wisdom (both positive and negative) about capitalism equates markets with capital’s power-distribution function.
markets have existed forever. what is new since the dutch invention of capitalism is the cycle of money->commodity->money instead of commodity->money->commodity. That is, production for money instead of simple exchange.
This different cycle has massive implications, and changes how investments are made. Instead of people investing in things for themselves, they invest explicitly for production for the market and for other people for things they will never use themselves.
In China, the post-Deng consensus is to use markets in service of socialist development. People can be critical of this, but Deng's idea was that: "it doesn't matter if a cat is black or white, if it catches mice it's a good cat" meaning that markets, even with some capitalist mechanics, if subservient to socialist politics, can still be used to socialist ends. Personally, I am still trying to decide how I feel about that, but it's also hard to argue with (so far) something that looks like success.
It used to be way more informal and less institutional, but I'm skeptical that it was more communal. We're still heavily dependent on community to raise our children (e.g. school, spots, etc). Sometimes to the point of absurdity.
> governance by elected officials is not democratic.
Correct. In a (representative) democracy, one does not elect officials. They elect representatives. The representative is not an authority like an official is. They are merely messengers who take the constituent direction established at the local level and travel with that message to deliver it in a country/state/etc.'s central gathering place.
> Then we need to decide if we actually want democracy or not.
We (meaning most people) do not. Democracy is a lot of work. An incredible amount of work. It requires active participation on a near-daily basis. Most people would rather do things like go to their job to put food on the table or spend time with their hobbies or other pleasure activities. Which is why most people seek — by your own admission — officials to lord over them instead.
> Personally, I’d like this decision to be… err… you know, it would be nice if everyone had a say?
It is nice when you are independently wealthy and no longer have to worry about things like giving up an enormous amount of your day to keep a roof over your head. But most people are not so fortunate, so they do not find it fair that, for all realistic purposes, only some people get to participate in democracy to their own advantage. Hence why democracies devolve into a system of officials instead, with most people believing it offers a better balance for all involved, albeit at the cost of losing say.
> They are merely messengers who take the constituent direction established at the local level and travel with that message to deliver it in a country/state/etc.'s central gathering place.
No. That is exclusively an USA thing. I live in a representative democracy and I vote for the parliamentarian. Representative vs. direct democracy is about whether the people vote on laws directly or not.
> We (meaning most people) do not.
Most people don't want to write the laws, yes. They still want to have a say about the content. Most house owners also don't want to build the house. They still want to have a say what the construction company does.
But in your example, it sounds like representative democracy is a choice freely taken. If people actually want representatives to worry about the details of policy for them, then that is real democracy, because the alternative is a form of government that the people don't actually want.
Maybe something like a publicly traded company, Citizens can vote directly on individual bills, or choose a proxy to vote on their behalf (and change that choice at any point that desire).
It wouldn't actually change anything, because your single direct vote wouldn't have any outcome at all. It would by negligible compared to all the votes from the proxies, because they represent millions and you just one. It would result in the same outcome, talking to the proxy gets your point better across than voting yourself.
> Which is why most people seek — by your own admission — officials to lord over them instead.
I don’t recall saying that. On the contrary, I believe people are forced to let officials rule over them, in part by lack of time and other resources, but also in a big part because they believe their government is democratic, even when it is increasingly not.
To give a couple examples in France: in 2005 about 60% of French people voted against the Treaty establishing a Constitution for Europe, despite predictions to the contrary by mass media, and overwhelming representative support. It wasn’t just defiance, there were quite a few objections to the text itself. Then a relatively short while later, a functionally identical text was voted by the parliament. That was the first time I realised my country was no longer, if ever, a democracy. Then over time we had unpopular reforms over unpopular reforms, culminating retirement reform, which all indicators show like about 70% of the population was against. All passed. Not long before that there was a popular demand for citizen initiated binding referendums. Ignored.
The people there did more than discuss in their private homes and answered surveys. We voted. We protested, down in the streets. The state answered with increasing violence. Documented repression tactics, turning a blind eye to police misconduct… A real shame in what was supposed to be the country of Human Rights — that too, we are no longer.
So yeah, politics takes time and effort. But it goes beyond that: work is inequitably spread, split between working overtime for relatively little benefit, and utter unemployment. (The split isn’t all that clear cut, I myself work 4 days a week, because I can afford the pay cut.) And on top of that, peaceful protests now put us in increasing physical danger. People lose their hands, their eyes, and in some (thankfully still rare) cases their lives.
No wonder so many people chose to just disengage at this point.
> But most people are not so fortunate, so they do not find it fair that, for all realistic purposes, only some people get to participate in democracy to their own advantage. Hence why democracies devolve into a system of officials instead, with most people believing it offers a better balance for all involved, albeit at the cost of losing say.
I believe this is false, as a matter of historical fact. At least in France. When we had our Bourgeois Revolution (sure the people were starved and all, but it was coopted quite quickly), there were discussions about whether we should have democracy, or a representative government. Note the wording: "representative democracy" would have been a ridiculous oxymoron at the time. Anyway, democracy was shut down, in big part because the bourgeois discussing this decided that the people couldn’t steer themselves. Nevermind the Paris Commune, who did steer themselves for a very short while, but never got the chance to prove itself — the army disbanded them with bullets, over 10,000 killed.
Another example are randomly sampled assemblies. Constituent assemblies, or assemblies with a specific purpose. When analysed after the fact we generally find that their decisions are pretty well reasoned, well grounded, well documented, and (shocker), serve the actual interests of the people — of course they would be, since the members would then go on being subject to their own decisions.
But as the parent comment suggests, if the adults were getting sick it is unlikely that they would be able to:
* Produce 5 kids in the first place.
* Take care of the kids that they were able to produce, making survival of even half them much less likely.
But in actuality, best we are able to determine hunter-gathers who made it into adulthood lived longer, healthier lives than those in agrarian lifestyles.
They were getting sick and died more often than us, but still enough survived to keep the population alive. There's no contradiction.
I admit they probably had a stronger immunologic system on average, by virtue of relying on it and "exercising" more often. Alternatively, people prone to getting sick just died early.
> They were getting sick and died more often than us
The comparison was with agrarian societies that were found in parallel, not "us", which presumably implies something about modern medicine. Have I misinterpreted you?
> There's no contradiction.
Was there reason to think that there was...? It is not clear what you are trying to add here.
> Take care of the kids that they were able to produce, making survival of even half them much less likely.
H-G societies tend to be smaller groups where everyone in the village helps with childcare, so if a parent was out of action for a while the children could still be gathered.
This is covered in the book Hunt, Gather, Parent by Michaeleen Doucleff, specifically with the Hadzabe people (Tanzania).
"Way after" is quite an overstatement. Smallpox is as old as agriculture. Most seem to agree that it was the transition into agrarian life that provided the necessary conditions for it to emerge, but it did so right as that transition took place.
> Or would C++98 also be considered a GC language due to auto_ptr?
auto_ptr does not exhibit qualities of GC.
> Are no_std Rust and freestanding C++ GC languages?
These are not different languages. A developer opting out of certain features as enabled by the language does not change the language. If one was specific and said "no_std Rust", then you could fairly say that GC is not available, but that isn't applicable here. We are talking about "Rust" as written alone.
> Does the existence of Fil-C change anything about whether C is a GC language?
No. While Fil-C is heavily inspired by C, to the point that it is hard to distinguish between them, it is its own language. You can easily tell they are different languages as not all valid C is valid Fil-C.
OK, so by the definition you're using C++ became a GC language with C++11?
> If one was specific and said "no_std Rust", then you could fairly say that GC is not available, but that isn't applicable here.
I'd imagine whether or not GC capabilities are available in the stdlib is pretty uncontroversial. Is that the criteria you're using for a GC language?
> No. While Fil-C is heavily inspired by C, to the point that it is hard to distinguish between them, it is its own language. You can easily tell they are different languages as not all valid C is valid Fil-C.
OK, fair; perhaps I should have been more abstract, since the precise implementation isn't particularly important to the point I'm trying to get to. I should have asked whether the existence of a fully-compatible garbage collecting implementation of C change anything about whether C is a GC language. Maybe Boehm with -DREDIRECT_MALLOC might have been a better example?
> I should have asked whether the existence of a fully-compatible garbage collecting implementation of C change anything about whether C is a GC language.
In a similar vein, tinygo allows compilation without GC[1]. That is despite the Go spec explicitly defining it as having GC. Is Go a GC language or not?
As you can see, if it were up to implementation, a GC/non-GC divide could not exist. But it does — we're talking about it. The answer then, of course, is that specification is what is significant. Go is a GC language even if there isn't a GC in implementation. C is not a GC language even if there is one in implementation. If someone creates a new Rust implementation that leaves out Rc and Arc, it would still be a GC language as the specification indicates the presence of it.
[1] It doesn't yet quite have full feature parity so you could argue it is more like the Fil-C situation, but let's imagine that it is fully compatible in the same way you are suggesting here.
You make some good points, and after thinking some more I think I agree that the existence of GC/non-GC implementations is not determinative of whether a language is typically called a GC language.
After putting some more thought into this, I want to say where I diverge from your line of thinking is that I think whether a language spec offers GC capabilities is not sufficient on its own to classify a language as a "GC language"; it's the language's dependence on said GC capabilities (especially for "normal" use) that matters.
For example, while you can compile Go without a GC, the language generally depends on the presence of one for resource management to the point that a GC-less Go is going to be relatively restricted in what it can run. Same for Java, JavaScript, Python, etc. - GC-less implementations are possible, but not really reasonable for most usage.
C/C++/Rust, on the other hand, are quite different; it's quite reasonable, if not downright common, to write programs that don't use GC capabilities at all in those languages. Furthermore, removing std::shared_pointer/Rc/Arc from the correspondning stdlibs wouldn't pose a significant issue, since writing/importing a replacement is something those languages are pretty much designed to be capable of.
I'm not sure this opt-in/out "philosophical razor" is as sharp as one would like it to be. I think "optionality" alone oversimplifies and a person trying to adopt that rule for taxonomy would just have a really hard time and that might be telling us something.
For example, in Nim, at the compiler CLI tool level, there is opt-in/opt-out via the `--mm=whatever` flag, but, at the syntax level, Nim has both `ref T` and `ptr T` on equal syntactic footing . But then in the stdlib, `ref` types (really things derived from `seq[T]`) are used much more (since it's so convenient). Meanwhile, runtimes are often deployment properties. If every Linux distro had their libc link against -lgc for Boehm, people might say "C is a GC'd language on Linux". Minimal CRTs vary across userspaces and OS kernel/userspace deployment.. "What you can rely on/assume", I suspect the thrust behind "optionality", just varies with context.
Similar binding vagueness between properties (good, bad, ugly) of a language's '"main" compiler' and a 'language itself' and 'its "std"lib' and "common" runtimes/usage happen all the time (e.g. "object-oriented", often diluted by the vagueness of "oriented"). That doesn't even bring in "use by common dependencies" which is an almost independent axis/dimension and starts to relate to coordination problems of "What should even be in a 'std'-lib or any lib, anyway?".
I suspect this rule is trying to make the adjective "GC'd" do more work in an absolute sense than it realistically can given the diversity of PLangs (sometimes not so visible considering only workaday corporate PLangs). It's not always easy to define things!
> I think "optionality" alone oversimplifies and a person trying to adopt that rule for taxonomy would just have a really hard time and that might be telling us something.
I think optionality is what gives that definition weight.
Think of it this way. You come to a project like a game engine, but you find it's written in some language and discover for your usage you need no/minimal GC. How hard is it to minimize or remove GC. Assume that changing build flags will also cause problems elsewhere due to behavior change.
> Similar binding vagueness between properties (good, bad, ugly) of a language's '"main" compiler' and a 'language itself' and 'its "std"lib' and "common" runtimes/usage happen all the time (e.g. "object-oriented", often diluted by the vagueness of "oriented")
Vagueness is the intrinsic quality of human language. You can't escape it.
The logic is fuzzy, but going around saying stuff like "Rust is a GC language" because it has an optional, rarely used Arc/Rc, is just off the charts level of wrong.
You can add your own custom GC in C — you can add your own custom anything to any language; its all just 1s and 0s at the end of the day — but it is not a feature provided by the language out of the box like in Rust. Not the same token at all. This is very different.
...as part of the language. Hence it being a GC language.
Is this another case of "Rustacians" randomly renaming things? There was that whole debacle where sum types bizarrely became enums, even though enums already had an established, different meaning, with all the sad talking past everyone else that followed. This is starting to look like that again.
I can't say I've heard of a commonly used definition of "GC language" that includes C++ and excludes C. If anything, my impression is that both C and C++ are usually held up as exemplars of non-GC languages.
C++ didn't add GC until relatively recently, to be fair. When people from 30 years ago get an idea stuck in their head they don't usually ever change their understanding even as life continues to march forward. This isn't limited to software. If you look around you'll regularly find people repeating all kinds of things that were true in the past even though things have changed. And fair enough. There is only so much time in the day. You can't possibly keep up to date on everything.
The thing is that the usual comparisons I'm thinking of generally focused on how much the languages in question rely on GC for practical use. C++11 didn't really move the needle much, if at all, in that respect compared to the typical languages on the other side of said comparisons.
Perhaps I happen to have been around different discussions than you?
> focused on how much the languages in question rely on GC for practical use.
That's quite nebulous. It should be quantified. But, while we wait for that, if we assume by that metric C++ is not a GC language today, but tomorrow C++ developers all collectively decide that all heap allocations are to depend on std::shared_ptr, then it must become a GC language.
But the language hasn't changed in any way. How can an attribute of the language change without any changes?
Perhaps, but I'm reluctant to speak more definitively since I don't consider myself an authority/expert in the field.
> But the language hasn't changed in any way. How can an attribute of the language change without any changes?
The reason I put in "for practical use" is because since pedantically speaking no language actually requires GC - you "just" need to provision enough hardware (see: HFT firms (ab)use of Java by disabling the GC and resetting programs/machines at the end of the day). That's not relevant for basically everyone, though, since practically speaking you usually want to bound resource use, and some languages rely on a GC to do that.
I guess "general" or "normal" might have been a better word than "practical" in that case. I didn't intend to claim that how programmers use a language affects whether it should be considered a GC language or not.
Which part? It's not available in no-std without alloc crate. You can write your own Arc.
Most crates don't have to use Arc/Rc.
> Is this another case of "Rustacians" randomly renaming things?
No. This is a case of someone not having enough experience with Rust. Saying Rust is a GC language is like claiming Pascal is object oriented language because they share some surface similarities.
> It's not available in no-std without alloc crate.
no-std disables features. It does not remove them from existence. Rust's worldly presence continues to have GC even if you choose to disable it for your particular project.
> This is a case of someone not having enough experience with Rust.
Nah. Even rust-lang.org still confuses sum types and enums to this very day. How much more experienced with Rust can you get than someone versed enough in the language to write comprehensive, official documentation? This thought of yours doesn't work.
> Saying Rust is a GC language is like claiming Pascal is object oriented language because they share some surface similarities.
What surface similarity does Pascal have to OO? It only has static dispatch. You've clearly not thought that one through.
Turbo Pascal has dynamic dispatch. Perhaps you've confused different languages because they happen to share similar names? That is at least starting to gain some surface similarity to OO. But message passing, of course, runs even deeper than just dynamic dispatch.
Your idea is not well conceived. Turbo Pascal having something that starts to show some very surface-level similarity to OO, but still a long way from being the real deal, isn't the same as Rust actually having GC. It is not a case of Rust having something that sort of looks kind of like GC. It literally has GC.
> no-std disables features. It does not remove them from existence.
It's the other way around; standard library adds features. Because Rust features are designed to be additive.
Look into it. `std` library is nothing more than Rust-lang provided `core`, `alloc` and `os` crates.
> Nah.
You don't seem to know how features work, how std is made or how often RC is encountered in the wild. It's hard to argue when you don't know language you are discusing.
> Even rust-lang.org still confuses sum types and enums to this very day.
Rust lang is the starting point for new Rust programmers; why in the heck would they start philosophizing about a bikesheddy naming edge case?
That's like opening your car manual to see history and debates on what types of motors preceded your own, while you're trying to get the damn thing running again.
> What surface similarity does Pascal have to OO?
Dot operator as in (dot in `struct.method`). The guy I was arguing with unironically told me that any language using the dot operator is OO. Because the dot operator is a sign of accessing an object or a struct.
Much like you, he had very inflexible thoughts on what makes or does not make something OO; it reminds me so much of you saying C++ is a GC-language.
> Your idea is not well conceived.
My idea is to capture the colloquial meaning of GC-language. The original connotation is to capture languages like C#, Java, JS, etc. That comes with a (more or less) non-removable tracing garbage collector. In practice, what this term means is
- How hard is it to remove and/or not rely on GC? Defaults matter a lot.
- How heavy is the garbage collection GC? Is it just RC or ARC?
- How much of the ecosystem depends on GC?
And finally, how many people are likely to agree with it? I don't care if my name is closest to frequency of red, if no one else agrees.
I'm not sure your characterization is all that accurate.
Originally, they thought they could build a product that worked across many languages. That necessitated a "lowest common denominator" language, which is a void that has always been strangely lacking in choice, to provide an integratabtle core. Zig had only been announced a few months earlier, so it wasn't really ready to be a contender. For all intents and purposes, C, C++, and Rust were the only options.
Once the product made it to market, it became clear that the Typescript ecosystem was the only one buying in. Upon recognizing the business failure, the "multi-language" core didn't make sense anymore. It was a flawed business model that forced them into using Rust (could have been C or C++ instead, but yeah) and once they gave up on that business model they understood that it would have been better to have been written it in Typescript in the first place — and it no doubt would have been if it weren't for the lofty pie in the sky dreams of trying to make it more than the market was willing to accept. Now they got the opportunity to actually do it.
They're not that free about beer. Though, more free about beer than liquor. That's only allowed to be sold in state run liquor stores. It was a real head scratcher when I first encountered it.
reply