Congrats to D / Vibe-D -- techempower Round 15
https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json D is finally showing up in the upper and middle parts of the tests. In some tests Vibe-D ( with LDC ) is showing a 10 to 80 times improvement compared to Round 14 ( where D was stuck at the bottom of the tests ). Plain Text: Round 15: vibed-ldc..1,200,034 Round 15: vibed987,534 Round 14: vibed-ldc 15,342 Round 14: vibed.10,657 Json: Round 15: vibed...206,136 Round 15: vibed-ldc...126,668 Round 14: vibed-ldc11,813 Round 14: vibed.8,415 It does not need to be negative postings all the time. Now a smart person might use this data and analyse it into a blog, hint hint ...
Re: A betterC base
On Friday, 9 February 2018 at 00:08:56 UTC, Adam D. Ruppe wrote: On Thursday, 8 February 2018 at 23:50:29 UTC, Ali wrote: But D, unlike many other languages, promotes itself as primarily a system programming language I think that's a mistake too. I'd rebrand it as a "general purpose" programming language. One language you can use everywhere. It worked for node.js and electron... Plenty of "general purpose" programming languages. The issue being that very few offer classes, no GC, easy syntax, good tooling and editor support, ... I noticed a trend with languages with so many going to functional programming or semi-class based. From the outside D looks good but there are so many strange things in the D design, that just infuriate. - GC ... sure, if only it did not allocate so much on startup. It makes any other languages look better, by simply having a lower memory footprint on first comparison. C 0.1MB, C++ 0.2MB, Rust 0.4MB, D 1.4MB, ... Looks inefficient when its simply the whole 1MB allocation. But perception matters! - import ... really, we are 2018 and people are still wasting our time to have standard libraries as imports. Its even more fun when you split, only to need import the array library. Look how ridiculous C++ like "import std.algorithm, std.conv, std.functional, std.math, std.regex, std.stdio;" some of the example on the front page look like. I see people on Reddit sh*t all over PHP all the time and yet, its so darn easy and comfortable to not think about writing import all over the code, just to get default functionality!! Reddit is full of people who love to hate languages that simply work. - Tooling. I will say it again and again until i die, it simply sucks for Windows users. How fun is it to see dcd-server taking up between 90 to 120MB and seeing 10, 12, 15 instances loading into memory eating away 2GB memory. Or seeing VSC work with some of the plugins for 5 minutes and then break again, forcing you to constantly restart VSC. Or how competing languages seem to provide more cleaner and better working plugins, with cleaner tool tips ( source documentation ) - Even the example on the front page are so typical "scare away the newbies". It looks like a cleaner version of C++. D has always been a love/hate relationship for me. One can see the work that has gone into it but it feels like a Frankenstein's monster. Small details, big details, the lack of clear focus. BetterC just moves resources away from actually implementing a permanent solution. Instead of maintain one system, you deal with two. While default D still deals with regressions and issue, BetterC being incomplete is pushed as the next big thing. The library has design choices that date back a long time and nobody dares to touch. The whole constant GC debate is linked to those design choices. D can do a lot but the layer between both is so thin that at times you wonder if your dealing with compile or runtime features. CTFE or not. Talking about CTFE .. Stephan vanished for a long time busy with work and yet it feels reading the topics that very few people noticed him missing, despite working a year on the whole new CTFE engine. Not exactly motivating for people. I can talk until i turn blue. I already wrote "a wall of text" as some say, in the Go topic and that was not even technical issues. People talk about the need for a clear design focus, leadership and ... things go on as before. That is D in a nutshell. People doing what they want, whenever and things stay the same. New features ( that is always fun ), a few people doing to grunt work and all the rest comes down to people complaining because they see no reason to put effort into D, as it feels like a wast of time. << want to bet that this is the only thing people will quote, instead of the rest. But on-topic again: No GC, yay. Always a win because it makes a language stand out. Possible for D. NO! Too much design choices that limit the language. Another D3 rewrite will simply kill D. D is so tiring. Its the main reason for going with Go, simply tired of waiting. In this one+ year time watching D, i have seen blogs, betterC half finished being promoted when D is already overloaded with features and has already a higher learning curve. More regressions and bug fix releases because the new features keep breaking stuff. Some more examples on the front pages. Some nice external packages that only limited amount of people care about. And very few things to improving the issues people mentioned the year before and the year before and the year before. So again, why do people need to bother? The momentum D build up in 2016, seem to according tiobe really lost. I remember D hitting (23) 1% a year ago, now its ranking (29) 0.5%. Great another wall of text at 2.50 in the morning. Frankly, i can write a book about D issues, justified or not. It will probably read like gibberish a
My choice to pick Go over D ( and Rust ), mostly non-technical
First of all, please do not repost this on Reddit or any other forum. This is focused for the D community alone to help deal with internal issues and it does not need to be ridiculed as this is a personal opinion. As some have seen my posting in the past week regarding D, i like to explain my reasoning. I have been looking for the language to use for my next project, one of them was D. But the choice was more or less between Rust, D and Go. As all 3 offered good multi-platform support ( essential ), fast, low memory usage. It came down to a list of criteria. I will mostly focus on D and Go as mentioning Rust too much will simply sidetrack the post too much. HTTP: D has no default HTTP server. So you need to rely on vibe.d. Vibe.d being a external package that then relies on a few people to maintain it. D has no future proof HTTP. There is currently no official http2 build in to vibe.d. Test branches do not count ;) Go is the only one in the short-list that has a default HTTP solution that is well tested by loads of people, is fast ( especially with pre-fork ) and future proof. Performance: When it comes down to anything HTTP related unfortunately D is lagging behind on this part. Especially vibe.d www.techempower.com/benchmarks/previews/round15. The techempower is just as example. My own tests show the same performance issues where D at minimum to a un-preforked Go loses over 30% in real life, network tested benchmarks ( not some silly local device benchmarks that most people do ). It also shows D has a higher CPU usage for the relative lower performance. Pre-forking Go increases the CPU usage but also performance. All of my own tests are done with LDC ( optimized flags ) not DMD. Sure, benchmarks are the devils breath but it makes no sense building a application that even with database queries are slow compared to the rest. Build: DMD is fast, no doubt about it but Go is just instant in my case for the same type of content i need ( Go HTTP vs D vibe.d ). Other issues in my past with D also did not help, namely the regressions and constant bug-fix releases. Its time for D to figure out a stable API. Its really bad when one compiles editor plugin code and sees "deprecated function" all over the output. How up to date is the https://dlang.org/deprecate.html even? Community / Code examples: D has a nice community here on the forum but out in the real world "the internet" D is more or less non existing. Google searches end up so many times back to this forum with a LOT of outdated code going back 5+ years, what does not work anymore as API changes happened. The fact that a lot of code out there is old or non functional is a issue. Worse when 80% of the search results end up in this forum, showing that D does not have a very broad community. I do not deny that D is used by some big companies as a C++ replacement but the impression is that those are mostly closed source projects where very few code surfaces on the web. Package support: Again ... D has very few packages and a LOT of them are frankly so old that they do not work properly anymore with the current DMD versions. Deprecated functions galore. If D had 1195 active, well supported high quality packages but it has not. Most packages at best have one decent package and that is it. You want to produce PDFs? fpdf 2015-Apr-06, a very limited PDF generation tool last updated 3 years go. You want to produce Excel's? Excel-d but it faces the same issue as being the only native project. What if the author ... GRPC? Imap? ... As i post this code.dlang.org is down so no more comparing. *sigh* https://github.com/avelino/awesome-go https://github.com/zhaopuming/awesome-d < missing Excel-d Just looking on Github for D vs Go packages. 323 vs 15,351 (dlang vs golang) ... This is again related to popularity and community. So there is much more chance for finding something exotic as a base project in Go then ever in D. Windows support: But unlike D, Go's Windows support is simply better. Plugins work out of the box with VSC. It has its own Jetbrain IDE. Is Go perfect, no... Dealing with Gopath is stupid. Who's idiotic idea that was instead of managing simply by project location. Its no fun dealing with the Go Sqlite plugin ( what is 3th party ) on Windows but then your are in actual production doing something, not fighting D to get your IDE working. Or fighting dub versions when LDC and DMD are both installed and in the environment path. The amount of strange issues, not bugs or cross platform support issue that crosses D Windows users, simply leaves a bad taste. Windows / Community issues: From a persona point of view, its tiring with some people looking down on the fact that i use Windows and have true issues related to D. That have been reported and helped fix but its a never ending stream of fixing one thing, running into another. Currently n
Re: Quora: Why hasn't D started to replace C++?
On Thursday, 1 February 2018 at 15:47:50 UTC, Russel Winder wrote: For me: aptitude install ldc aptitude install gdc aptitude install dmd-bin aptitude install dub Seems to work fine, and no conflicts. […] Please try Windows and then come back ;)
Re: Quora: Why hasn't D started to replace C++?
On Thursday, 1 February 2018 at 11:21:37 UTC, Russel Winder wrote: D should be proud of having a reference compiler, a GCC-based one, and an LLVM-based one. This is a Good Thing™, let no-one undermine this. Nothing wrong with choice as long as that choice does not introduces issues. Currently there are 3 compilers but also 3 different ways to install ( depending on the platform ). DMD has a installer, LDC needs a manual copy job + path creation, GDC did not even bother with ( sorry ). Let alone 'conflicts': Example: Install DMD ( what has its own DUB ) but also install LDC ( what has its own DUB), now lets say both version have different dub versions. Yes, this happened to me and it conflicted with some of the Editor plugins their build process because the wrong "version" of dub got selected during the build process. Its not really a bug but a issue that can trip people ( lost a hour on that one ). Other issues can be that it makes conversations difficult. When new people read DMD, LDC, GDC in these forums, you can just as well be speaking Mandarin ( Chinese ). Suggestion: Is it maybe not better to have one "front-end" compiler visible that people download Example: D run main.d D run main.d --compiler ldc ( not installed? Auto download and compile using dub ) D run main.d --compiler ldc --options -o3 D run main.d --compiler gdc ( not installed? Auto ...) D package install web-d Seen this layout with a some other compilers where everything is clean integrated. - Compiler ( default ) -- Run -- Test - Package -- Install -- Remove -- Update - Tools --- Format --- Check - Language server? No dub, no ldc, gdc, no confusion, just one clean interface. What happens behind the interface is nobody there business. It just presents better. Dub already does half this work with the compiler option but its a package manager not the "face of D". Hard to explain... Anyway, too much off-topic?
Re: Quora: Why hasn't D started to replace C++?
On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote: Here's a spoiler: 1) Andrei does an excellent job at managing his students [1] and there work over the last couple of months has been tremendous. As the experiment with UPB was very successful, there will be more projects like this one and global scholarship 2) The vision document will finally get updated (there have been a few delays due to holiday, illnesses etc.) https://wiki.dlang.org/Vision/2017H2 3) More community input (I'm preparing a State of D survey atm) 4) More active voting by the community on important issues 5) Better documentation and overview on what the foundation is doing Currently under discussion/work: 6) Using OpenCollective for tracking expenses openly 7) Offering membership packages for companies 8) Doing bi-annual Kickstarter compaigns for important issues to the community (e.g. "fix shared") Thank you Seb and the other. Sorry for going off the rails but i do like D a lot. Its the only reason i keep coming back for the same punishment time and time again. It simply gets so frustrating at times what feels like running into a stone wall. Maybe the real issue is not the issues that need to be solved but the lack of "news". The blogs are very interesting and i applaud them. But is it maybe not time to have a real news section on the site where project status updates are provided. We are not talking blogs but smaller news snipes that do not take a lot of time, so people who do not spend there life on the forum or other locations feel like there is indeed movement. It can also help in the actual marketing.
Re: Quora: Why hasn't D started to replace C++?
On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote: Let me say this again *uch* Never mind this rant. I am just fed up with the issues. I will not post anymore as its just a wast of time for everybody involved.
Re: Quora: Why hasn't D started to replace C++?
On Wednesday, 31 January 2018 at 07:56:37 UTC, Andrew Benton wrote: If I had to pick a second issue, it's that the ecosystem story is hard compared to other languages. New programmers aren't certain what to choose or how to get their environment up and running. Compared against Rust, Go, and Java we have horrible ecosystem fragmentation. E.g. three compilers, two separate languages for dub * three compilers And 3 different installation method's depending on the platform. Windows: DMD installer, LDC manually extract zip and setup path, GDC ... Now not all platforms are better. Go with its default compiler and cGo are also two different beasts. But both perform in regards to performance close to the point that you can rely on the main compiler as production compiler. The same can not be said about DMD and LDC where the performance differences can be huge. Let me add a few other issues to your list: * Library Auto generated libraries where all functions are dumped into massive one pagers. https://dlang.org/phobos/std_datetime_date.html Is this readable when the first two pages are this: jan feb mar apr may jun jul aug sep oct nov dec sun mon tue wed thu fri sat Const "jump to" lists intermixed between the documentation. No clear function calls: const pure nothrow @nogc @property @safe ubyte daysInMonth(); Const Pure nothrow @nogc @property @safe ubyte ... and FINALLY the actual function call your looking for: daysInMonth(); Now the question becomes without looking at the example!!! Is this part of Date, Datetime, ... You can not tell because the way you jump to page anchors and with a bit of scrolling, you lose where you are. Everything Date belongs into a Date Subpage with a method/function Index page. And that method/function Index page links to separated pages for EACH method. You know the extra advantage: It makes finding information from a search engine like Google way more easy and less clutter / clean. No issue for people who read this manual hundred of times or know the function calls from there head. But it just ugly and unclean. .. The real problem is that anybody can find 100's of issues that are simply unproductive or make the language look like a mess. And they get reported all the time but there is nobody to work on them. When the company line is: Do it yourself or pay somebody to do it. Guess what the first reaction of a lot of people is. *miep* *miep* *snooof* ... and you hear nothing from them anymore. A few may struggle, get into arguments and then they give up. And the rest simply complains about trolls who come to complain all the time and do not do the work. D is highly individualized as a language with actually very little corporation between the 100's of project, that get abandoned when the only developer runs out of time or moves to a differed language. I put a lot of money in several FOSS projects and it always feel like trowing money into a bottomless pit. Very few projects show where there money is being spend, let me correct that, not a single FOSS project where i put money into has every published where the money really gets spend. The closed that i ever got was Crystal where Manas.tech gives a yearly report of there time spend, money intake, ... https://crystal-lang.org/2017/12/19/this-is-not-a-new-years-resolution.html Its the core issue with D. * Why replace C++ with D when C++ does all the same with just a bit more effort but in exchange you get access to way more community, development, tools, support. * Why replace Rust with D when Rust is more actively developed, has better tooling support, focuses on drawing in new people, has key selling points that its drones keep repeating over and over again. * Why replace any language with D... We can talk until we turn blue and wast ages discussing the issues. But very few outsiders will put in the voluntary effort on a language where most doubt its future. That includes me ( and i know people will jump on this as being a troll comment ). There is a reason why i am focusing on learning Rust for my next project and not D. Despite Rust its more complex designs, its the whole package that is simply better organised. And do not take this that i am a rust troll. While yes, D gets used by some big companies on specific projects, the reality is that this seems to stem more from one developer in that company using D and not a real interest to use it company wide. D simply has too few people, no real goal, is a mishmash of different people with mostly individualized goals, a lacking and unclear foundation, lacking in paid developers. In simple terms, what D accomplished in 20 years time, is being overturned C++ taking the same features, Rust developing at a very fast rate, Swift same, Go same ... and with a mass of choice to people, if one does not stand out. This really remind me of a Knight Ta
Re: How programmers transition between languages
On Tuesday, 30 January 2018 at 11:55:42 UTC, rjframe wrote: - I click "Browse All Crates"; the default sort is alphabetical - not useful unless I'm just browsing, Right side: * Alphabetical * All-Time Downloads * Recent Downloads even then I'd likely want to browse by category. https://crates.io/categories Each project takes up too much space (it looks like something's missing on each project), but I like the links to the project's homepage/repo/docs being right there in the list. - I don't see any sort of categories/tags to organize projects. https://crates.io/categories I guess I have to know what I'm looking for and use the right search term. - Overall, I have the impression that it was designed to look good, but less effort has gone into what people will want to do with it in the first place (assuming I can consider myself normal for a moment). Dub doesn't look so nice, but it's efficient; I could see me searching Cargo for something and not finding it; True... but both dub and cargo are not exactly the pinnacle in user friendly and informative packages websites. I've never thought that about Dub (granted, far fewer packages) or Pypi. 1,193 packages found 13,605 Crates in stock Side note: End of 2016, this was 1400. If you consider 12 times "far fewer packages". The issue is that a lot of D's packages are even less maintained then Rust, mostly because Rust being newer and attracting more active crowds. And it does not help when Dmd having constant deprecating functions and regressions ( what happens WAY too often ) that break packages. Its a long term weakness. Depending on 3th party packages is always dangerous but even more so when the compiler forces people to use older versions, just to stay safe.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Saturday, 27 January 2018 at 22:58:27 UTC, H. S. Teoh wrote: I never said we should not offer good IDE support, in fact I said that we *need* good IDE support. But that in no way justifies the wrong claim that you can't be productive without an IDE. In fact, I find myself *more* productive without needing a memory-hogging, CPU-hogging GUI program that requires taking my hands off the keyboard all the time, just to edit code. But I'm sure you think the same about Vim/Emacs, so we're square. :-) The problem is Teoh that learning a language in Vim or a IDE are two totally different things. I used to program in Notepad because i grew up with PHP and knew it like the back of my hand. The result was very little need to see the documentation. The moment i found PHPStorm, i fell in love. Fast function jumping, remote tools, database at your fingertips, code checkers and hinters and all the other niceties. But for anybody who is not a master of a language or even intermediate, a good IDE can make one so much more productive compared to the same person just relying on a default notepad type environment. The fact that a good IDE expands the methods from a class, it shows you the basic help / buildup of the methods calls so you know exactly where you write what, without the need to visit the developers documentation website. It massif increases the adoption rate of a language, when your new to a language or not a 10 year expert. And for the people who are used to a language, a IDE can still be useful by increasing productivity as you simply do ... example "fu" ... enter ... "function " or automated braked closing, or error indicators when you forget something so you do not wast your time discovering a stupid issue during compilation. Its the same issue i personally have with languages that get lazy and trow out readability in exchange for less keystrokes. You can at times tell what development ides a language uses simply by looking at the language. Everything awkwardly shortcut like "fn" and other shorthand ( but what do make it much more brain taxing for anybody new ). Advanced programmers have the skills to make new languages, unlike beginner programmers but they also are so used to a specific environment that they build up to speed up, over the year, that they assume that everybody else can get going just as fast as they are. As a side note, despite working years in Vim, i still prefer a normal but well equip IDE because there are just some things VIM is not good at ( unless you customize it to hell with 100's of plugins what tends to take years to find your sweet spot and build up the know how to use them all perfectly ). VIM with all the plugins is simply a IDE, just one where you do not move your hands too much away from the keyboard. As your example of your colleagues: a IDE where it takes ages to jump to a definition in a file, is simply a incomplete IDE. Or maybe those colleges have not master the IDE. I know for a fact from myself that there is a massive amount of things still "hiding" in Jetbrain there products or Visual Studio Code that can make me more productive but you learn over time or when you stumble upon it. From my point of view, without a working IDE its much more difficult for a non-specific-language to learn and get better at the language. And again, VIM with the right plugins is a IDE, simple as that. Its annoying that people do not see this. The big difference is that VIM is designed around not moving your hand to your mouse and that is its major strength. On a side note: The issue i had with the plugins, well one of the plugin authors found the issue and it came down to it that the D compiler had a regression that effect DCD. I remember mentioning before as how many times the compiler ends up breaking code. Going over the D release list, you see way too many times: Major release - fix - fix, Major release - fix, Major release - fix - fix... What indicates to me a lack of cross platform testing. Especially the amount of regressions surprises even me. It feels like too much focus is put upon new features and too few upon a test setup that does not only tests the compiler but also all the dub packages.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote: * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 21:59:51 UTC, Dgame wrote: You are not alone. The existing D-Tools are either really bad or do not work propely/not out of the box. And I have more important things to do than trying to setup the tools. Maybe someone likes that, but not me. But I have to say that I've used more or less successfully Visual-D and Mono-D a few years ago. But neither of the tools can keep up in any way with Tools for Rust/C++/C#/Java/PHP. The existence of a good IDE which works out of the box without annoying setup procedures is crucial for the success of a language nowadays. That's one of the reason why I've moved on. I went back to C++ and nowadays to Rust. C++ is not that clean as D but the Tool support is crucial for anyone who wants to use the language for other than some hobby stuff. I have been comparing a bunch of languages and there IDEs this afternoon to see how fast and efficient there latest version work ( mostly inspired by the other topics of popular languages ). Wanted to avoid the whole "grass is greener on the other side" as a way to be fair. * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. * Crystal: Visual Studio Code + OmniPascal plugin Color syntax but nothing else. No surprise, Crystal has no Windows compiler so no way to link any meaningful out output on Windows. * Pascal: Yes, freaking pascal! Visual Studio Code + OmniPascal plugin Impressive! Impressive features, type hinting and more. * C#: Visual Studio Code + C# ( OmniSharp ). No surprise there. Lots of functionality. * Go: Visual Studio Code + Go Plugin. Again, no surprise. Lots of functionality. Did not try the Jetbrain Gogland IDE because that is a official product so of course Go will work great in that one. * Julia: Visual Studio Code + Julia Plugin. Took a bit more configuring but again more functionality then i ever got from any D plugin. * Swift: Visual Studio Code + Swift Plugin. Like Crystal, no Windows version and limited to Color Syntax. ... got kind of fed up testing because everything that you expect to works on Windows, worked out of the box ( at best with oa Julia one needed to add the compiler path ). If nobody has figured out the trend by now, every language that has a windows compiler in any form has no major issues to offer extended functionality ( or even basic ). Those that do not have windows compiler, fall flat as expected. The exception being D that despite having multiple windows compilers offer ( in my case ) no functionality beyond color syntax. I do not count the VSC ability to list every keyword in your document. Another trend that i noticed from the other thread is that all the above mentioned languages all outperform D in github user activity ranking ( inc the very young one's ). D has always struck me more as a corporate language ( one that is less focused upon open source ). Maybe there is a more open community focus on the other platforms and this drives more interaction and pushes better plugin support? In other words, at best it take me half a hour to get proper editor support in the above mentioned languages ( that offer it in Windows ). Where as D ... well, its been a long topic and anybody who read the first post knows the results. Lets see: * 8+ hours: Struggling with 4 plugins and no results. And still waiting on one of the plugin authors his feedback as he also has a life. * 5 hours: Seven languages with 5 working perfectly and 2 POSIX languages with the expected no result. Yes, that includes the time to download all the compilers, get examples and other stuff. Guess the 8+ hour language ;)
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 03:40:26 UTC, Rubn wrote: You seem to be short tempered You think after two days trying to get a series of plugins to work? you tried 2 plugins rather quickly, without even trying to see if there were configurations or other options you could use to get features working. Visual Studio Code: Code-D, Serve-D, D-Language Jetbrain: D-Language That is 4 plugins as described in the original post. Two of the same author, 2 from other authors. So that makes 3 different people there plugins. One may think a person can be salty after so many hours. - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... This is just not true... https://imgur.com/z6CZbjL.gif Well, if that actually worked, i will not be complaining here.
Re: How programmers transition between languages
On Friday, 26 January 2018 at 09:02:03 UTC, Ola Fosheim Grøstad wrote: While this analysis of language popularity on Github is enlightening: http://www.benfrederickson.com/ranking-programming-languages-by-github-users/ What i found interesting is the comparison between the "newer" languages and D ( see the reddit thread ). 9 Go 4.1022 15 Kotlin 1.2798 18 Rust0.7317 35 Julia 0.0900 46 Vala0.0665 50 Crystal 0.0498 53 D 0.047% While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), Go ( Google ). Even Vala and Crystal are ranked higher then D.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 07:08:50 UTC, Johannes Loher wrote: Take this all with a grain of salt: I have only tested this on Linux and OS X, I have no clue about the situation on Windows. In general a lot of plugins tend to work better in POSIX systems then Windows. I think its more a issue about Windows platform testing. But at least my experience was really good, so I'd like to use this opportunity to thank all the authors of the plugins and the underlying tools for doing this (ungrateful) work (and in my opinion doing it very well). I know that probably a lot has still to be done, but the state of affairs is not as bad as all the complaints make it sounds. It probably is not as bad but its clearly a issue anyway. But one guy complaining after trying 6 or 7 times over a year+ ( with constant reporting the issues ), probably means there are more people out there who tried and simply gave up without reporting the issues. The reasons for the problems you describe still being so common have already explained thoroughly by others: Its mainly that there are no paid developers working on it and therefore not enough people working on it. So the solution is actullay quite simple and it is the same answer that most complaints about problems with D get: Either do it yourself, or pay somebody to do it. That is the quickest way to fix things. And that is the same issue with a lot of FOSS languages. But at one moment one needs to say stop. I donated a lot ( for me anyway ) of money to different FOSS projects but that money, what happened to it? In general there is zero accountability where money gets spend on most projects. Just in the last month over 500$ on different projects. But i am not a infinity money machine. And in this case: Does one donate money to the Code-D/Serve-D developer. But its not really his issue. To the D-Language developer? But its not really his issue. Who do you even donate too to have specific problems that are hard to trace fixed. Its not like one asks: "Please add x functionality". Just recently i donated 100$ to a other language project to implement socket support. So far i see nothing happening, while this functionality is more important to me now ( as it blocks my progress on that project ). So even when donating the results can be "i feel ripped off". Do it yourself = Time is money. If i had that much time to learn the base code of a language, i will not be donating money to specific language projects ( also i'am not a good core / system programmer ). I feel its too many times: Complain about issue => Get responds there are no people to do it => Please do it yourself or pay. By that logic i am bankrupt tomorrow with the issues i face in different languages :) Let me not bother you too much with my rants. Like i said, its better ( for me ) to focus on a language that has things better worked out and it does not feel like screaming at the walls. I feel sorry for projects like this that have no big corporate backers because its not a envy position without the money and focus.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 21:42:33 UTC, bachmeier wrote: Even one paid developer makes a big difference. You don't need hundreds. Making the problem harder is that many current D users don't have an interest in those tools. Therefore you're drawing from a small pool of part-time volunteer labor. It's entirely up to the community. This is not something Walter or Andrei should be concerned with. I had hoped the D Foundation would lead to a better organization of the community, but to this point, that doesn't seem to be the case. It was my impression that D Foundation has sponsoring from different companies. No clue how much but its strange to run a Foundation and not being able to pay one or more full time employees. I just looked up some community sourced project: Nim gets on average 1500 to 2000$ per month Crystal seems to be doing 2000 to 3000$ per month That is only counting salt.bountrysource and no direct donations. Just noticed this thread on Reddit and somebody asked about D. http://www.benfrederickson.com/ranking-programming-languages-by-github-users/ According to the author off the ranking: 18. Rust 0.73% 58. D... 0.047% No wonder that Rust seems to be more popular and D seems to struggle in popularity.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 19:53:39 UTC, Basile B. wrote: If you write OOP with few templates like often done in C#, Delphi, or more declarative style like Go or C, then DCD works fine. Your frustration probably comes from the fact that popular techniques in D are not supported by DCD: Template Metaprogramming and CTFE. Maybe there has been a misunderstanding but i am not talking about CTFE or Metaprogramming. Basic OOP does not even work. And that is after testing D plugins going back a year or more with several DMD/Dub releases at the times. On Thursday, 25 January 2018 at 17:32:24 UTC, Andre Pany wrote: While the several tools out of the box do not work well together, the involved developers did a great job (without any payment in contrast to Go/C#, Delphi...). I also struggled with the problem how to configure DCD in the DLang plugin for IntelliJ today. This might be the reason for the items marked as unknown. I created an issue here https://github.com/intellij-dlanguage/intellij-dlanguage/issues/356 Most of the plugins mentioned here are also made by community or individual members. The issue ends up being that its not so much the Editor plugins that create the problems but whatever language server that is behind it. Please look up several of the plugins there originals and you will see a lot are made by individuals? For instance OmniPascal... In my eyes its not the plugin authors there problem because they need the official tooling support from D. Compile a set of tools and notice how many deprecated calls show up. Or issues when a new D compiler version gets released. Or a new Dub version that breaks the tooling left or right. This is what i mean by "not properly cross platform tested". There seems to be a total lack for any tool "chain testing" beyond individual stand alone tests. How else does one explain the constant issues i have personally faced ( and reported ). I have been in the position to use D in several projects but in my experience its not worth taking the risk ( when issues like this keep happening ). This also affect not just the tooling but also the whole public dub packages. When a new language like Rust is more tooling friendly and its extended platform integrates great with the editor plugins... Its not like Mozilla has hundreds of Engineers on Rust. Its extreme highly community driven. It seems to be that they understand the value of better tooling and friendly platform support. Whereas its my impression that a lot of resources get focused on making D its compiler / language better but the rest seems to be ignored. I am sorry if this sounds cruel but for now D is on the back burner and my next project will probably be in Rust. Its a real shame but when even things like editor plugins barely work it makes me doubt the rest of the platform. And i do not even like Rust as a language but one can not deny it is a better supported platform. One can only express their hope that there will be a revitalization in the D management and the priorities. From my point of view it feels like D is falling behind when compared to other languages like Rust/C++/Go/... D really needs a project leader that knows the language and starts focusing the resources beyond just the compiler. Anyway, good luck in the future.
Dscanner - DCD - Dfix ... Editor support or the lack of it.
After months doing a different project, i need a programming language for a new client with specific needs. D comes to mind. As usual that involves downloading the compiler (dmd and ldc). So, lets install Visual Studio Code: * Code-D Plugin: - Syntax highlight *check* - After saving: DMD error suggestions in the code. *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... So lets try the next plugin: * Serve-D Plugin: - Syntax highlight *check* - After saving: DMD error suggestions in the code. *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... Frustration level increasing. Lets try the next one: * D-Language Plugin: - Syntax highlight *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... Ok ... so Visual Studio Code its Dscanner, DCD, Workspace-d do not properly work or some other issue. Then lets try IntelliJ Community Edition. After a long time getting all the dependancies and compiling them... Dscanner - DCD ( client and server ) - Dfix ... * D Language Plugin: - Syntax highlight *check* - Way too many items like writefln, import etc all being marked as unknown. Clearly wrong. - ... and nothing else... - Socket error (std.socket.xxx) on closing IntelliJ Conclusion is that it feels like the whole D infrastructure is very, very poorly supported. Other issues like delays that some of the D plugins seem to introduce: * Like "loading ..." popups that do nothing but always show up ( Visual Studio Code ) * Like pressing "dot" expecting a response, waiting 2 seconds and then finally something happening ( IntelliJ plugin ) but simply dumping every possible name and variable ( zero intelligent code support ) I assume that this is again broken DCD or Dscanner. And no, no errors in the console of VSC or anything like that. Let me summarize my personal D editor experience in the last 1+ year. * Attempts at getting D editor support going: 6 or 7. * Amount of times things worked out of the box. One! And this was limited to about a few minutes and after that all suggestions broke again. * Amount of times dscanner or dcd or other plugins broke because of DMD newest version broke: 4 * Tested on different machines: 4! They all have one thing in common: Windows 10 * Tested on different Windows installations: 3 * Tested on different "version" of Windows 10: 3 * Amount of times complaining to the plugin authors: Too many to count. * Time spend on these tests / issues: Easily 50 hours or more. * Frustration level: Again, like each time before EXTREME! Please do not give me the company line that i need to report issues. I did so many times. It is tiring playing guinea pig, complaining and reporting, waiting for things to get fixed and still seeing things break again or simply not working properly. I can download Go, C#, C, C++, Delphi, Rust and get proper working plugins for the above mentioned editors but D is always that frustrating problem child. And i can not blame the plugin authors because the issues always seem to stem from the D plugins ( dcd, dscanner, ... ). Like dscanner changing its binary location between builds from folder root to /bin folder, breaking the plugin authors there system as it expected it in the folder root. Maybe things work great in a few very specific editor but in my personal experience, D its editor support is non stop frustrating. And i suspect that this complaint is not new. Clearly there is infrastructure in place for automated testing the compiler but it feels like there is a total lack of infrastructure for everything that surround it. Beyond maybe a few editors that the core team uses? My personal opinion: Too much in the D landscape is so individualist and not properly cross platform tested, that it results in pure frustration for the end developer.
