Re: Vision document for H1 2018
On Monday, 12 March 2018 at 06:13:35 UTC, rumbu wrote: I'm comparing two open source projects, both hosted on github. Both available in the same supermarket. It seems that one of them is easy to reach to, the other one is on the top shelf and you need a forklift to reach it. And when you bring the forklift, you find out that you need two additional excavators running on a special kind of fuel which is not available in your country. I'm comparing the contributing experience, because almost every time when someone complains about something, is invited to contribute himself. yeah, but if you know in advance, that you need a fork lift to reach it, and that you'll also need two additional excavators running on a special kind of fuel, which is not available in your country...then..and only then.. are your expectations in line with reality ;-) but people come to D, thinking they can just walk over to the shelf and take it. (because that's often what they are used to). Some of us are actually used to the very opposite - i.e you always have make that extra effort, even to do the most simple things. But that effort just seems normal to us. I agree, there needs to be more middle ground, which both types will benefit from in the end.
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 04:48:43 UTC, psychoticRabbit wrote: but I think comparing things in the C# world, to things in the D world, does not make a lot of sense, really. It's like comparing my local corner shop to some worldwide supermarket chain. I'm comparing two open source projects, both hosted on github. Both available in the same supermarket. It seems that one of them is easy to reach to, the other one is on the top shelf and you need a forklift to reach it. And when you bring the forklift, you find out that you need two additional excavators running on a special kind of fuel which is not available in your country. I'm comparing the contributing experience, because almost every time when someone complains about something, is invited to contribute himself.
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 03:11:34 UTC, Laeeth Isharc wrote: You don't need to have subsystem for Linux to use bash. Just the standard git client for Windows is enough. Happy to find out about this. It's not like using git bash everyday on Windows to know this by default. sh setup.sh [...] make -> Command error: undefined switch '-C'
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 03:37:11 UTC, Laeeth Isharc wrote: cd test make all -j8 Command error: undefined switch '-j8' Why are you adding -j8 ? Does it say to do so in the instructions ? Try without it. (I can't test here as typing from my phone). https://wiki.dlang.org/DMD_development Of course, it works without the -j8 switch, but the documentation doesn't say that multiple threads option is only available on Linux.
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 04:54:22 UTC, Jonathan M Davis wrote: On Monday, March 12, 2018 03:37:11 Laeeth Isharc via Digitalmars-d-announce wrote: On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote: > [...] Why are you adding -j8 ? Does it say to do so in the instructions ? Try without it. (I can't test here as typing from my phone). When dealing with building on Windows, it would definitely pay to read the instructions and not assume anything about make, since unfortunately, the Windows build uses the digital mars make, which is severely limited in comparison to the BSD make or GNU make. - Jonathan M Davis That's only partially true and the reason for the error. GNU/BSD make is required to run the DMD testsuite. BTW removal of DigitalMars Make has been officially approved since a long time, but it's blocked since it's so hard to make changes to the auto-tester.
Re: Vision document for H1 2018
On Monday, March 12, 2018 03:31:36 Laeeth Isharc via Digitalmars-d-announce wrote: > If Phobos looks like a mess to C# programmers, so much the worse > for C# programmers. However I doubt they this is true in the > general case. It's better in many ways, but different and > unfamiliar and everything unfamiliar is disconcerting in the > beginning. Yeah, I remember when I was first dealing with D years ago, and the range stuff that was in there was totally unfamiliar, and it annoyed me, because I just wanted the iterators that I was familiar with so that I could easily do what I wanted to do. Granted, it was worse to figure all of that out then, since the documentation was much worse (e.g. at the time, there was a compiler bug that made it so that auto return functions did not show up in the documentation, so all of std.algorithm explicitly listed the return types, making it downright scary), but still, at the time, I just didn't want to deal with figuring out the unfamiliar concept, so it annoyed me. Now, I actually understand ranges and am very glad that they're there, but as a D newbie, they were annoying, because they were unfamiliar. I think that I'd approach it all very differently now, since at the time, I was in college and just generally a far less experienced programmer, but I think that many of us tend to look for what we expect when learning a new language or library, and when that's not what we get, it can be disconcerting to begin with. Phobos is very unique in its approach with ranges, likely making it a major learning experience for anyone from any language, but AFAIK, the only language with a comparable approach in its standard library is C++, and I'd definitely expect it to be somewhat alien to the average C# or Java programmer - at least to begin with. D does things differently, so anyone learning it is just going to have to expect to deal with a learning curve. How steep a curve that is is going to depend on the programmer's experience and background, but it's going to be there regardless. - Jonathan M Davis
Re: Vision document for H1 2018
On Monday, March 12, 2018 03:37:11 Laeeth Isharc via Digitalmars-d-announce wrote: > On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote: > > On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote: > >> [...] > > > > Yes, I'm the typical lazy convenient Windows user scared of the > > terminal window. > > > >> [...] > > > > I am happy for Posix users. Theoretically the process is the > > same on Windows. > > > >> [...] > > > > This will need Linux subsystem as a Windows feature installed. > > Bash scripts do not work on Windows. Or other third party > > applications that are not listed as prerequisites on wiki. > > > >> [...] > > > > make -fwin32.mak release > > Error: don't know how to make 'release' > > > > Ok, let's skip this, make it without "release". > > > > Now test it: > > > > cd test > > make all -j8 > > Command error: undefined switch '-j8' > > Why are you adding -j8 ? Does it say to do so in the instructions > ? Try without it. (I can't test here as typing from my phone). When dealing with building on Windows, it would definitely pay to read the instructions and not assume anything about make, since unfortunately, the Windows build uses the digital mars make, which is severely limited in comparison to the BSD make or GNU make. - Jonathan M Davis
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. Hey.. I feel your pain.. I like things to be easy too ;-) but I think comparing things in the C# world, to things in the D world, does not make a lot of sense, really. It's like comparing my local corner shop to some worldwide supermarket chain. What's the point in going into the local corner shop and complaing that they don't stock this or that, but the supermarket down the road does. Or complaining that they charge $4 for a loaf of bread, when down the road at the supermarket it only costs $2.50. You have to compare apples with apples, not apples with shiny red toffee apples ;-)
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 19:58:51 UTC, rumbu wrote: On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote: [...] Yes, I'm the typical lazy convenient Windows user scared of the terminal window. [...] I am happy for Posix users. Theoretically the process is the same on Windows. [...] This will need Linux subsystem as a Windows feature installed. Bash scripts do not work on Windows. Or other third party applications that are not listed as prerequisites on wiki. [...] make -fwin32.mak release Error: don't know how to make 'release' Ok, let's skip this, make it without "release". Now test it: cd test make all -j8 Command error: undefined switch '-j8' Why are you adding -j8 ? Does it say to do so in the instructions ? Try without it. (I can't test here as typing from my phone).
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote: On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote: On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote: And personally, depending on the problem, C# is better to program in than D. I still don't know why C# programmers are willing to give up C# and prefer to use D. C# is vastly surperior for what it does. Because, even the language creators seem to not recognize this, D looks like C# with *native compilation*, the syntax is 95% identical. Basically, if my source code doesn't use any .NET framework function, it will compile successfully with dmd without any (major) change. I suppose that every C# programmer is enthusiastic on the first contact with the D language, but fails to keep his enthusiasm when he sees Phobos. C# programmer's mind is locked in the OOP world and Phobos looks like a mess from his point of view. The problem is that D stagnates and in the same time C# evolves. Sometimes I feel like the C# language team is using D as inspiration for the new features, starting with C# 7.0, a lot of D concepts were introduced in the language: local functions, '_' as digit separator, binary literals, ref returns, tuples, templates, immutability. Guess what the next version of C# has on the table: slices. In the same time, D delegates new features (and sometime existing ones) to library implementation, instead of assume them in the language syntax. My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly. It's a good thing not bad that other languages are inspired by what works. Languages aren't in a vicious battle to the death, a Hobbesian war of all against all. If C# gets better, that's great! I don't think D is stagnating at all - on the contrary, it's amazing to see the ecosystem flourishing, no matter where you look - documentation, adoption, libraries, commercial adoption. I think it's reasonable to disagree with the strategic decision made to move capabilities from compiler to libraries. But you really have to make an argument about why you disagree if you are you expect to be persuasive because there is a thought-through argument for the choices made, which I am sure you must be familiar with. I don't think it matters much whether you are right about what happens to C# programmer interest in D dies as soon as C# native cross-platform is ready because D is quite an ambitious language and doesn't need to depend on adoption from any one community to continue growing at an impressive rate. As it happens though, as an empirical matter I doubt it. C# slices look great. I wanted to use them for generating wrappers for our analytics. Not that easy for that purpose, from what I could see. Looks like the primitives are stack only, and I tried to figure out how to use them elsewhere and gave up because it wasn't that easy. If Phobos looks like a mess to C# programmers, so much the worse for C# programmers. However I doubt they this is true in the general case. It's better in many ways, but different and unfamiliar and everything unfamiliar is disconcerting in the beginning.
Re: dpldocs now has cross-package search (experimental)
I probably released this a bit too soon... it seems to have a memory leak and eventually pushes all other server functions out if I leave it running. So I took the search back down for now until I can debug that, or maybe just rewrite the program to something fundamentally more memory-efficient.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. Funnily enough, becoming a significant contributor to the ecosystem - compiler or Phobos - demonstrably does not require even a complete graduation from high school or any industrial programming experience. I know of what I speak, but I don't say who as it's not for me to say. I was in Munich over new year and I asked someone else who has been a star contributor how he got involved. It was really easy for him to start contributing, so he did. But different people find different things easy. You don't need to have subsystem for Linux to use bash. Just the standard git client for Windows is enough. I agree the Windows experience could be easier upfront. Still, it's better than it used to be and next year it will be better again. You can't really compare the C# ecosystem to the D ecosystem because they are organised around different principles. Yes, the pain is upfront with D, and it's not for everyone. However on the basis of rational calculation the pain in learning something new is a small part of the total cost of the technology choice and for some people by far not the most relevant question. And it's an advantage in hiring because the D community filters for people who have a tolerance for discomfort upfront. It would be wonderful to be able to wave a wand and make all of life's little frustrations disappear. But in my experience, that's not what is possible - one picks from the choices available and the new ones one thinks up. People have a tendency to think that leadership has more power to just change things then is actually the case. I'm going to be building standard developer images from scratch programmatically. Transform froma Windows ISO into a VM image.Maybe I could open source those scripts and then it's easier to get to the bottom of any install and build problems and one can replicate difficulties.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote: Because, even the language creators seem to not recognize this, D looks like C# with *native compilation*, the syntax is 95% identical. Basically, if my source code doesn't use any .NET framework function, it will compile successfully with dmd without any (major) change. As an aside, I had to translate a special-use decompression algorithm from C# to D, and it was a near seamless transition. I'm trying to persuade some of my C# compatriots to try D because of that experience.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 17:15:28 UTC, Seb wrote: I assume you are using Windows? Yes, I'm the typical lazy convenient Windows user scared of the terminal window. Setup on Posix is really simple. git clone all three repos + run make. I am happy for Posix users. Theoretically the process is the same on Windows. There's also a bash script to automate this: https://github.com/dlang/tools/blob/master/setup.sh This will need Linux subsystem as a Windows feature installed. Bash scripts do not work on Windows. Or other third party applications that are not listed as prerequisites on wiki. From what I heard it's a bit tricky on Windows. I only tried with wine and that worked out-of-the-box for me. Execute the DMD installer, set PATH, DM_HOME and HOST_DC and then run the win32 makefiles work fine. make -fwin32.mak release Error: don't know how to make 'release' Ok, let's skip this, make it without "release". Now test it: cd test make all -j8 Command error: undefined switch '-j8' What could be done from your perspective to make the setup easier? From my perspective I would like to have an working setup, not necessary easier. But if interested, to contribute to C# compiler, you just need to open roslyn.sln in Visual Studio, make your modification, run the test suite, commit, you're done.
Re: State of D 2018 Survey
On Wednesday, 28 February 2018 at 13:41:56 UTC, Mike Parker wrote: About a month ago, Sebastian Wilzbach sent an email out to a few of the core D folks asking for feedback on a survey he had put together. He thought it would be useful for the Foundation to use in order to make decisions about where to expend development efforts. Eventually Andrei gave his stamp of approval, the survey questions were tweaked, and then it was ready to roll. Of course I would love for you to read my blog post announcing it, but if you want to skip the prose and go straight to the good stuff, here's the survey link: https://seb134.typeform.com/to/H1GTak The blog: https://dlang.org/blog/2018/02/28/the-state-of-d-2018-survey/ Reddit: https://www.reddit.com/r/d_language/comments/80w29n/the_state_of_d_2018_survey/ Wow, we got more than 500 responses so far. A huge thank you already! The survey is still open for a few more days, so if you want to make your opinion count now is the last chance.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). Don't forget that "open source" != non-profit. For the C# compiler there's a dedicated team of full-time developers. Also to be fair, the activity on dmd isn't that low either though the last week was a one with low-traffic: https://github.com/dlang/dmd/pulse Typically ~40 PRs get merged per PR for dmd alone: https://auto-tester.puremagic.com/chart.ghtml?projectid=1 With druntime + phobos, it's a lot more. The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. I assume you are using Windows? Setup on Posix is really simple. git clone all three repos + run make. There's also a bash script to automate this: https://github.com/dlang/tools/blob/master/setup.sh From what I heard it's a bit tricky on Windows. I only tried with wine and that worked out-of-the-box for me. Execute the DMD installer, set PATH, DM_HOME and HOST_DC and then run the win32 makefiles work fine. What could be done from your perspective to make the setup easier?
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. I contributed to phobos for the first time for the release 2.079.0. Experience was smooth and also I learnt many new things from the review comments. I was able to follow wiki page to compile phobos or compile one specific module. Please let us know the issue faced, so that wiki can be improved.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos.
Re: Article: Why Const Sucks
On Thursday, 8 March 2018 at 15:13:09 UTC, Steven Schveighoffer wrote: On 3/8/18 9:58 AM, joe wrote: On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: /snip May be not entirely related, but a little gotcha. given: interface XY {} class Foo: XY {} class Bar: XY {} void doSomething(in XY sth) { auto foo = cast(Foo)sth; // error in @safe code } But the compiler doesn't emit a warning that const got cast away in @system code. Since @system is the default setting and casting const away is by definition undefined behavior, there should be some feedback. If you cast away const in C++ you need to be explicit about it by using const_cast, documents the intention rather than D's swiss-army-cast. This is a problem with the cast system, not const. ... I figured. Sorry for off topic. ... D has one cast mechanism, and it's used to: a) dynamic type cast b) hook user-supplied opCast c) enter undefined behavior by casting away const/immutable. I really think we should have a separate mechanism for a and b, as they are far less dangerous than c. std.conv.to does this as well, ... Thanks for pointing this out. ...but the language should have some safeguards against using "safe casting" incorrectly. -Steve yes, that's what I was aiming for :) This one got me because I assumed, with all the improved security in place, D would never silently do such a thing... Assumptions, right? ...the root of all evil. I should know better. haha. Anyways, thanks for the insight and have a nice Sunday.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote: I am sure that lots of D members will be quick to point out, that C# is run by a commercial company and D has only open source contributors. Now why did you not contribute! /sarcasm I'd like to point out, that C# is run by a commercial company and D has only open source contributors. For that matter, so is Rust (a 1/2 billion $ organisation, at least), run by sjw's who will 'attack' (as opposed to 'point out') anyone that speaks out against anything. As for cross platform, have you tried running Rust in Windows XP? Anyway.. I'm going back to the sandbox, to play with my own toys.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote: With the usual response here: "Why do you not fix it yourself or pay for it". Maybe because most people who come want to use the tools and be productive and not spend their time fixing up those tools. I've never seen anyone write that. Most likely you saw someone post something that looks similar, but has a dramatically different meaning. The usual response is "If you want something done, you're going to have to do it yourself or pay someone to do it for you, or else it won't get done." Its a mentality issue that some do not get here. In order to grow you need consumers for your product. If you force or whine to them to fix the issues, they leave. When they leave you lose potential growth. That loss in growth means losing potential members that can fix and want to fix the issues. And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for.
Re: Updated D packages in GNU Guix for x86_64-linux, i686-linux, armhf-linux
On Sunday, 11 March 2018 at 12:41:28 UTC, Johan Engelen wrote: Kai has been working recently [1] on updating LDC 0.17.x (ltsmaster) to work with LLVM 6, PowerPC, AArch64, ... You may want to take advantage of that activity to get better bootstrap compiler support for your platforms. For example by filing bug reports, or better: helping out with testing and fixing things ;-) Sure thing. Guix can support multiple versions of LLVM and build against those, so you can inject different dependencies (read versions of LLVM) in the dependency graph. I am quite keen to use the latest for my tools.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote: Because, even the language creators seem to not recognize this, D looks like C# with *native compilation*, the syntax is 95% identical. Basically, if my source code doesn't use any .NET framework function, it will compile successfully with dmd without any (major) change. Most people do not have issues with the core language of D. You can come from any of the above mentioned languages ( like C, C++, Rust, PHP, Python, Nim, ... ) and get going with D. That is what attracted me in the first place. The language looks good but the moment you actually start using D its issue after issue. With the usual response here: "Why do you not fix it yourself or pay for it". Maybe because most people who come want to use the tools and be productive and not spend their time fixing up those tools. Its a mentality issue that some do not get here. In order to grow you need consumers for your product. If you force or whine to them to fix the issues, they leave. When they leave you lose potential growth. That loss in growth means losing potential members that can fix and want to fix the issues. One can call it selfish but every language is based upon this principle. No growth and community of lots of selfish users means no other members to fix the issues. It is the 9 Circles of Hell. I suppose that every C# programmer is enthusiastic on the first contact with the D language, but fails to keep his enthusiasm when he sees Phobos. C# programmer's mind is locked in the OOP world and Phobos looks like a mess from his point of view. +1! It has the language mostly right but its everything around it that is simply a mess. When one compares that to Rust. They are not having constant discussion about replacing cargo ( as dub in D has issues ). They do not need to have multiple documentation generators. The cross platform is simple and fast. Same applies to Go. And C# ... Resources simple are more focused and enhance the whole platform as such. D is like a children sandbox where everybody is playing with their own toys. So when other complain about the mess of the playground, the responds by some is just as typical. The problem is that D stagnates and in the same time C# evolves. I am sure that lots of D members will be quick to point out, that C# is run by a commercial company and D has only open source contributors. Now why did you not contribute! /sarcasm Sometimes I feel like the C# language team is using D as inspiration for the new features, starting with C# 7.0, a lot of D concepts were introduced in the language: local functions, '_' as digit separator, binary literals, ref returns, tuples, templates, immutability. Guess what the next version of C# has on the table: slices. Yep ... Things are moving faster in the .net camp thanks to the focus on .net Core and the RyuJit. Here is a fun one, with Blazer now being part of the official .net. https://github.com/aspnet/blazor Blazer = C# code runable in the browser using WebAssembly. In the same time, D delegates new features (and sometime existing ones) to library implementation, instead of assume them in the language syntax. My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly. Personally i am waiting to see CoreRT finalized: https://github.com/dotnet/corert -> CppCodeGen/C++ -> RyuJIT codegen -> Webasm Its already working and getting better by the day. Other languages are moving forwards at blazing speeds and D seems to put it priorities on adding new exiting features. Where as a large part of the outcry is the issues with the library, lacking editors support, cross platform issues, ...
Re: Updated D packages in GNU Guix for x86_64-linux, i686-linux, armhf-linux
On Sunday, 11 March 2018 at 08:43:25 UTC, Pjotr Prins wrote: The GNU package manager updated LDC to 1.7.0 which now provides x86_64-linux, see https://www.gnu.org/software/guix/packages/L/. Runtime dependencies and build are listed at https://hydra.gnu.org/build/2525193#tabs-runtime-deps, including 0.17.4 (bootstrap) and LLVM 3.8.1. LDC 0.17.4 provides x86_64-linux, i686-linux, armhf-linux. We aim to add D compilers for all supported architectures. Kai has been working recently [1] on updating LDC 0.17.x (ltsmaster) to work with LLVM 6, PowerPC, AArch64, ... You may want to take advantage of that activity to get better bootstrap compiler support for your platforms. For example by filing bug reports, or better: helping out with testing and fixing things ;-) -Johan [1] See e.g. https://github.com/ldc-developers/dmd-testsuite/pull/34
Re: Vision document for H1 2018
On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote: On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu wrote: Hello, the vision document of the Founation for the first six months of 2018 is here: https://wiki.dlang.org/Vision/2018H1 According to the State of D Survey, 71% of the respondents don't care about betterC. Why is betterC on the priority list? BetterC is probably mostly useful for writing libraries (that can be used from D or other languages). So these 29% of respondents are perhaps more important than just their percentage suggests.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:25:07 UTC, Dylan Graham wrote: betterc is just another way of supporting that crowd..and it's a very big crowd. Yeah, 29% of the crowd. 29% of the existing D crowd who answered the survey, which means around 150 people, or about how many download one compiler, dmd, in an average hour of the day: http://erdani.com/d/downloads.daily.png Meanwhile, Walter wrote a blog post about his betterC efforts last year, and it was the third-most liked link from dlang.org on reddit over the last year, with 226 net likes: https://www.reddit.com/domain/dlang.org/top/?sort=top&t=year No. 2? Another article about using D without the GC. Now, as I've said on the forum several times, I personally don't care for @nogc or betterC: I don't use them. I'm sure many existing D users don't either. However, as those reddit stats show, there is interest from _outside_ the D community for them. When it comes to strategic decisions like this to bring in new users from outside the community, you cannot depend on polling users within the community to figure it out. Argue against betterC really bringing in new users if you want, but arguing that it doesn't help existing users is missing the point. I'm not sure how successful betterC will be in pulling in those users, as I'm not a C/C++ programmer and don't know what they want, but the popularity of those links suggests the D foundation is on the right track. Your problem is not betterc, but something else. So focus on that instead. You're right, my problem isn't BetterC, it's the fact that Foundation can't get its priorities right. BetterC is a symptom. The Foundation's priorities are not simply serving the existing users but growing the userbase.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote: My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly. OT: Interestingly, my uni is still stuck in the OOP paradigm, and is now teaching intro to OOP using .NET Core, cause it's now cross platform, and people can also used VS code, which also cross platform. but running > dotnet myprogram (.dll) is just an awful experience ;-) although, that's how java works to.. and java is probably the most widely used language of all.
Updated D packages in GNU Guix for x86_64-linux, i686-linux, armhf-linux
The GNU package manager updated LDC to 1.7.0 which now provides x86_64-linux, see https://www.gnu.org/software/guix/packages/L/. Runtime dependencies and build are listed at https://hydra.gnu.org/build/2525193#tabs-runtime-deps, including 0.17.4 (bootstrap) and LLVM 3.8.1. LDC 0.17.4 provides x86_64-linux, i686-linux, armhf-linux. We aim to add D compilers for all supported architectures. Note that GNU Guix can run on top of all Linux distributions because it is self-contained. Guix includes all its dependencies (except the kernel) and can be removed easily.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:10:28 UTC, psychoticRabbit wrote: On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote: And personally, depending on the problem, C# is better to program in than D. I still don't know why C# programmers are willing to give up C# and prefer to use D. C# is vastly surperior for what it does. Because, even the language creators seem to not recognize this, D looks like C# with *native compilation*, the syntax is 95% identical. Basically, if my source code doesn't use any .NET framework function, it will compile successfully with dmd without any (major) change. I suppose that every C# programmer is enthusiastic on the first contact with the D language, but fails to keep his enthusiasm when he sees Phobos. C# programmer's mind is locked in the OOP world and Phobos looks like a mess from his point of view. The problem is that D stagnates and in the same time C# evolves. Sometimes I feel like the C# language team is using D as inspiration for the new features, starting with C# 7.0, a lot of D concepts were introduced in the language: local functions, '_' as digit separator, binary literals, ref returns, tuples, templates, immutability. Guess what the next version of C# has on the table: slices. In the same time, D delegates new features (and sometime existing ones) to library implementation, instead of assume them in the language syntax. My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly.