> it's a universal tradeoff, that is: Safety is less ergonomic.

I'm not sure that that tradeoff is quite so universal. GC'd languages (or even GC'd implementations like Fil-C) are equally or even more memory-safe than Rust but aren't necessarily any less ergonomic. If anything, it's not an uncommon position that GC'd languages are more ergonomic since they don't forbid some useful patterns that are difficult or impossible to express in safe Rust.

▲

nextaccountic 2 days ago | parent | next [-]

GCed languages aren't (usually) more memory safe than safe Rust because they (usually) lack the equivalent to the Send and Sync traits and thus will not prevent unsynchronized access to the same from multiple threads, including data races. Some languages might define data races to not be UB (at least Java and OCaml do this, but Go famously doesn't), but even in those languages data races may produce garbage data due to tearing (writing to a large struct needs to be done in many steps, and without proper synchronization two concurrent updates may interleave leaving data structures in an inconsistent state)

Guaranteed thread safety is huge. I hope more high level, GC languages use Rust's approach of defining an interface for types that can be safely sent and/or shared across threads

	▲	aw1621107 2 days ago \| parent [-]
		> GCed languages aren't (usually) more memory safe than safe Rust because they (usually) lack the equivalent to the Send and Sync traits and thus will not prevent unsynchronized access to the same from multiple threads, including data races. To be honest that particular aspect of Rust's memory safety story slipped my mind when I wrote that comment. I was thinking of Java's upcoming (?) disabling-by-default of sun.misc.Unsafe which allows you to ensure that you have no unsafe code at all in your program and your dependency tree outside of the JVM itself. To be fair, that's admittedly not quite the same level of memory safety improvement over Rust as Rust/Java/C#/etc. over C/C++/etc., but I felt it's a nice guarantee to have available. > Guaranteed thread safety is huge. I totally agree! It's not the only way to get memory safety, but I definitely lean towards that approach over defining data races to be safe.

▲

SkiFire13 3 days ago | parent | prev | next [-]

The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one.

▲

quotemstr 3 days ago | parent [-]

> The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one.

That's a myth that just won't die. How is it that people simultaneously believe

1) GC makes a language slow, and

2) Go is fast?

Go's also isn't the only safe GC. There are plenty of good options out there. You are unlikely to encounter a performance issue using one of these languages that you could resolve only with manual memory management.

▲

shakow 3 days ago | parent | next [-]

Go is not fast though.

It's plenty fast compared to commonly used languages such as JS, PHP or Python, but can easily be let in the dust by Java and C#, which arguably play in the same court.

And AOT-compiled, no GC languages like C++, Rust or Zig just run circles around it.

▲

pjmlp 2 days ago | parent [-]

Not quite true if using GCC Go as compiler, however they seem to have dropped development after Go got generics.

You are comparing quality of implementation, not languages.

▲

shakow 2 days ago | parent [-]

> You are comparing quality of implementation, not languages.

But comparing languages in a vacuum has 0 value. Maybe some alien entity will use physic transcending time and space to make TCL the fastest language ever, but right now I won't be writing heavy data-processing code in it.

▲

pjmlp 2 days ago | parent [-]

At the same time, comparing without acknowledging that it is an implemenation issue, it is also not being fully honest.

For example, comparing languages with LLVM based implementations, usually if the machine code isn't the same, reveals that they aren't pushing the same LLVM IR down the pipe, and has little value for what the grammar actually looks like.

▲

shakow 2 days ago | parent [-]

> comparing without acknowledging that it is an implemenation issue

Because that's implicit at this point – I'm not going to prefix with “because Earth geometry is approximately Euclidian at our scale” every time I'm telling a tourist to go straight ahead for 300m to their bus station.

Just like when people say “C++ is fast”, of course they refer to clang/g++/msvc, not some educational university compiler.

	▲	pjmlp 2 days ago \| parent [-]
		I seriously doubt it, given how many discussions go on HN or similar sites, revealing a complete lack of knowledge in compiler design. Of course the authors of many of such comments aren't to blame, they only know what they know, hence why https://xkcd.com/386/

▲

cheshire_cat 3 days ago | parent | prev | next [-]

Go is fast compared to Python or Ruby. Go is not fast compared to C.

I think people that talk about GC'd languages being slow are usually not building Rails or Django apps in their day to day.

▲

on_the_beach 3 days ago | parent [-]

Not a Go programmer I'm guessing.

Go can be made to run much faster than C.

Especially when the legacy C code is complex and thus single threaded, Go's fabulous multicore support means you can be exploiting parallelism and finishing jobs faster, with far less effort than it would take to do it in C.

If you measure performance per developer day invested in writing the Go, Go usually wins by a wide margin.

	▲	quotemstr 3 days ago \| parent [-]
		> Go can be made to run much faster than C. Not literally the case. > If you measure performance per developer day invested in writing the Go, Go usually wins by a wide margin. I can accept that performance/hour-spent is better in Go than C, but that's different from Go's performance ceiling being higher than C's. People often confuse ceilings with effort curves.

▲

somanyphotons 2 days ago | parent | prev | next [-]

Go is middle-pack fast, not fast-fast.

There are always going to be problem sets where the GC causes significant slowdown.

▲

rixed 3 days ago | parent | prev [-]

> How is it that people simultaneously believe > 1) GC makes a language slow, and > 2) Go is fast?

Easy one: either not the same people, or people holding self contradicting thoughts.

GC are slow not only because of scanning the memory but also because of the boxing. In my experience, 2 to 3 times slower.

Still a better tradeoff in the vast majority of cases over manual memory management. A GC is well worth the peace of mind.

▲

quotemstr 3 days ago | parent [-]

> also because of the boxing

Not every GC boxes primitives. Most don't.

▲

rixed 3 days ago | parent [-]

Sure. What about non primitives?

▲

pjmlp 2 days ago | parent [-]

CLU, Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Oberon-07, Active Oberon, Component Pascal, Eiffel, Sather, BETA, D, Nim, Swift, C#, F# are all examples of GC based languages with value types that can be used without any kind of boxing.

	▲	rixed 2 days ago \| parent [-]
		Impressive erudition and interresting list of nice languages, some of which I'd never heard about, thank you. Yes indeed not all GCed languages suffer from mandatory boxing. I've been both picky and wrong, which is not a nice place to find oneself in :)

▲

mattwilsonn888 3 days ago | parent | prev [-]

*Under the assumption that you are maximizing both. I often hear complaints that Rust's semantics actually haven't maximized ergonomics, even factoring in the added difficulty it faces in pursuit of safety.

It's totally possible languages as ergonomic as Rust can be more safe, just because Rust isn't perfect or even has some notable, partially subjective, design flaws.

▲

aw1621107 3 days ago | parent [-]

> Under the assumption that you are maximizing both.

I'm not sure that changes anything about my comment? GC'd languages can give you safety and* ergonomics, no need to trade off one for the other. Obviously doing so requires tradeoffs of their own, but such additional criteria were not mentioned in the comment I originally replied to.

> I often hear complaints that Rust's semantics actually haven't maximized ergonomics, even factoring in the added difficulty it faces in pursuit of safety.

Well yes, that's factually true. I don't think anyone can disagree that there aren't places where Rust can further improve ergonomics (e.g., partial borrows). And that's not even taking into account places where Rust intentionally made things less ergonomic (around raw pointers IIRC, though I think there's some discussion about changing that).

> It's totally possible languages as ergonomic as Rust can be more safe

It's definitely possible (see above about GC'd languages). There are just other tradeoffs that need to be made that aren't on the ergonomics <-> safety axis.

▲

mattwilsonn888 3 days ago | parent [-]

Your earlier point that languages exist that are safer than Rust but not less ergonomic is irrelevant - that's the point I made.

One can fail, or artificially make a language less ergonomic and that doesn't mean that fixing that somehow has an effect on the safety tradeoff.

So obviously it is when safety and ergonomics are each already maximized that pushing one or the other results in a tradeoff. It's like saying removing weight from a car isn't a tradeoff because the weight was bricks in the trunk.

Anyways I was holding performance constant in all of this because the underlying assumption of Rust and Zig and Odin and C is that performance will make no sacrifices.

	▲	aw1621107 3 days ago \| parent [-]
		> that's the point I made. That's not the way I read your original comment. When you said "it's a universal tradeoff, that is: Safety is less ergonomic", to me the implication is that gaining safety must result in losing ergonomics and vice versa. The existence of languages that are as safe/safer than Rust and more ergonomic than Rust would seem to be a natural counterexample since they have gained safety over Zig/C/C++ and haven't (necessarily, depending on the exact language) sacrificed ergonomics to do so. > One can fail, or artificially make a language less ergonomic and that doesn't mean that fixing that somehow has an effect on the safety tradeoff. To be honest that case didn't even cross my mind when I wrote my original comment. I was assuming we were working at the appropriate Pareto frontier. > So obviously it is when safety and ergonomics are each already maximized that pushing one or the other results in a tradeoff. Assuming no other relevant axes are available, sure. > Anyways I was holding performance constant in all of this because the underlying assumption of Rust and Zig and Odin and C is that performance will make no sacrifices. Sure. Might have been nice to include that assumption in your original comment, but even then I'm not sure it's too wise to ignore the performance axis completely due to the existence of safe implementations of otherwise "unsafe" languages (e.g., Zig's ReleaseSafe, GCs for C like Fil-C, etc.) that trade off performance for safety instead of ergonomics.