Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removed rust to gain speed

prisma.io

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Removed rust to gain speed

#61

Post by [deleted] »

aw1621107 wrote: post #58
9rx wrote: post #55

Earlier quoted context omitted.

> 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…

> auto_ptr does not exhibit qualities of GC. 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 i…

[deleted]

Re: Removed rust to gain speed

#62

Post by 9rx »

aw1621107 wrote: post #58
9rx wrote: post #55

Earlier quoted context omitted.

> 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…

> auto_ptr does not exhibit qualities of GC. 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 i…

> 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.

Re: Removed rust to gain speed

#63

Post by 9rx »

aw1621107 wrote: post #59
9rx wrote: post #56

Earlier quoted context omitted.

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…

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?

Re: Removed rust to gain speed

#64

Post by 9rx »

Ygg2 wrote: post #54
9rx wrote: post #48

Earlier quoted context omitted.

...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.

> ...as part of the language. 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.

> Which part?

The part that is detailed on rust-lang.org.

> 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.

Re: Removed rust to gain speed

#65

Post by aw1621107 »

9rx wrote: post #62
aw1621107 wrote: post #58

Earlier quoted context omitted.

> auto_ptr does not exhibit qualities of GC. 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 i…

> 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…

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.

Re: Removed rust to gain speed

#66

Post by aw1621107 »

9rx wrote: post #63
aw1621107 wrote: post #59

Earlier quoted context omitted.

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 att…

> That's quite nebulous. It should be quantified.

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.

Re: Removed rust to gain speed

#67

Post by Ygg2 »

9rx wrote: post #64
Ygg2 wrote: post #54

Earlier quoted context omitted.

> ...as part of the language. 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.

> Which part? The part that is detailed on rust-lang.org. > 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 ve…

> 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.

Re: Removed rust to gain speed

#68

Post by baranul »

anon-3988 wrote: post #24

I claim that 99.9999% of software should be written in a GC language. Very, very, very few problems actually requires memory management. It is simply not part of the business requirement. That said, how come the only language closest to this criteria is Go except it hasn't learn about clean water (algebraic data types).

Good point. However, similar offshoot languages of Golang, do have them. Those are Vlang (aka Sum Types) and Odin (aka Discriminated Unions). However and per your comment, only Vlang has the optional GC (used by default) and the flexible memory management philosophy (to turn the GC off without its stdlib depending on it).

Re: Removed rust to gain speed

#69

Post by baranul »

BenoitP wrote: post #36
theamk wrote: post #27

Earlier quoted context omitted.

Large parts of web browsers (like entire Firefox' UI) is written in javascript already Operating systems _should_ use GC languages more. Sure, video needs to have absolute max performance... but there is no reason my keyboard or mouse driver should be in non-GC language.

Most programs should be written in GCd languages, but not this. Except in a few cases, GCs introduce small stop-the-world pauses. Even at 15ms pauses, it'd still be very noticeable.

Might want to read up on Ponylang. GC'd FOSS language without the stop-the-world pauses, demonstrating that it's possible. Should also be pointed out, that there are a number of proprietary solutions that claim GC with no pauses. Unfortunately, if coming from more common C-family languages, Ponylang may require more to get used to the actor model and different syntax.
Post reply on HN