3 ms·

> D is more pragmatic Being pragmatic is a very questionable claim. Its exact meaning varies from time to time, and a property that a certain people consider t

> D is more pragmatic Being pragmatic is a very questionable claim. Its exact meaning varies from time to time, and a property that a certain people consider to be pragmatic can be considered to be not pragmatic by another people. It's mostly meaningless. For example, for embedded devices D is a no-go from the beginning. I'm not just saying the reliance on GC. D has a few ridiculous behavior that may cost significantly on the low resource devices, such as http://forum.dlang.org/thread/mr6bl7$26f5$1@digitalmars.com http://forum.dlang.org/thread/mr6bl7$26f5$1@digitalmars.com D is never pragmatic in this area. But of course, D may be pragmatic in other areas. > expressive D and Rust have different kinds of expressiveness. While D has much better compile-time metaprogramming, how do you express affine type in D? In Rust affine type is very fundamental and we can utilize it to define the exact meaning of our programs. > and generally has better performance (e.g. bounds checking is optional). What? How can a GC'ed language be faster than a non-GC'ed language? Besides simple numeric evaluation, D is generally more heap-allocation-heavy than Rust, so it can never beat Rust. After all, there's no point in Rust if it's slower than a GC'ed language. The benchmarks you linked are questionable too, as their results say D is faster than C. Are you really sure D can outperform C in general cases?

rpedela 11y ago
> How can a GC'ed language be faster than a non-GC'ed language? Besides simple numeric evaluation, D is generally more heap-allocation-heavy than Rust, so it can never beat Rust. I would be interested in benchmarks showing that. Do you have any?
- deleted 11y ago
  [deleted]
- yokohummer7 11y ago
  Sorry, I don't have specific numbers. I was saying generally for all GC'ed languages.
  - qznc 11y ago
    D has lots of tools to avoid heap allocation. There is no reason why D should use more heap allocations than Rust. A GC might only encourage you to use more heap allocations.
CyberShadow 11y ago
> Being pragmatic is a very questionable claim. Its exact meaning varies from time to time, and a property that a certain people consider to be pragmatic can be considered to be not pragmatic by another people. It's mostly meaningless. I disagree that it is meaningless. It's simply subjective. I've used D since 2006 and tried most new programming languages that appeared since, and it seems like they all tried to solve a specific problem (e.g. Go - concurrency, Rust - memory safety) while giving less attention to everything else. > For example, for embedded devices D is a no-go from the beginning. Existing D projects contradict that. They simply don't use the standard D runtime when it's not appropriate. Alternative runtimes exist. Rust users do the same thing: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-static-linux-binary-in-rust.html http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-... > D and Rust have different kinds of expressiveness. While D has much better compile-time metaprogramming, how do you express affine type in D? In Rust affine type is very fundamental and we can utilize it to define the exact meaning of our programs. Can you provide a good example of affine types and how they help with expressiveness? My view of expressiveness in D does not stop at compile-time metaprogramming. For example, here's an excerpt from one of my programs: http://dump.thecybershadow.net/fb6c5a080c7a42ecd8d1f062b58a540d/000000CF.txt http://dump.thecybershadow.net/fb6c5a080c7a42ecd8d1f062b58a5... > How can a GC'ed language be faster than a non-GC'ed language? It is entirely plausible. For example, deallocation/destruction can run in a background thread, heap compaction removes heap fragmentation and improves cache locality, and of course throwing away all memory after the program is done executing is very practical if the program would otherwise do little deallocating overall. > Are you really sure D can outperform C in general cases? I don't know what's going on there, but "higher-level" languages outperforming C is not that uncommon, for example due to stricter aliasing rules or SIMD array vector operations, or simply due to language or standard library facilities being readily available (e.g. STL or associative arrays) which would be cumbersome or impractical to write/maintain in C versions.
- yokohummer7 11y ago
  > Can you provide a good example of affine types and how they help with expressiveness? For example, let's say there's an HTTP server handler that must send each header line first, and finally send a body. So you should: conn.send_header("HTTP/1.1 200 OK"); conn.send_header("Connection: Close"); conn.send_header("Content-type: text/html"); conn.send_body("Hello, world!"); In Rust, you can construct the API so that you cannot call `send_body` before any occurrences of `send_header`. So if you do: conn.send_body("I'm sent first!"); conn.send_header("Content-type: text/html"); you will get a compile error. This greatly reduces the risk of having incorrect logic in your program. In this case Rust helps ensuring our intention: `send_body` can only be the last call of the request handler. I consider this a good example of expressiveness of Rust (and affine types).
