7 ms·

This can get downvoted to oblivion, but i fell for DLang first time i wrote a hobby raspberry pi gpio library. It just worked. It compiled without hassle. The

This can get downvoted to oblivion, but i fell for DLang first time i wrote a hobby raspberry pi gpio library. It just worked. It compiled without hassle. The language was easy to understand - i first read about a few days prior to writing my lib. I absolutely think this language should get more attention, and probably it should explore wasm a bit more. I know webdevs love easy to read languages and DLang is an ideal candidate for replacing javascript in the browser via wasm. All it needs is a nice package manager and a set of basic web libs to use in the browser - not the DOM kind of libs, but for large’ish tables and data manipulation, a bit of audio and video editing and perhaps webgl integration to showcase what it can do. /end of babbling

ironmagma 6y ago
I've heard before that there is a schism in the D community between two different options, but never can remember what it is. Something that fragments the ecosystem?
- mhh__ 6y ago
  There was a schism the best part of 15 years ago now.
- gmfawcett 6y ago
  You might mean the D1 vs. D2 schism. That was ages ago, it hasn't been a live issue for a very long time.
- deleted 6y ago
  [deleted]
- wk_end 6y ago
  IIRC there were two different standard libs at one point. I don't believe that's an issue anymore.
- scythe 6y ago
  D's biggest problem at this point is that everyone (including me) vaguely remembers that period where it was in limbo between different design strategies, and consequently frets: "is it stable yet?". Luckily, that seems to finally have reached a "yes!". Development continues, but nobody's getting the rug pulled out from under them anymore.
  - mhh__ 6y ago
    > finally That really arrived with Andrei Alexandrescu's book which was 10 years ago now.
    - ironmagma 6y ago
      I heard about this schism less than 5 years ago so there's probably some pages/blogs/talks that need to be updated.
      - mhh__ 6y ago
        It's mostly second hand commentary. HN is an outlier in that people have even heard of D, for some perspective.
- acehreli 6y ago
  I've been in the D community since 2009. There is no schism.
- lhorie 6y ago
  There were two stdlibs in D1 (the official one called phobos, and tango which had a more "java-like" feel). I haven't been following D for years, but it looks like Tango sort of died off when work on D2 started to get traction[0] [0] http://www.dsource.org/projects/tango/forums/topic/920 http://www.dsource.org/projects/tango/forums/topic/920
  - ironmagma 6y ago
    Thanks for that context. I wish that information was more obvious and well-documented since it seems like enough people still don’t know the details. D does seem useful and it’s something I want to pick up someday but had been holding off because that situation sounded so demotivating.
    - destructionator 6y ago
      What irks me is this stuff is all from before 2007 - that's when the runtime support lib branches were merged - yet social media comments make it sound like it is today. I'm a bit irked personally at people saying "D1" vs "D2" too. I use scare quotes because they actually came out at about the same time. There's only really one D language that's gone through a consistent evolutionary process. In January 2007, a "stable" branch was arbitrarily forked off the language. This was labeled "D 1.0". It wasn't exactly stable yet; it still got some new features and even some breaking changes applies to it from the dev branch, but most the more experimental stuff didn't get merged. In summer 2007 - mere months later - the "dev branch" got arbitrarily rebranded "D 2.0" There was nothing particularly special about that release, it didn't even have any real breaking changes. It was just slapped with a new label, but this was the ongoing evolution D has had since the beginning. A little while later, the dev branch, aka D2, did start getting some more major breaking changes, like the const and immutable system being added (at first nothing broke, but then the type of string literals was changed from char[] to immutable(char)[] and that was a fairly big change since strings are used everywhere), while the stable branch, aka D1, would start to get only bug fixes. People call this a "community split", but that's just not really how it happened. The stable branch was mostly maintained for a few corporate clients who didn't want to adapt to an array reallocation change in the runtime (despite general agreement the new way was better, they were just heavily invested in the old way and it would take some time to confirm their code wasn't adversely affected) while most everyone else embraced the ongoing evolution. There were a few years of kinda obnoxious churn - I remember being quite annoyed when the std.string tolower got renamed to toLower among other "consistency" updates - but like it really wasn't that big of a deal for most of us. I think it was a mistake to call it "D1". It should have probably just been something like "D extended support edition". But the name was what it was and online commenters continue to misrepresent what actually happened now, 14 years [!] (yikes i've been in the community a long time now) later.
