4 ms·

My suggestions: completely get rid of GC(use refcounts or borrowed pointers), add macros(see FreeBasic extensions of C macros), migrate everything complex/optio

My suggestions: completely get rid of GC(use refcounts or borrowed pointers), add macros(see FreeBasic extensions of C macros), migrate everything complex/optional out of stdlib to specific packages(Rust ecosystem is centered on packages not stdlib), and you will have a solid competitor to C++ and perhaps Rust. Rust of course has better macros and type system, but D looks simpler and more approachable for rapid prototyping/tinkering that will drive adoption.

teleforce 3y ago
Your suggestions are moving backward, and GC by default and no macro made D intuitive and Pythonic that are big plus in any modern programming language construct. The non GC is not really needed unless you're working on OS control primitives but again D give you alternative unlike Go. Every modern languages should avoid macro like a plaque otherwise you will sooner or later create a ghetto inside your community not unlike Ruby on Rails. C++ and Rust are complex languages and it's evident by their long compilation time, while Go and D are much simpler hence faster compilation time. D get many things right, and C++ and later languages like Nim have been copying D uniques features left and right since its introduction.
- countWSS 3y ago
  Then, D will compete with GC languages that outclass it in ecosystem diversity and metaprogramming.(i.e. it will remain same niche language it was for decades). Having a huge runtime with GC doesn't seem appealing or efficient.
  - teleforce 3y ago
    Fret not, Python just a fringe programming language for more than two decades, it only then become popular. If you have the right fundamentals success will eventually come your way.
    - WhereIsTheTruth 3y ago
      Python is a interpreted language, and is both strongly/dynamic typed D is a native strongly typed language You don't make game engines in Python, and certainty not drivers, python devs fall back to C when they need performance, this should give you a hint
      - teleforce 3y ago
        Sorry don't get your points, latest D compiler does support C native in addition to the much safer DasBetterC. D is even better you can do all things seamlessly in the same D ecosystem supported by GCC compiler suite by not even going to another language eco-system. Heck, D can be even be faster than Fortran and C++ for native HPC library seven years ago where Rust and Julia still revert to them for HPC routines until now [1]. [1]Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
        WhereIsTheTruth 3y ago
        Exactly, you achieve this by not embracing the GC, wich is not what this fork wants to do.. And Python's selling point isn't the fact that it has a GC, it's its interpreted/dynamic nature D is pragmatic about memory allocation strategy, this fork won't be
        bachmeier 3y ago
        > D is pragmatic about memory allocation strategy, this fork won't be Better than a pragmatic approach to memory allocation is to not have to think about it at all. For many applications, you can use the GC and not even know anything about memory allocation. If you embrace the GC, you make a lot more progress, since you can add things to the standard library and the language quickly and easily. Users not wanting a GC should use something else. Catering to users that don't want a GC imposes a big tax on everything and everyone. Embracing the GC doesn't mean they're going to strip out the reference counting and unique pointers already in the standard library.
  - mhd 3y ago
    Is the field of competition so ripe here? I'm seeing Go, but what else? It seems a lot of the other languages: - don't have an easy compilation story (interpreted, VM, compilers as secondary implementations) - lean more on the functional side (Ocaml, Haskell) - otherwise clash with the common BCPL-family mindset (Oberon, arguably Go) There definitely seems room for an "easier C++". Heck, given how popular Rust is due to backing and support from the functional crowd, leaning into ease of use and imperative programming might be a sufficiently large niche.
- WhereIsTheTruth 3y ago
  If you don't have state of the art GC, it's a burden to have in your language since it'll cripple performance, GC pausing threads, collection becoming slower as your heap grows and memory fragmentation for example D doesn't have state of the art GC, it perhaps should focus on its strengths, being a better C/C++ and embrace the concept of allocators https://dlang.org/phobos/std_experimental_allocator.html https://dlang.org/phobos/std_experimental_allocator.html To me D shine with its -betterC mode, it completely strip the runtime, giving you a great low level language to work with, a great better C/C++, I would have quit D a long time ago if it didn't have this compiler flag
  - WalterBright 3y ago
    One unexpected benefit of GC is it makes compile time function execution easy to write code for. The use of the GC there does not transfer to the runtime. Removal of the GC makes for CTFE code becoming much klunkier. One can see this in betterC mode - the GC is allowed for CTFE code.
