The progress of D since 2013
Hi! Good to see D is progressing! I was active forum and bugzilla participant in 2011-2013. Since then I have not touched D. What is the progress of D (2014-2017) in following dimensions: 1) Support of linking in win64? AFAIK Walter introduced win64 support in circa 2012 which was the big progress. However, support for win64 linking was limited because dmd defaulted on old dmc linker, and Walter didn't plan to do anything with this. 2) What is the support of other platforms? AFAIK there was progress on Android. From my memory recollections, the full support of Android was expected at that time. 3) What is the state of GC? AFAIK there were some improvements for GC sent as GSOC projects but they were not added in 2013. I see in the changelog that there are some improvements in speed and configuration support was added. 4) What is the state of GDC/LDC? GDC team was actively working on including gdc in gcc project. Do gdc and ldc still pull D frontend, so there is essentially 1 frontend (where gdc and ldc frontends lag several versions behind) + 3 backends? I see in the changelog some dmd backend improvements. How the dmd backend is compared with C++/GDC/LDC? AFAIK in 2013 there was a tradeoff: either you use dmd with brand-new frontend or gdc/ldc where performance is comparable to gcc, but frontend lags behind. Is it still true? 5) What is the progress with CTFE? I see a lot of discussions in forum archive devoted to the development of CTFE. What is the summary of CTFE development in recent years? 6) I don't see any significant changes in D core from dlang documentation (except those mentioned in changelog for 2014-2017). Is is true or is the official spec as usual delayed :)? Is dlang spec fully and frequently updated or is it sparse as in the past? Is TDPL book still relevant? 7) Is UDA still compile-time? Are there plans to make it also runtime? 8) What is the progress with shared and immutable? AFAIK the compiler support for shared was not complete and Phobos library itself was not 'immutable-' and 'shared-correct'. 9) Does D gains popularity? 10) Anything else 2013 D user must know? :) I don't ask about Phobos because according to the changelog the progress is enormous, incremential and targets several directions - I doubt it can be easily summarised... Thanks!
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 17:43:59 UTC, Maxim Fomin wrote: On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote: Sure, but in many cases D allows you to work around decisions you don't like. Plus, you can actively contribute, make suggestions and prove your case. The length of some threads shows that Walter, Andrei and others involved in the development take input seriously and answer questions and give the reasons for their decisions. Well, in case of C/C++ there is also rationale for decision, but not in the forum form. But providing rationale is not helpful if there is disagreement. To elaborate. If the issue is comparing chances of changing language in a user-oriented way of D and standardized languages, then it is definitely no. First of all, there is huge information gap between language hackers and users. Secondly, it is hard to beat the 'committee' argumentation even if they are wrong - they are simply to skilled and experienced. Two examples. I am aware of only one case when Walter and Andrei agreed with community. It is epic bugzilla discussion [1] regarding contract programming. It took 60 comments to convince. [1] https://issues.dlang.org/show_bug.cgi?id=6857 The second example is more recent dmd pull discussion regarding template linkage behavior (Walter + Martin vs. Kenji). After long discussion the outcome was that some rare but used feature was dropped for the sake of dmd internals convenience. Walter's argumentation was that the language feature was working by chance, so relying on it is a mistake (to be more precise, the question was whether to write new code to support feature in another context or to drop it and make code cleaner). After new release there were couple issues filed in bugzilla that complained about new behavior, but were closed as invalid (sorry, don't have link, recollect from memory). So, my point is that D except communication channel is pretty much the same as standardized languages with respect to changing language. I would say there are better chances that some feature will suddenly be changed and backfire existing code rather than user will convince to tweak the existing features to make it user - friendly at the expense of internals complexity. I do admit that discussions of new features and simple enhancements provide better chances (discussion is about significant issues, not trivial enhancements - isn't it?).
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote: On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin wrote: On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote: to be confined by committee decisions etc., D has committee (Walter & Andrei). Some of their decisions frustrate D users too. Sure, but in many cases D allows you to work around decisions you don't like. Plus, you can actively contribute, make suggestions and prove your case. The length of some threads shows that Walter, Andrei and others involved in the development take input seriously and answer questions and give the reasons for their decisions. Well, in case of C/C++ there is also rationale for decision, but not in the forum form. But providing rationale is not helpful if there is disagreement. That these decisions are not always to everyone's liking is inevitable. Given the contradictory nature of requirements in programming, it's only logical that one cannot cater for both sides all the time. Definitely agree.
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote: to be confined by committee decisions etc., D has committee (Walter & Andrei). Some of their decisions frustrate D users too.
Re: Moving back to .NET
On Tuesday, 22 September 2015 at 06:03:25 UTC, Laeeth Isharc wrote: On Monday, 21 September 2015 at 19:15:28 UTC, Maxim Fomin wrote: OK, the frustration is understandable. D is good enough to impress in short-run but has problems damaging itself in the long run. This leads to impression -> frustration cycle. Well, that may or may not be true. But someone who finds the error messages offputting isn't a good exemplar of putative deficiencies that show up in the long run, because these are part of the initial learning curve and after a year or two or experience it's really unlikely to be a main factor in determining choice of framework. Whereas it's understandable that in the beginning it can be a big source of frustration. I do not consider error messages as long run issue (it is discussed in the thread and I didn't mentioned it, so it might caused impression that I agree with complains about error messages). And if you leave the Microsoft ecosystem, I am not sure that D fares so badly in relation to a certain C family language that has had a big influence. If Microsoft ecosystem is left out then my opinion regarding comparison with Microsoft system is obviously irrelevant. Comparing with other languages I found D is decently good. He didn't say how long he had been using D for, but as others point out one underestimates how much one knows in relation to existing languages, and forgets that it is a degree of work over months and years to learn something new... I always could not understand complaints regarding D hard learning curve for anyone with C/C++/C# background. Either you need portability and you care what Mono does, or you don't. Commercial decisions are often a matter of tradeoffs. Eg for internal enterprise software you might find it valuable to be able to run on both linux and windows, but you can always make it a service on windows if linux is too much trouble. Sounds like 'lazy' portability: if app is portable - than good, if not - ok, we can leave with it:)
Re: Moving back to .NET
On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote: My experiences with D recently have not been fun. ... My main concern with .NET is portability and performance. I am going to give in to the portability and just assume Mono is good enough. Performance wise, I'd prefer D, but .NET is performant enough for most apps. Maybe in a few years things will change, I can't wait that long. Sorry guys! (not that you will miss me) OK, the frustration is understandable. D is good enough to impress in short-run but has problems damaging itself in the long run. This leads to impression -> frustration cycle. However, one point regarding portability. It is wrong to target cross - platform project by *assuming* that Mono is good enough. Either you need portability and you care what Mono does, or you don't. But then it is irrelevant what happens in Linux. By the way, it seems you started from .Net from the very beginning. It is unclear why you considered D in such circumstances (of course, except portability, but it seems you actually don't need it). Last point. You mentioned performance. Did you run benchmarks?
Re: D for Game Development
On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote: After leaving C++ behind for a few years to work in some higher-level languages for job-related coding, I was excited when I stumbled upon D ... This is a typical path ... I spent several weeks tearing through the language reference and standard APIs ... ... of a new user, who becomes very impressed Unfortunately I'm regrettably having to reconsider my decision to start a game project (or any project requiring significant time investment) in D. ... but the story usually continues with disillusionment (let me guess: buggy toolchain, not everything is ready) Not because of the language or compiler, but rather because of the lack maturity in the supporting tools; specifically, a debugger. Yep.
Re: Thoughts about the ideal programming language
On Wednesday, 13 May 2015 at 18:59:42 UTC, Dennis Ritchie wrote: Hi, I think that many will find something interesting in this article: - https://translate.google.ru/translate?hl=ru&sl=ru&tl=en&u=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F - Sorry translated using google translate. Can few to say regarding your thoughts, but need to mention that that site is the only significant one I am aware of with anti-technical, inflated, self - important culture of discussion (this has nothing to do with your post particular).
Re: D casually mentioned and dismissed + a suggestion
On Wednesday, 13 May 2015 at 09:20:36 UTC, Bienlein wrote: "You are making a cool project and we'd like to contribute to it, but we don't know and neither feel like studying this silly D". This is indeed a problem for many newly created languages. Scala has somewhat managed to create its own eco system with Akka, Spark, Spray in a specialized area like concurrent programming and big data. Also because Scala has found some liking in academical circles (e.g. Spark, Scala STM). I don't know how things will look like for Kotlin. Maybe there will be a niche for Android development. For Groovy there is basically only Grails as a killer application. Giving how D is similar to C/C++ I am surprised that non-familiriarity with D is a big problem.
Re: UDAs and no complaints about "need 'this'"
On Thursday, 9 April 2015 at 09:53:15 UTC, John Colvin wrote:
struct BigLongStructName
{
int evenLongerMemberName;
}
struct QN{}
unittest
{
BigLongStructName bigLongStructName;
@(bigLongStructName.evenLongerMemberName)
QN quickName;
__traits(getAttributes, quickName)[0]++;
}
Is it just me or is it weird that this works? Once you pull the
UDA out from being a storage class and attempt to alias it, you
get the usual "need 'this' for 'evenLongerMemberName' of type
'int'" error messages on use.
Why are UDAs so special? I don't believe there's any other way
to achieve this sort of effective renaming.
For me it seems to fit into D type system (which is not
necessarily is a good idea).
struct S
{
int i;
}
alias S.i si;
void main(){ /*si++;*/}
Behavior of D depends sometimes on it internals, not on
programmers' expectations. Since D has never been stabilized, the
boundary between WAT and bugs is partially undefined.
Re: size_t for length on x64 will make app slower than on x86?
On Sunday, 16 November 2014 at 13:39:24 UTC, FrankLike wrote: Many old projects need move from x86 to x64,but the 'length' type is size_t,it will change on x64,so a lot of work must to do.but I find some info which is help for d: http://www.dotnetperls.com/array-length. it means: test length and longlength, and found 'test longlength' is slower than 'test length'. 0.64 ns Length 2.55 ns LongLength I love D.So I don't want my app on x64 slower than on x86. Hope change in 2.067. Thank you all. It means where you have uint x = arr.length you should have had size_t x = arr.length from the very beginning.
errno_c.obj in druntime
Currently I am building dmd on win64. For some reason some phobos code references getErrno() function in errno_c.obj and that object file is not included into final binary (linker issues symbol absence error - by the way I don't remember it was needed on linux). It can be avoided by adding file into linking list, however it is only x86 version and during building win64 linker issues error due to model mismatch. 1) Why two trivial functions should be placed into separate .c file compounding win64 buildings headache instead of placing it somewhere in druntime among other D code? 2) How to avoid it? It comes to my mind to write two functions in D, compile with -m64 -c, replace x86 version with x64 version, add to gitignore, but then there would be repo syncing issues. Anyway it seems to be a too strange way to build a project. P.S. What's so wrong with D on win64? I had nothing close to win64 building difficulties when was dealing with linux x64 or x86.
Re: Constant relationships between non-constant objects
On Wednesday, 18 June 2014 at 05:34:18 UTC, Sebastian Unger wrote: So again, I believe, if D wants to play any role in major OO software design and development, it will need to step up its game. Especially in view of C++11 having addressed a number of the issues in C++ that I would have chosen D over C++ for. Cheers, Seb I believe this is wrong. First of all, if you want to keep relationship between objects, instead of thinking which feature can prevent it, consider not to try to break it in a first place. Secondly, it is sometimes discussed how to write some idiomatic code per se, rather than to solve particular task. Thirdly, if feature from one language does not do the same as similar feature from other language, does not mean that the feature/language is broken. Lastly, taking into account that it was Walter decided to do so, says something. Regarding your problem. Keeping relationship between two classes can be achieved by associative array, by inheriting from one class or by using examples above.
Re: Unnamed parameter with default value
On Tuesday, 17 June 2014 at 15:15:44 UTC, Luís Marques wrote:
Is there any particular reason why this is accepted? (I
introduced it by mistake):
void foo(int = 3) {}
I guess it could be useful to ensure binary compatibility when
you expect to add the parameter later?
Actually there is nothing strange because current implementation
technically does not remove variable names, it generates implicit
ones. This compiles:
void foo(int = 0)
{
_param_0 = 1;
}
and is equivalent to
void foo(int _param_0 = 0)
{
_param_0 = 1;
}
It is not a wise design decision which is aimed to support some
case, it is just technical consequence of implementation.
And I don't think that it has anything to do with binary
compatibility, because both parameter names and default arguments
exists only in compile time.
Re: Why are breakpoints caught by the runtime?
On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:
void main()
{
asm { int 3; }
}
object.Error: Breakpoint
0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll().void __lambda1()
0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll()
0x00402200 in _d_run_main
Is there any good reason to catch that?
I really want the debugger to fire up.
It is default windows runtime behavior and unless it provides
some interface to adjust it, you can not fix it (except patching
and rebuilding runtime, of course). Or, perhaps, you can bypass
runtime behavior by using windows api directly to adjust the
behavior to your needs.
By the way, judging by that runtime catches windows exceptions
and rethrows them as errors (object.Error: Breakpoint), you are
not encouraged to catch them.
Re: Why are breakpoints caught by the runtime?
On Sunday, 15 June 2014 at 15:23:29 UTC, Marc Schütz wrote:
On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:
void main()
{
asm { int 3; }
}
object.Error: Breakpoint
0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll().void __lambda1()
0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll()
0x00402200 in _d_run_main
Is there any good reason to catch that?
I really want the debugger to fire up.
Which OS and compiler version is that? The breakpoint is
correctly triggered here on openSUSE 13.1 x86_64 / DMD 2.066
git:
# ./bptest
Trace/breakpoint trap
# gdb ./bptest
...
(gdb) run
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0041b7b5 in D main ()
(gdb)
Obviously he is using windows and compiler version is irrelevant
- it is windows runtime issue.
Re: Tail pad optimization, cache friendlyness and C++ interrop
On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote: On 6/11/2014 4:34 AM, Timon Gehr wrote: Not memory safe implies (is supposed to imply) not @safe but not @safe does not imply not memory safe. @safe in D == memory safe. Why? I found dozens of cases when @safe is broken, let alone other issues in bugzilla. After thinking about the @safety in D my conclusion is that it is impossible to evaluate memory and safety correctness of a code in which static type says nothing about where an object is allocated. Contrary to popular wisdom, one can have fixed array on heaps, classes on stack, etc. If any code which is potentially not safe is rejected, this would lead to lots of false positives making using the language very inconvenient. Even in that case, safety cannot be guaranteed by the language due to other issues, like separate compilation, etc. By the way, memory safety is also compromised by compiler bugs which make him generate buggy code. Note, when I counted memory safety problems, codegen issues were not counted. @safe should not be considered as feature which ensures that the code is memory safe, but as a feature rejecting code with high probability of memory bugs. The difference is very important. I have reached this conclusion some years ago and nothing has change in D since then which make me reconsidering my opinion (including that @safe holes were not fixed). Note, that I do not critique the language, it is fine. It is very good system level language with powerful modelling features. It is not good at verifying memory correctness, because in such languages (unlike managed ones) burden of memory correctness lies mostly on programmer. If he thinks that he can outsource memory correctness to @safe, there is high probability that he would be suddenly surprised.
Re: Null pointer dereferencing in D
On Saturday, 14 June 2014 at 17:05:21 UTC, David Nadlinger wrote: On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote: The case which you described is a not a type safety problem. If a struct type has a non-trivial invariant(), .init allows an object to exist that violates it without an Error being thrown. Arguing that this is not part of the type system would be splitting hairs. David Déjà vu http://forum.dlang.org/thread/mohceehplxdhsdllx...@forum.dlang.org#post-mailman.550.1349377293.5162.digitalmars-d:40puremagic.com https://issues.dlang.org/show_bug.cgi?id=7021 If I not mistaken it was Kenji who updated the init spec.
Re: Null pointer dereferencing in D
On Saturday, 14 June 2014 at 17:05:21 UTC, David Nadlinger wrote: On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote: The case which you described is a not a type safety problem. If a struct type has a non-trivial invariant(), .init allows an object to exist that violates it without an Error being thrown. Arguing that this is not part of the type system would be splitting hairs. David Again, it may depend on your definition of type safety. In my view, it is not related. It is a problem of unwarranted assumption about data correctness in a system level language. By the way, AFAIK the issue has been already filed in bugzilla (closed as wontfix) and discussed in newsgroups. After the discussion the spec was updated to explicitly mention that init property may be problematic http://dlang.org/property.html (please notice, that invariant example is in the spec). Another issue which popped up is that in order to fix disable this() init problem, one need to break assumption about init availability in compile time, which breaks CTFE. In other words, it is impossible to fix the issue without creating a multitude of new problems.
Re: Null pointer dereferencing in D
On Saturday, 14 June 2014 at 15:41:10 UTC, John Colvin wrote:
On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
Why this is a type hole if initializer is explicitly provided?
The idea of disabled this() is to prevent default
initialization,
not to reject potentially buggy one.
Well consider imaginary NotNullable struct that uses "@disable
this()" to guarantee that instance of that struct always has
meaningful state. By using (NotNullable!T).init you can get
value of that type which is in fact null and pass it as an
argument to function that expects NotNullable to always be non
null. With no casts involved you have just circumvented
guarantees static type system was suppose to give.
Hole in the type system: yes
Necessarily a bad thing: no
It depends on what do you mean by type safety. If commonly
accepted definition is chosen (for example, what type safety
article means), than there is no type safety problem here.
Some data-types require runtime initialisation to be valid. By
using .init you are explicitly circumventing any runtime
initialisation. It's an explicit hole, just like cast.
Yes, this is known. But note, that it is user, not the language,
who
circumvents initialization. By the way, what many people expect
from the feature - to have reference which points to
preallocated, valid object is hardly achievable in system level
language where due to free access to memory and memory bugs
reference may hold any value. For example, class object may turn
into integer with value 12345.
class A {}
int I = 12345;
A a = cast(A) I;
With the same reasoning I can say that language is faulting here
because it allowed for me to circumvent my own wishful(!)
assumption that references should always be allocated and point
to valid memory.
The fact that pointer or reference can be null, is a tiny, tiny
problem. You can test for null, but you cannot check whether
pointer contains valid address. For example, try to figure out
whether it is safe to write to address 0xFEFFABCD in some
particular context.
It appears that it possible (in 2.065 at least) for a struct to
provide it's own init, which can of course be
template init() { static assert(false); }
Is the ability to manually specify .init a bug or a feature? I
feel like it's a bug.
As far as I remember the ability to define init property was
since 2.058. The semantic would that if you access init
explicitly, you would get overridden property, but in other cases
(for example allocation) the semantic is of language init.
Probably it was filed as a bug, I don't remember.
Re: Null pointer dereferencing in D
On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
Why this is a type hole if initializer is explicitly provided?
The idea of disabled this() is to prevent default
initialization,
not to reject potentially buggy one.
Well consider imaginary NotNullable struct that uses "@disable
this()" to guarantee that instance of that struct always has
meaningful state. By using (NotNullable!T).init you can get
value of that type which is in fact null and pass it as an
argument to function that expects NotNullable to always be non
null. With no casts involved you have just circumvented
guarantees static type system was suppose to give.
You can complain if language itself produces code which accesses
init property. This would be violation of disable premise.
However, it is clearly you who intentionally asked init property,
so there is no language fault here.
For example, some time ago implicit disable struct creation
issues (in context of array copy, out parameter, etc. ) were
filed and fixed. If you face situation when compiler generates
default disabled struct without user permission, this would be a
bug.
The case which you described is a not a type safety problem.
There is no reinterpretation of object of one type as another
type (or reading/writing memory which should not have been
read/written). It is perfectly safe to assign object of type A to
the same type. What is presented is some sort of design pattern
violated by the user, not the language (and the goal of the
pattern cannot be fully achieved in D language).
Re: Null pointer dereferencing in D
On Saturday, 14 June 2014 at 12:33:28 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote:
Huh? Types with `@disable this()` still have an `init` value.
All it does is disallow instantiating the type without
specifying an initializer (e.g. a struct literal, a value
returned from a factory function, or `static opCall()`).
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
Why this is a type hole if initializer is explicitly provided?
The idea of disabled this() is to prevent default initialization,
not to reject potentially buggy one.
