3 ms·

Has the whole 2-library thing been fixed? Years ago when I got into it, it got really confusing and unsexy.

by keyle 4y ago

silisili 4y ago
Same. I really respect Walter, liked the language, but the tiny community seemed fractured already and a future unclear. Will definitely revisit when things settle.
- mhh__ 4y ago
  The Phobos/Tango thing has literally been settled for basically 10 to 13 years now. Beyond that D is a good language for writing software in. all language communities have fractures unless the language attracts lots of either new or bad programmers who haven't formed opinions yet
- 1980phipsi 4y ago
  Things settle? Sheesh
p0nce 4y ago
Yes it has been fixed since 10 years.
generichuman 4y ago
> Has the whole 2-library thing been fixed? If you're talking about the whole Tango/Phobos (2 std libs) thing, it's fixed and Phobos won. But now there are optional function attributes such as @nogc (checks that the code doesn't trigger the GC), @safe (memory safety checks) and nothrow that's causing a bit of a problem. For example, not all libraries are @nogc. So if you want to use some library in your @nogc code and the library is not marked as @nogc, you can't use that library. This is not as bad as the two standard libraries problem but it restricts the libraries you can use. The attributes are optional like I said, you can just ignore them and write code that uses the GC (not @nogc), code that is not explicitly checked by compiler for memory safety (not @safe) and code that throws exceptions (not nothrow). Of course this is sort of expected in multi-paradigm languages, like some people disable C++ exceptions. But in D's case it feels like the compiler and library developers' efforts are spread thin.
- mhh__ 4y ago
  The main issue with the nogc and nothrow flags is people taking a feature designed for careful consideration, and using them for building from-scratch code with often no philosophy other than a vague and usually completely unfounded mental model where GC == slow. Write the code first then measure it.
  - generichuman 4y ago
    Agreed and I actually don't really care about the GC speed. I mostly use arenas / object pools and you can do that with or without GC. Sort of undecided on the exceptions though. The Result / Option type in Rust is pretty nice to use (and !?*T in Zig, which is nicer if you ask me). It forces you to handle exceptions explicitly which is pretty nice and you can be sure there is no overhead introduced by the compiler for handling exception stuff. I'd probably wrap all the exception throwing functions in my D codebases with Result type if we had language level support for sum types and match syntax. I know we have it in the standard library, I want it in the language with nicer syntax. I also want the GC to be replaced with deterministic destruction using RC + ownership analysis and optimizations like Lobster does, but that's wishful thinking territory.
    - mhh__ 4y ago
      Even if it's small, the Option/Result style exceptions always have overhead in at least a limiting case whereas the unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky.
      - generichuman 4y ago
        > unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky. D doesn't return values when an exception is thrown as far as I know. How are exceptions' costs are paid by tricky implementation? I thought exceptions require allocation and run-time type info and therefore always introduce some cost (this goes for D and C++). I guess returning values and allocating error strings statically can help with that (or maybe allocate some exception buffer on program start -- but that's technically "overhead"). Am I wrong, or missing some important context related to exceptions?

Has the whole 2-library thing been fixed? Years ago when I got into it, it got really confusing and unsexy.

by keyle 4y ago

Has the whole 2-library thing been fixed? Years ago when I got into it, it got really confusing and unsexy.

Same. I really respect Walter, liked the language, but the tiny community seemed fractured already and a future unclear. Will definitely revisit when things settle.

mhh__ 4y ago
The Phobos/Tango thing has literally been settled for basically 10 to 13 years now. Beyond that D is a good language for writing software in. all language communities have fractures unless the language attracts lots of either new or bad programmers who haven't formed opinions yet
1980phipsi 4y ago
Things settle? Sheesh

p0nce 4y ago

Yes it has been fixed since 10 years.

generichuman 4y ago

> Has the whole 2-library thing been fixed? If you're talking about the whole Tango/Phobos (2 std libs) thing, it's fixed and Phobos won. But now there are optional function attributes such as @nogc (checks that the code doesn't trigger the GC), @safe (memory safety checks) and nothrow that's causing a bit of a problem. For example, not all libraries are @nogc. So if you want to use some library in your @nogc code and the library is not marked as @nogc, you can't use that library. This is not as bad as the two standard libraries problem but it restricts the libraries you can use. The attributes are optional like I said, you can just ignore them and write code that uses the GC (not @nogc), code that is not explicitly checked by compiler for memory safety (not @safe) and code that throws exceptions (not nothrow). Of course this is sort of expected in multi-paradigm languages, like some people disable C++ exceptions. But in D's case it feels like the compiler and library developers' efforts are spread thin.

mhh__ 4y ago
The main issue with the nogc and nothrow flags is people taking a feature designed for careful consideration, and using them for building from-scratch code with often no philosophy other than a vague and usually completely unfounded mental model where GC == slow. Write the code first then measure it.
- generichuman 4y ago
  Agreed and I actually don't really care about the GC speed. I mostly use arenas / object pools and you can do that with or without GC. Sort of undecided on the exceptions though. The Result / Option type in Rust is pretty nice to use (and !?*T in Zig, which is nicer if you ask me). It forces you to handle exceptions explicitly which is pretty nice and you can be sure there is no overhead introduced by the compiler for handling exception stuff. I'd probably wrap all the exception throwing functions in my D codebases with Result type if we had language level support for sum types and match syntax. I know we have it in the standard library, I want it in the language with nicer syntax. I also want the GC to be replaced with deterministic destruction using RC + ownership analysis and optimizations like Lobster does, but that's wishful thinking territory.
  - mhh__ 4y ago
    Even if it's small, the Option/Result style exceptions always have overhead in at least a limiting case whereas the unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky.
    - generichuman 4y ago
      > unwinding style exceptions are basically zero cost with a modern compiler - the debt is paid in the implementation being tricky. D doesn't return values when an exception is thrown as far as I know. How are exceptions' costs are paid by tricky implementation? I thought exceptions require allocation and run-time type info and therefore always introduce some cost (this goes for D and C++). I guess returning values and allocating error strings statically can help with that (or maybe allocate some exception buffer on program start -- but that's technically "overhead"). Am I wrong, or missing some important context related to exceptions?