3 ms·

> It was obvious that everything you can do in C++ can be done in D in so much easier way that it could have replaced C++ in a near future if done right. Do yo

> It was obvious that everything you can do in C++ can be done in D in so much easier way that it could have replaced C++ in a near future if done right. Do you have an opinion on how the GC schism within D affected it competitively with regards to C/C++?

lifthrasiir 3y ago
While I don't know well about exact arguments for and against GC in that incident, I believe it's worthwhile to consider two cases when you want to avoid GC. One is the case where you shouldn't run GC because you have a very strict time limit and any GC pause is not desirable. The other is the case where GC pauses are discouraged but not the end of the world. D's `@nogc` only caters the former, which is much rarer than the later (i.e. hard realtime vs. soft realtime). So I think `@nogc` should have been more like an `@explicitgc`, where any allocation and thus GC pause should be marked in the syntax, but is not forbidden otherwise. But I do agree that something like `@nogc` was required.
- Narishma 3y ago
  What about the situations where you don't want the memory overhead of the GC?
  - lifthrasiir 3y ago
    Again, the answer depends on whether you absolutely don't want that or just want to minimize that. I believe something like `@explicitgc` is enough annoyance to make sure that you are conscious about GC and memory allocation. If you need even more guarantee, you have to make sure that everything you transitively call is i) marked as `@explicitgc` and ii) has no GC call inside. Given enough demand you may have both `@nogc` and `@explicitgc` as well, but I think the hard guarantee is not something usually want. Maybe you wanted me to answer about some magical sauce that can conveniently avoid such issues, but I want to make a point that there is no such thing. In fact, Rust is praised for its strictness about memory safety, but that owes much to the existence of `panic`, and you know what? What I've described earlier equally applies to the `panic` behavior in Rust. You can not avoid panicking in Rust, though you can avoid panicking as much as possible and make `panic` immediately fail to avoid any further overhead, so you are liable for any panicking in your code. In the same way, if you really don't want to touch GC you are in the minority and should be served well with a placeholder GC that always fails. Anything beyond that is not something you can't expect from mainstream programming in the near future.
    - dwattttt 3y ago
      It's not strictly impossible to avoid panicing in Rust, but it's pretty painful. The approaches typically involve forcing a linker error if a panic is linked (https://docs.rs/no-panic https://docs.rs/no-panic). Yes, you'll be (re)writing a lot more code than if panics are acceptable.

lifthrasiir 3y ago

While I don't know well about exact arguments for and against GC in that incident, I believe it's worthwhile to consider two cases when you want to avoid GC. One is the case where you shouldn't run GC because you have a very strict time limit and any GC pause is not desirable. The other is the case where GC pauses are discouraged but not the end of the world. D's `@nogc` only caters the former, which is much rarer than the later (i.e. hard realtime vs. soft realtime). So I think `@nogc` should have been more like an `@explicitgc`, where any allocation and thus GC pause should be marked in the syntax, but is not forbidden otherwise. But I do agree that something like `@nogc` was required.

Narishma 3y ago
What about the situations where you don't want the memory overhead of the GC?
- lifthrasiir 3y ago
  Again, the answer depends on whether you absolutely don't want that or just want to minimize that. I believe something like `@explicitgc` is enough annoyance to make sure that you are conscious about GC and memory allocation. If you need even more guarantee, you have to make sure that everything you transitively call is i) marked as `@explicitgc` and ii) has no GC call inside. Given enough demand you may have both `@nogc` and `@explicitgc` as well, but I think the hard guarantee is not something usually want. Maybe you wanted me to answer about some magical sauce that can conveniently avoid such issues, but I want to make a point that there is no such thing. In fact, Rust is praised for its strictness about memory safety, but that owes much to the existence of `panic`, and you know what? What I've described earlier equally applies to the `panic` behavior in Rust. You can not avoid panicking in Rust, though you can avoid panicking as much as possible and make `panic` immediately fail to avoid any further overhead, so you are liable for any panicking in your code. In the same way, if you really don't want to touch GC you are in the minority and should be served well with a placeholder GC that always fails. Anything beyond that is not something you can't expect from mainstream programming in the near future.
  - dwattttt 3y ago
    It's not strictly impossible to avoid panicing in Rust, but it's pretty painful. The approaches typically involve forcing a linker error if a panic is linked (https://docs.rs/no-panic https://docs.rs/no-panic). Yes, you'll be (re)writing a lot more code than if panics are acceptable.