- otabdeveloper4 3y ago
  > intuitive and Pythonic "Pythonic" hasn't been "intuitive" for 15 years now. Even old-school Perl is more cohesive and coherent than modern Python.
  - teleforce 3y ago
    Yeah that is why Python popularity is on the downward trend and Perl is the opposite /s
    - otabdeveloper4 3y ago
      Or perhaps "intuitive" and "pythonic" was never Python's biggest selling point.

teleforce 3y ago

Your suggestions are moving backward, and GC by default and no macro made D intuitive and Pythonic that are big plus in any modern programming language construct. The non GC is not really needed unless you're working on OS control primitives but again D give you alternative unlike Go. Every modern languages should avoid macro like a plaque otherwise you will sooner or later create a ghetto inside your community not unlike Ruby on Rails. C++ and Rust are complex languages and it's evident by their long compilation time, while Go and D are much simpler hence faster compilation time. D get many things right, and C++ and later languages like Nim have been copying D uniques features left and right since its introduction.

countWSS 3y ago
Then, D will compete with GC languages that outclass it in ecosystem diversity and metaprogramming.(i.e. it will remain same niche language it was for decades). Having a huge runtime with GC doesn't seem appealing or efficient.
- teleforce 3y ago
  Fret not, Python just a fringe programming language for more than two decades, it only then become popular. If you have the right fundamentals success will eventually come your way.
  - WhereIsTheTruth 3y ago
    Python is a interpreted language, and is both strongly/dynamic typed D is a native strongly typed language You don't make game engines in Python, and certainty not drivers, python devs fall back to C when they need performance, this should give you a hint
    - teleforce 3y ago
      Sorry don't get your points, latest D compiler does support C native in addition to the much safer DasBetterC. D is even better you can do all things seamlessly in the same D ecosystem supported by GCC compiler suite by not even going to another language eco-system. Heck, D can be even be faster than Fortran and C++ for native HPC library seven years ago where Rust and Julia still revert to them for HPC routines until now [1]. [1]Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen: http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
      - WhereIsTheTruth 3y ago
        Exactly, you achieve this by not embracing the GC, wich is not what this fork wants to do.. And Python's selling point isn't the fact that it has a GC, it's its interpreted/dynamic nature D is pragmatic about memory allocation strategy, this fork won't be
        bachmeier 3y ago
        > D is pragmatic about memory allocation strategy, this fork won't be Better than a pragmatic approach to memory allocation is to not have to think about it at all. For many applications, you can use the GC and not even know anything about memory allocation. If you embrace the GC, you make a lot more progress, since you can add things to the standard library and the language quickly and easily. Users not wanting a GC should use something else. Catering to users that don't want a GC imposes a big tax on everything and everyone. Embracing the GC doesn't mean they're going to strip out the reference counting and unique pointers already in the standard library.
- mhd 3y ago
  Is the field of competition so ripe here? I'm seeing Go, but what else? It seems a lot of the other languages: - don't have an easy compilation story (interpreted, VM, compilers as secondary implementations) - lean more on the functional side (Ocaml, Haskell) - otherwise clash with the common BCPL-family mindset (Oberon, arguably Go) There definitely seems room for an "easier C++". Heck, given how popular Rust is due to backing and support from the functional crowd, leaning into ease of use and imperative programming might be a sufficiently large niche.
WhereIsTheTruth 3y ago
If you don't have state of the art GC, it's a burden to have in your language since it'll cripple performance, GC pausing threads, collection becoming slower as your heap grows and memory fragmentation for example D doesn't have state of the art GC, it perhaps should focus on its strengths, being a better C/C++ and embrace the concept of allocators https://dlang.org/phobos/std_experimental_allocator.html https://dlang.org/phobos/std_experimental_allocator.html To me D shine with its -betterC mode, it completely strip the runtime, giving you a great low level language to work with, a great better C/C++, I would have quit D a long time ago if it didn't have this compiler flag
- WalterBright 3y ago
  One unexpected benefit of GC is it makes compile time function execution easy to write code for. The use of the GC there does not transfer to the runtime. Removal of the GC makes for CTFE code becoming much klunkier. One can see this in betterC mode - the GC is allowed for CTFE code.
otabdeveloper4 3y ago
> intuitive and Pythonic "Pythonic" hasn't been "intuitive" for 15 years now. Even old-school Perl is more cohesive and coherent than modern Python.
- teleforce 3y ago
  Yeah that is why Python popularity is on the downward trend and Perl is the opposite /s
  - otabdeveloper4 3y ago
    Or perhaps "intuitive" and "pythonic" was never Python's biggest selling point.