Re: A strategic vision for D
On Monday, 7 May 2018 at 10:27:32 UTC, Joakim wrote: On Saturday, 5 May 2018 at 04:59:58 UTC, germandiago wrote: On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote: [...] My 2 cents. I have been following D for a long time and started using it in a very small project. I am a very long term C++ user. [...] Interesting analysis. These are pretty much the points of technical and marketing emphasis today, so it appears the current message resonated with you. However, I was talking about more from the point of which markets D would target first, ie the types of end users who'd use D, whether game programmers or compiled GUI apps. So far D's gained some traction at startups that need performance. One issue with the current approach is that they seem to implicitly assume that D needs to match or surpass C and C++. Can't disagree with the betterC approach as that's really needed, but I'm not sure if D should want to be a better C++. Certainly app devs don't really care about @nogc and the current systems programming emphasis aimed at C++ devs like you. My point is that whatever that strategy is should be clearly articulated, or you may even undermine yourself by not thinking through carefully what your goals are. Great marketing beats great tech (sadly), but we are creatures subject to social influence and that which is shiny. Who actually runs marketing for Dlang? Is it the foundation, collective cooperation, or ? Does Dlang have what it needs to be successful in this category in terms of financial resources, expertise, and focus? As an aside, this was the original marketing for Node.js, in the years before it was acquired by Joyent: http://tinyclouds.org/ . In a single year, it caught fire (that is, it became wildly successful) because it had a strong BDFL (who was not a dictator, and who stepped down as soon as it made sense to do so, and he took on some messianic stature as a result), strong technical merits, a clear focused message of where it fit in the market, and it met a need. In fact, it met many more needs than intended, widely used in both cloud and embedded type applications. 8 years on from moving the project into the hands of a corporate sponsor, through much controversy over governance and some community strife, forks, etc., it's doing well in the hands of a foundation: https://foundation.nodejs.org/ . From a market focused perspective there is the technology itself in one bucket, and then there is the adoption by enterprise. Certain things have to happen for enterprise adoption to actually take place. If we follow the pattern of what happened for Go or Node.js, we can boil those down to execution of certain tangibles: - Project is well documented - Project is available under favorable OSS license (I won't get into what favorable means, but for corporations, they have their preferences) - Project has a good toolchain and tools support - Project has a good IDE integration - Project has good sample applications built, lots of good examples - Project has a strong and active community of developers with the appropriate mix of core contributors, external contributors, experts, casual users, and people evaluating possible use - Project has strong technical merits - Project has strong market differentiators (this may require real marketing to get this down on paper and promote this) - Project has commercial support available (training, bug fixing, development) - Project has an academic community (this often helps seed use in Universities), and students eventually grow up to work for enterprise corporations - Project has corporate sponsors (or foundation sponsors ... they are really representing corporations) - Project has a sustainable model (legal, financial) to maintain its community, engineering, and marketing. - Project has multiple big projects that rely upon it Grade Go, Rust, and Node.js on this list above. Where are they at on each item? Grade Dlang on this. We still have some work to do. What companies offer commercial support in D? Are there any Dlang focused agencies out there? How many projects are using Dlang commercially? Who are the corporate sponsors of Dlang? Again, I think much of this comes back to that marketing message. What is the unique selling proposition. Define that. Then conquer the world.
Re: D vs nim
On Friday, 10 April 2015 at 21:26:35 UTC, bachmeier wrote: On Friday, 10 April 2015 at 18:52:24 UTC, weaselcat wrote: The only things I've read about nim have been on the D forums - it seems the wikipedia article is even being considered for deletion due to not being noteworthy. So I think you might have trouble finding any comparisons. Read the comments sections on other languages on Reddit programming and you'll see their spam all over the place. I've never used Nim (and don't plan to because I've been turned off by their constant spamming of comment threads on Reddit) but the numerous comments I've seen repeatedly indicate that Nim is not yet ready for real use. This is a fair set of critiques as far as the spamming goes. The NIM project founder is sort of a one person show in development and promotion. I wouldn't say it is not ready for real (commercial) use without being objective, as you have to really characterize what those requirements are. If one considers commercial criteria to be something like: toolchain quality, IDE support, documentation, platform support, sustainable community, fair licensing terms, significant technical merits, actual adoption in the enterprise or research community, and commercial support available. I'd agree that if your graded NIM across these criteria, it doesn't score high. What impresses me about it are the technical merits, platform support, and its toolchain. Disclosure, I did actually use NIM before posting. I wrote a module called huenim which handles basic Philips HUE communication. I found the experience to be a mixed bag. I was impressed that the project lead of NIM was available to help me in my struggles around UPnP. But there just is not enough great documentation with sample code, at the level I like when I am picking up a new language. The syntax bothers me, but that's just my own issue with too many years of Java and C. Another thing that really impressed me was how easy it was to bootstrap the language on an ARM device, particularly AARCH64. The total runtime size is small as well. Would I use it for my company? Yes. Is there risk in doing this? Yes. Hard to recruit NIM coders. Hard to know what is the long term sustainability of the NIM community and project as a whole. I still would say that on the ready for "real" commercial use, D would get a much higher grade on more categories.
Re: D on AArch64 CPU
On Thursday, 10 August 2017 at 07:00:55 UTC, David J Kordsmeier wrote: On Wednesday, 9 August 2017 at 08:37:53 UTC, Johannes Pfau wrote: Iain recently updated GDC & phobos up to 2.074 and we have a pull request for 2.075. So don't worry about fixing old GDC phobos/druntime versions, recent gdc git branches should already have AArch64 phobos changes. We have a test runner for AArch and GDC master here: https://buildbot.dgnu.org/#/builders/2/builds/29 There are still some failing test suite tests though and AFAICS we currently don't build phobos on that CI at all. (We can run ARM/AArch tests without special hardware, thanks to QEMU's user mode emulation) -- Johannes Thanks both for the reply. I'll be interested to try both gdc and the ldc cross compiler options. BTW - I randomly decided to check on the latest status of builds today, to see if by chance AARCH64 is passing the buildbot tests run for GDC. Pleased to find, that actually as of four days ago, it is passing: https://buildbot.dgnu.org/#/builders/2/builds/45/steps/3/logs/stdio Looking forward to jumping back into D.
Re: D on AArch64 CPU
On Wednesday, 9 August 2017 at 08:37:53 UTC, Johannes Pfau wrote: Iain recently updated GDC & phobos up to 2.074 and we have a pull request for 2.075. So don't worry about fixing old GDC phobos/druntime versions, recent gdc git branches should already have AArch64 phobos changes. We have a test runner for AArch and GDC master here: https://buildbot.dgnu.org/#/builders/2/builds/29 There are still some failing test suite tests though and AFAICS we currently don't build phobos on that CI at all. (We can run ARM/AArch tests without special hardware, thanks to QEMU's user mode emulation) -- Johannes Thanks both for the reply. I'll be interested to try both gdc and the ldc cross compiler options.
Re: D on AArch64 CPU
On Sunday, 14 May 2017 at 15:05:08 UTC, Richard Delorme wrote: I recently bought the infamous Raspberry pi 3, which has got a cortex-a53 4 cores 1.2 Ghz CPU (Broadcom). After installing on it a 64 bit OS (a non official fedora 25), I was wondering if it was possible to install a D compiler on it. Richard, I would be interested in working through the GDC issues further with you if you haven't completely given up on this. I am surprised the response is that there is still no official support. I am struggling on nearly every project I have on aarch64 with really lagging support for a wide variety of software, mainly platform support in more complex builds that does not include aarch64, and clearly the compilers all need more core level work to bring up a language and programming toolchains in a new environment. I think Go, for example, isn't fully supported on aarch64, and Rust has the same issue. If you are still available, I would like to share notes on the GDC 6.3 work that you started, and see if we can work through the issues with the core team. I realize there is probably some lack of visibility into the interest that exists in the ARM-embedded area for D, but I've been using gdc on ARM since 2014. It has been reasonably good for me, however, with the migration of many device manufacturers to AARCH64, most notably the Raspi3 and all of the hordes of Android devices hitting the market, there is a substantial installed base. I can commit some hardware to builds also, and have some contacts in the industry around arm stuff, so it shouldn't be hard to find more dedicated gear if this helps teams like the GDC team who may not have access to gear to even run nightly builds. Honestly, I stopped using D when I ran into this issue, was hoping, as you, that "someone should fix this". However, that's not how good OSS works, and I'm willing to put some cycles on it if there is a way forward. At the time, I had to make some fast decisions and opted to rewrite my code base in C. I look forward to hearing from you and anyone else interested in working on/contributing to this topic. Also, why I don't look at LDC further, I think RAM on the embedded devices is still pretty skimpy, Raspi3 only has 1GB ram. It's not great for compiling with the LLVM-based things and probably run OOM. Other devices I have only have 512MB ram. So gcc is usually fine in these circumstances.
