3 ms·

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)

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.
      - teleforce 3y ago
        D is general purpose programming language similar to Python but most would agree that in computing sense it is more general than Python since the latter is rather limited in hardcore HPC domain (bit twiddling, etc). The fact that most of today's programmer or in the future will be just fine and better off with GC based languages compiled or interpreted, as modern drivers are better off with auto transmission than the manual. Heck, even F1 drivers now compete in auto transmission (DCT). The fact that D is embracing GC as a default is not a disadvantage but it is advantage for majority of the programmers [1]. Imagine a world in the near future where D is as popular as Python due to its intuitive syntax thus more library will be written for D and thus the library eco-system is flourishing regardless you are using enabled the GC or not with D [2]. Imagine a world where you don't need to write in Python and interface in a wrapper for library in foreign language that only selected few can understand because most of original library authors have passed away since the core are using language originated from the 50s and the library was developed in the 70s [3]. Imagine a world where only programming language with GC can be JIT to wasm [4]. [1]Go: What we got right, what we got wrong: https://news.ycombinator.com/item?id=38874952 https://news.ycombinator.com/item?id=38874952 [2]Stop Designing Languages. Write Libraries Instead: https://lbstanza.org/purpose_of_programming_languages.html https://lbstanza.org/purpose_of_programming_languages.html [3]Programming in Modern Fortran: https://cyber.dabamos.de/programming/modernfortran/blas.html https://cyber.dabamos.de/programming/modernfortran/blas.html [4] WebAssembly Garbage Collection (WasmGC) now enabled by default in Chrome: https://developer.chrome.com/blog/wasmgc https://developer.chrome.com/blog/wasmgc
    - nsajko 3y ago
      Julia depends on OpenBLAS by default, but faster pure-Julia packages are available, too.
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.

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.
    - teleforce 3y ago
      D is general purpose programming language similar to Python but most would agree that in computing sense it is more general than Python since the latter is rather limited in hardcore HPC domain (bit twiddling, etc). The fact that most of today's programmer or in the future will be just fine and better off with GC based languages compiled or interpreted, as modern drivers are better off with auto transmission than the manual. Heck, even F1 drivers now compete in auto transmission (DCT). The fact that D is embracing GC as a default is not a disadvantage but it is advantage for majority of the programmers [1]. Imagine a world in the near future where D is as popular as Python due to its intuitive syntax thus more library will be written for D and thus the library eco-system is flourishing regardless you are using enabled the GC or not with D [2]. Imagine a world where you don't need to write in Python and interface in a wrapper for library in foreign language that only selected few can understand because most of original library authors have passed away since the core are using language originated from the 50s and the library was developed in the 70s [3]. Imagine a world where only programming language with GC can be JIT to wasm [4]. [1]Go: What we got right, what we got wrong: https://news.ycombinator.com/item?id=38874952 https://news.ycombinator.com/item?id=38874952 [2]Stop Designing Languages. Write Libraries Instead: https://lbstanza.org/purpose_of_programming_languages.html https://lbstanza.org/purpose_of_programming_languages.html [3]Programming in Modern Fortran: https://cyber.dabamos.de/programming/modernfortran/blas.html https://cyber.dabamos.de/programming/modernfortran/blas.html [4] WebAssembly Garbage Collection (WasmGC) now enabled by default in Chrome: https://developer.chrome.com/blog/wasmgc https://developer.chrome.com/blog/wasmgc
  - nsajko 3y ago
    Julia depends on OpenBLAS by default, but faster pure-Julia packages are available, too.

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.