Foomf 6y ago
D does have a package manager named dub, it works well. https://code.dlang.org/ https://code.dlang.org/
- moonchild 6y ago
  > it works well it ... works That's as much as I think can be said for it. Dub is garbage. It's too complicated, too rigid, and it does too little. It's also slow for larger projects because it doesn't do incremental builds.
  - vidugavia 6y ago
    Is the lack of incremental compilation aproblem with dub or with D compiler in general?
    - Doxin 6y ago
      It's a problem with dub. The D compiler operates basically exactly like a C compiler would as far as I'm aware. Note that in most cases an incremental build isn't really required for D because for moderately complex projects you're often limited by linking speed, not compiling speed.
    - p0nce 6y ago
      dub does incremental builds.
      - moonchild 6y ago
        On a per-file basis? Afaik it works with package granularity, so if you change one line of a package, you're SOL.
        p0nce 6y ago
        Per-package translation unit are faster than per-file translation units.
    - 6y ago
destructionator 6y ago
I like to write really basic little games to kill time. Stuck on a flight? Clone tetris or minesweeper or whatever. And of course I use D. Well, I wrote a version of my support library for those games for webassembly too and you can play some of them online! http://webassembly.arsdnet.net/ http://webassembly.arsdnet.net/ None of them are "finished" per se, I'd be on a strict time limit and just left it where it landed when I ran out, some not even really working, but there's some little playable chunks there. Tends to be 60KB or so of webasm, really not too bad (no need for the emscripten bloat etc since I did it all myself) It amuses me to compile the same program for Windows, Linux, and the browser without modification. (that's all I personally use webassembly for though, since I'm not a fan of SPAs...)
- brobdingnagians 6y ago
  That's really cool, thank you for sharing! It is neat to see a bit longer form D code in more than just sample tutorials.
Shadonototro 6y ago
i love D, i only wish story where non-gc is needed would improve (more allocator work, more gc free runtime etc) after trying zig, i also wish C interop was as smooth, but zig has advantage of shipping a clang compiler as library, D could do the same since they got LDC (with LLVM) i move between zig/rust and D; i'm happy to say that we can live in a world where we can totally ignore c++
- mhh__ 6y ago
  @nogc is growing, and memory safety will also be improving, just that we've basically reached end of what we can do before reaching the hard problems - we're definitely not stopping we just need to get any changes to the language right. Also remember that the GC is entirely written in D, it is possible.
- gmueckl 6y ago
  There's also Calypso, an LDC fork that can process C++ headers directly. It should in theory also work with C.
  - Shadonototro 6y ago
    why a fork, and not a PR to LDC? fragmentation is a bad thing in my opinion
    - mhh__ 6y ago
      Because merging an increasingly large subset of a c++ compiler into a compiler for a different language is a recipe for disaster if you're unlucky.
      - Shadonototro 6y ago
        I don't know how exactly things works, but zig approach is very nice, i wish it was possible with D too When i say available, i mean available out of the box
megameter 6y ago
One thing D does have in its favor over most of the competing alternatives is a fairly mature ecosystem story, with multiple implementations of the compiler, decent docs, libraries for common domains, and a lot of "use hours and eyeballs" on the project as a whole that have brought up and addressed obscure issues. While it has accumulated some more serious warts with time as the project goals have shifted in very large ways, D could be described as boring, useful, and mostly keeping up with the trends, which is a pretty decent place for a fundamental software development tool to be in. I'd be happy to use it again.
yarg 6y ago
If LLVM languages are going to become more mainstream in the browser, you need more than a WASM backend - you need to significantly improve interaction with the UI from WASM. HTML's canvas might be an adequate stop gap, but it really doesn't seem like an acceptable solution in the long term.
- spijdar 6y ago
  Wouldn't the ultimate irony be "native" toolkits like Gtk and Qt being normalized through WASM code rendering to a canvas?
  - MaxBarraclough 6y ago
    Qt already supports WASM, [0] but it's a long way from being 'web native'. [0] https://www.qt.io/qt-examples-for-webassembly https://www.qt.io/qt-examples-for-webassembly