qznc 11y ago
> How can a GC'ed language be faster than a non-GC'ed language? Why should a GC'ed language be slower than a non-GC'ed language? The evidence [0,1,2] seems more like: Given enough memory, GC is faster. Non-GC means explicit deterministic free at specific points in the source code. A garbage collector has the freedom to delay the free, which means potential for optimization. [0] https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf [1] http://www.cs.princeton.edu/~appel/papers/cmljava.html http://www.cs.princeton.edu/~appel/papers/cmljava.html [2] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.1816 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.1...
- pcwalton 11y ago
  > The evidence [0,1,2] seems more like: Given enough memory, GC is faster. You really have to take Appel papers with a large grain of salt in 2015. Caches and multithreading have come to dominate nowadays, and assuming that all memory access is equal isn't reasonable. Also, the first paper doesn't make the claim that GC is faster than manual memory management—in fact, manual memory management was faster. > A garbage collector has the freedom to delay the free, which means potential for optimization. People commonly say this, but I don't see how a malloc couldn't do the same thing if it actually helped. Malloc implementations typically don't do delayed reclamation because it doesn't help; if it did help, they would do it. But cache is king, and prompt reuse of space is most important nowadays.

rpedela 11y ago

> How can a GC'ed language be faster than a non-GC'ed language? Besides simple numeric evaluation, D is generally more heap-allocation-heavy than Rust, so it can never beat Rust. I would be interested in benchmarks showing that. Do you have any?

deleted 11y ago
[deleted]
yokohummer7 11y ago
Sorry, I don't have specific numbers. I was saying generally for all GC'ed languages.
- qznc 11y ago
  D has lots of tools to avoid heap allocation. There is no reason why D should use more heap allocations than Rust. A GC might only encourage you to use more heap allocations.

CyberShadow 11y ago

> Being pragmatic is a very questionable claim. Its exact meaning varies from time to time, and a property that a certain people consider to be pragmatic can be considered to be not pragmatic by another people. It's mostly meaningless. I disagree that it is meaningless. It's simply subjective. I've used D since 2006 and tried most new programming languages that appeared since, and it seems like they all tried to solve a specific problem (e.g. Go - concurrency, Rust - memory safety) while giving less attention to everything else. > For example, for embedded devices D is a no-go from the beginning. Existing D projects contradict that. They simply don't use the standard D runtime when it's not appropriate. Alternative runtimes exist. Rust users do the same thing: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-static-linux-binary-in-rust.html http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-... > D and Rust have different kinds of expressiveness. While D has much better compile-time metaprogramming, how do you express affine type in D? In Rust affine type is very fundamental and we can utilize it to define the exact meaning of our programs. Can you provide a good example of affine types and how they help with expressiveness? My view of expressiveness in D does not stop at compile-time metaprogramming. For example, here's an excerpt from one of my programs: http://dump.thecybershadow.net/fb6c5a080c7a42ecd8d1f062b58a540d/000000CF.txt http://dump.thecybershadow.net/fb6c5a080c7a42ecd8d1f062b58a5... > How can a GC'ed language be faster than a non-GC'ed language? It is entirely plausible. For example, deallocation/destruction can run in a background thread, heap compaction removes heap fragmentation and improves cache locality, and of course throwing away all memory after the program is done executing is very practical if the program would otherwise do little deallocating overall. > Are you really sure D can outperform C in general cases? I don't know what's going on there, but "higher-level" languages outperforming C is not that uncommon, for example due to stricter aliasing rules or SIMD array vector operations, or simply due to language or standard library facilities being readily available (e.g. STL or associative arrays) which would be cumbersome or impractical to write/maintain in C versions.

yokohummer7 11y ago
> Can you provide a good example of affine types and how they help with expressiveness? For example, let's say there's an HTTP server handler that must send each header line first, and finally send a body. So you should: conn.send_header("HTTP/1.1 200 OK"); conn.send_header("Connection: Close"); conn.send_header("Content-type: text/html"); conn.send_body("Hello, world!"); In Rust, you can construct the API so that you cannot call `send_body` before any occurrences of `send_header`. So if you do: conn.send_body("I'm sent first!"); conn.send_header("Content-type: text/html"); you will get a compile error. This greatly reduces the risk of having incorrect logic in your program. In this case Rust helps ensuring our intention: `send_body` can only be the last call of the request handler. I consider this a good example of expressiveness of Rust (and affine types).

qznc 11y ago

> How can a GC'ed language be faster than a non-GC'ed language? Why should a GC'ed language be slower than a non-GC'ed language? The evidence [0,1,2] seems more like: Given enough memory, GC is faster. Non-GC means explicit deterministic free at specific points in the source code. A garbage collector has the freedom to delay the free, which means potential for optimization. [0] https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf [1] http://www.cs.princeton.edu/~appel/papers/cmljava.html http://www.cs.princeton.edu/~appel/papers/cmljava.html [2] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.1816 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.1...

pcwalton 11y ago
> The evidence [0,1,2] seems more like: Given enough memory, GC is faster. You really have to take Appel papers with a large grain of salt in 2015. Caches and multithreading have come to dominate nowadays, and assuming that all memory access is equal isn't reasonable. Also, the first paper doesn't make the claim that GC is faster than manual memory management—in fact, manual memory management was faster. > A garbage collector has the freedom to delay the free, which means potential for optimization. People commonly say this, but I don't see how a malloc couldn't do the same thing if it actually helped. Malloc implementations typically don't do delayed reclamation because it doesn't help; if it did help, they would do it. But cache is king, and prompt reuse of space is most important nowadays.