ironmagma 6y ago

I've heard before that there is a schism in the D community between two different options, but never can remember what it is. Something that fragments the ecosystem?

mhh__ 6y ago
There was a schism the best part of 15 years ago now.
gmfawcett 6y ago
You might mean the D1 vs. D2 schism. That was ages ago, it hasn't been a live issue for a very long time.
deleted 6y ago
[deleted]
wk_end 6y ago
IIRC there were two different standard libs at one point. I don't believe that's an issue anymore.
scythe 6y ago
D's biggest problem at this point is that everyone (including me) vaguely remembers that period where it was in limbo between different design strategies, and consequently frets: "is it stable yet?". Luckily, that seems to finally have reached a "yes!". Development continues, but nobody's getting the rug pulled out from under them anymore.
- mhh__ 6y ago
  > finally That really arrived with Andrei Alexandrescu's book which was 10 years ago now.
  - ironmagma 6y ago
    I heard about this schism less than 5 years ago so there's probably some pages/blogs/talks that need to be updated.
    - mhh__ 6y ago
      It's mostly second hand commentary. HN is an outlier in that people have even heard of D, for some perspective.
acehreli 6y ago
I've been in the D community since 2009. There is no schism.
lhorie 6y ago
There were two stdlibs in D1 (the official one called phobos, and tango which had a more "java-like" feel). I haven't been following D for years, but it looks like Tango sort of died off when work on D2 started to get traction[0] [0] http://www.dsource.org/projects/tango/forums/topic/920 http://www.dsource.org/projects/tango/forums/topic/920
- ironmagma 6y ago
  Thanks for that context. I wish that information was more obvious and well-documented since it seems like enough people still don’t know the details. D does seem useful and it’s something I want to pick up someday but had been holding off because that situation sounded so demotivating.
  - destructionator 6y ago
    What irks me is this stuff is all from before 2007 - that's when the runtime support lib branches were merged - yet social media comments make it sound like it is today. I'm a bit irked personally at people saying "D1" vs "D2" too. I use scare quotes because they actually came out at about the same time. There's only really one D language that's gone through a consistent evolutionary process. In January 2007, a "stable" branch was arbitrarily forked off the language. This was labeled "D 1.0". It wasn't exactly stable yet; it still got some new features and even some breaking changes applies to it from the dev branch, but most the more experimental stuff didn't get merged. In summer 2007 - mere months later - the "dev branch" got arbitrarily rebranded "D 2.0" There was nothing particularly special about that release, it didn't even have any real breaking changes. It was just slapped with a new label, but this was the ongoing evolution D has had since the beginning. A little while later, the dev branch, aka D2, did start getting some more major breaking changes, like the const and immutable system being added (at first nothing broke, but then the type of string literals was changed from char[] to immutable(char)[] and that was a fairly big change since strings are used everywhere), while the stable branch, aka D1, would start to get only bug fixes. People call this a "community split", but that's just not really how it happened. The stable branch was mostly maintained for a few corporate clients who didn't want to adapt to an array reallocation change in the runtime (despite general agreement the new way was better, they were just heavily invested in the old way and it would take some time to confirm their code wasn't adversely affected) while most everyone else embraced the ongoing evolution. There were a few years of kinda obnoxious churn - I remember being quite annoyed when the std.string tolower got renamed to toLower among other "consistency" updates - but like it really wasn't that big of a deal for most of us. I think it was a mistake to call it "D1". It should have probably just been something like "D extended support edition". But the name was what it was and online commenters continue to misrepresent what actually happened now, 14 years [!] (yikes i've been in the community a long time now) later.

Foomf 6y ago

D does have a package manager named dub, it works well. https://code.dlang.org/ https://code.dlang.org/

moonchild 6y ago
> it works well it ... works That's as much as I think can be said for it. Dub is garbage. It's too complicated, too rigid, and it does too little. It's also slow for larger projects because it doesn't do incremental builds.
- vidugavia 6y ago
  Is the lack of incremental compilation aproblem with dub or with D compiler in general?
  - Doxin 6y ago
    It's a problem with dub. The D compiler operates basically exactly like a C compiler would as far as I'm aware. Note that in most cases an incremental build isn't really required for D because for moderately complex projects you're often limited by linking speed, not compiling speed.
  - p0nce 6y ago
    dub does incremental builds.
    - moonchild 6y ago
      On a per-file basis? Afaik it works with package granularity, so if you change one line of a package, you're SOL.
      - p0nce 6y ago
        Per-package translation unit are faster than per-file translation units.
  - 6y ago

destructionator 6y ago

I like to write really basic little games to kill time. Stuck on a flight? Clone tetris or minesweeper or whatever. And of course I use D. Well, I wrote a version of my support library for those games for webassembly too and you can play some of them online! http://webassembly.arsdnet.net/ http://webassembly.arsdnet.net/ None of them are "finished" per se, I'd be on a strict time limit and just left it where it landed when I ran out, some not even really working, but there's some little playable chunks there. Tends to be 60KB or so of webasm, really not too bad (no need for the emscripten bloat etc since I did it all myself) It amuses me to compile the same program for Windows, Linux, and the browser without modification. (that's all I personally use webassembly for though, since I'm not a fan of SPAs...)

brobdingnagians 6y ago
That's really cool, thank you for sharing! It is neat to see a bit longer form D code in more than just sample tutorials.

Shadonototro 6y ago

i love D, i only wish story where non-gc is needed would improve (more allocator work, more gc free runtime etc) after trying zig, i also wish C interop was as smooth, but zig has advantage of shipping a clang compiler as library, D could do the same since they got LDC (with LLVM) i move between zig/rust and D; i'm happy to say that we can live in a world where we can totally ignore c++

mhh__ 6y ago
@nogc is growing, and memory safety will also be improving, just that we've basically reached end of what we can do before reaching the hard problems - we're definitely not stopping we just need to get any changes to the language right. Also remember that the GC is entirely written in D, it is possible.
gmueckl 6y ago
There's also Calypso, an LDC fork that can process C++ headers directly. It should in theory also work with C.
- Shadonototro 6y ago
  why a fork, and not a PR to LDC? fragmentation is a bad thing in my opinion
  - mhh__ 6y ago
    Because merging an increasingly large subset of a c++ compiler into a compiler for a different language is a recipe for disaster if you're unlucky.
    - Shadonototro 6y ago
      I don't know how exactly things works, but zig approach is very nice, i wish it was possible with D too When i say available, i mean available out of the box

megameter 6y ago

One thing D does have in its favor over most of the competing alternatives is a fairly mature ecosystem story, with multiple implementations of the compiler, decent docs, libraries for common domains, and a lot of "use hours and eyeballs" on the project as a whole that have brought up and addressed obscure issues. While it has accumulated some more serious warts with time as the project goals have shifted in very large ways, D could be described as boring, useful, and mostly keeping up with the trends, which is a pretty decent place for a fundamental software development tool to be in. I'd be happy to use it again.

yarg 6y ago

If LLVM languages are going to become more mainstream in the browser, you need more than a WASM backend - you need to significantly improve interaction with the UI from WASM. HTML's canvas might be an adequate stop gap, but it really doesn't seem like an acceptable solution in the long term.

spijdar 6y ago
Wouldn't the ultimate irony be "native" toolkits like Gtk and Qt being normalized through WASM code rendering to a canvas?
- MaxBarraclough 6y ago
  Qt already supports WASM, [0] but it's a long way from being 'web native'. [0] https://www.qt.io/qt-examples-for-webassembly https://www.qt.io/qt-examples-for-webassembly