Re: Precise GC state
On Monday, 27 November 2017 at 06:59:30 UTC, Petar Kirov [ZombineDev] wrote: the shared_ptr itself) and you can't opt out of that even if you're not sharing the shared_ptr with other threads. Well, the compiler can in theory ellide atomics if it csn prove that the memory cannot be accessed by another thread. But it kinda is missing the point that if it only is in a single thread then it would typically only have only one assignment. Shared_ptr is for holding a resource not for using it...
Re: Looking for a job in USA
On 11/26/2017 10:15 PM, Satoshi wrote: Thanks everyone for your advices and helping me with finding job in the US. I applied for about 300 jobs at companies like Apple, M$, Amazon, Google, etc. and got one offer in Canada, so it's half-win for me. :) Good luck! BTW: Walter, why you don't use IP Board instead of this, custom made forum? Because our forum here is better and faster than any of the various forum software we looked at. It's also customized to our particular preferences and needs. If you are not OK with topics like this, why you don't create off-topic category where it should be fine to post topics what are not focused on D? This forum is for D, and supporting off-topic forums is not part of our purpose. I enjoy arguing about politics myself, but not here. I recommend using reddit for politics. For here, I appreciate everyone maintaining professional demeanor and keeping things reasonably about D. If you'd like to review our Code of Conduct: https://www.youtube.com/watch?v=eQRuNwOMzW8&list=PLBFA47360BEAFBC75
Re: Precise GC state
On Monday, 27 November 2017 at 06:47:00 UTC, Dmitry Olshansky wrote: Last time I check shared_ptr can be safely shared across threads, hence RC is takling synchronization and most likely atomics since locks won’t be any better. The controlblock can, but it is crazy to use shared_ptr for anything more than high level ownership. It is a general solution with weak pointers and extra indirection, not a typical RC implementation for datastructures. In C++ sync is manual, which is the only efficient way to do ??? shared_ptr is nowhere manual. There is an upcoming atomic_shared_ptr, but it is not in the standard yet. My post is about particular primitive in C++ std, what could be done instead or in addition to is not important. Oh, but it is. 1. D currently does not provide what you says it does. 2. Sane C++ programmers rarely use shared_ptr for more than exchsnging ownership (suitable for sharing things like bitmap textures). There are plenty of other RC implementations for tracking memory. So you compare apples and oranges.
Re: Precise GC state
On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad wrote: On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky wrote: likely via RAII. Not to mention cheap (thread-local) Ref Counting, C++ and many other language have to use atomics which makes RC costly. No, you dont. Nobody in their right mind would do so in C++ as a general solution. Seems there is trend in doing D-advocacy based on the assumption that programmers using other languages are crazy these days. In C++ sync is manual, which is the only efficient way to do it. Proving correctness for an efficient general solution is an unsolved theoretical problem. You can do it for high level mechanisms, but not low level atm. Rust and Pony claims to have solutions, but they are not general. D most certainly does not have it and never will. When threading is a libray type then you cannot achieve more in D than you can achieve in C++, i.e. Shared is not going to do more than a C++ library type with a separate static analysis tool. What I think Dmitry meant is that shared_ptr uses atomic instructions for the reference counting (though you need to use atomic_shared_ptr, or atomic_* function if you want to modify the shared_ptr itself) and you can't opt out of that even if you're not sharing the shared_ptr with other threads. On the other hand in D, a properly designed SharedPtr(T) will use atomic instructions for reference counting, only if it's payload type T is has the 'shared' type qualifier. And if you have 'shared(SharedPtr(T))', only then you'll have atomic instructions for the SharedPtr struct itself, but unlike shared_ptr, you won't have access to the non-thread safe methods.
Re: Precise GC state
On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad wrote: On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky wrote: likely via RAII. Not to mention cheap (thread-local) Ref Counting, C++ and many other language have to use atomics which makes RC costly. No, you dont. Nobody in their right mind would do so in C++ as a general solution. Seems there is trend in doing D-advocacy based on the assumption that programmers using other languages are crazy these days. Last time I check shared_ptr can be safely shared across threads, hence RC is takling synchronization and most likely atomics since locks won’t be any better. In C++ sync is manual, which is the only efficient way to do ??? shared_ptr is nowhere manual. Sorry but the rest of the of post is take a direction into the fog, that I don’t want to follow. My post is about particular primitive in C++ std, what could be done instead or in addition to is not important.
Re: Thoughts about D
On 11/26/2017 9:11 PM, Neia Neutuladh wrote: The culprit for the C# version's poor performance was System.String.Substring, which allocates a copy of its input data. So "Hello world".Substring(5) creates a new char* pointing at a new memory allocation containing "Hello\0". C++'s std::string does the same thing. So if I reimplemented subtex naively in C++, its performance would be closer to the C# version than to the D version. I could probably get slightly better performance than the D version by writing a special `stringslice` struct. But that's a lot of work, and it's currently just barely fast enough that I realize that I've actually run the command instead of my shell inexplicably swallowing it. 0 terminated strings in C (and C++) have always been a severe performance issue for programs that deal a lot in strings, for these reasons: 1. To get a substring, a copy must be made, meaning also that storage allocated and managed for it. 2. To do most operations on it, you need to do a strlen() or equivalent. You can always write your own string package to deal with, and I've written many :-( and they all failed for one reason or another, mostly because about everything in the C/C++ ecosystem is built around 0 terminated strings.
Re: Precise GC state
On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky wrote: likely via RAII. Not to mention cheap (thread-local) Ref Counting, C++ and many other language have to use atomics which makes RC costly. No, you dont. Nobody in their right mind would do so in C++ as a general solution. Seems there is trend in doing D-advocacy based on the assumption that programmers using other languages are crazy these days. In C++ sync is manual, which is the only efficient way to do it. Proving correctness for an efficient general solution is an unsolved theoretical problem. You can do it for high level mechanisms, but not low level atm. Rust and Pony claims to have solutions, but they are not general. D most certainly does not have it and never will. When threading is a libray type then you cannot achieve more in D than you can achieve in C++, i.e. Shared is not going to do more than a C++ library type with a separate static analysis tool.
Re: Thoughts about D
On Monday, 27 November 2017 at 01:03:29 UTC, Adam Wilson wrote: On 11/26/17 16:14, IM wrote: Hi, I'm a full-time C++ software engineer in Silicon Valley. I've been learning D and using it in a couple of personal side projects for a few months now. [snip] I could add more, but I'm tired of typing. I hope that one day I will overcome my frustrations as well as D becomes a better language that enables me to do what I want easily without standing in my way. Well. D has it's own idioms and patterns. So we fully expect some of the idioms that are easy in C++ to be not easy in D, and indeed that's kind of the point. If you look at the those idioms that are hard in D, it's probably because said idiom allows you to do some fantastically unsafe (and insecure) thing in C++. Yes, I am sure that it gives some performance boost, but D is not trying to be the pinnacle of language performance. It sure does. Otherwise there are plenty languages that are safe and somewhat fast. C# or Java fit the bill nicely. Also Go. D is trying to be a memory-safe language, quite intentionally And thus @system is the default, right? I think memory safety came as an afterthought. at the expense of speed (see this DConf 2017 talk: https://www.youtube.com/watch?v=iDFhvCkCLb4&index=1&list=PL3jwVPmk_PRxo23yyoc0Ip_cP3-rCm7eB). Bounds checking by default, GC, etc. are all memory safety features that come explicitly at the cost of performance. We are not trying to be C++ True, albeit doesn’t feel like that. and we are not trying to replace C++ Patently false. It sounds like C++ works better for you. We are OK with that. We always recommend using what works best for you. That is after all why WE are here. :) That WE might have been just you :) D certainly tries to replace C++ in a number of ways. It’s not a drop-in replacement and doesn’t cover all of C++ niche.
Re: Looking for a job in USA
Thanks everyone for your advices and helping me with finding job in the US. I applied for about 300 jobs at companies like Apple, M$, Amazon, Google, etc. and got one offer in Canada, so it's half-win for me. :) Thanks! BTW: Walter, why you don't use IP Board instead of this, custom made forum? If you are not OK with topics like this, why you don't create off-topic category where it should be fine to post topics what are not focused on D?
Re: Thoughts about D
On Monday, 27 November 2017 at 05:11:06 UTC, Neia Neutuladh wrote: You might say that I could use C++ style manual memory management and get even better performance. And you'd be wrong. No... Not if you do it right, but it takes more planning. I.e. Design. Which is why scripting and high level languages dont use it. std::string does the same thing. So if I reimplemented subtex naively in C++, its performance would be closer to the C# version than to the D version. You meant stupidly, you would rather use std::string_view for string references in C++. std::string is a library convenience type that typically is only used for debugging and filenames. If you want performance then it really isnt possible to make do with a fixed library type for strings so in a realistic program people would write their own. I could probably get slightly better performance than the D version by writing a special `stringslice` struct. But that's a lot of work, No... On the whole, it sounds like you don't like D because it's not C++. Which is fine, but D isn't going to become C++. Sure. But maybe you shouldn't use a tiny 400k input when discussing performance. Try to think about how many instructions a CPU executes in 50ms... If you dont know C++ then it makes no sense for you to compare performance to C++.
Re: Precise GC state
On Sunday, 26 November 2017 at 18:58:04 UTC, jmh530 wrote: On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky wrote: If all of the code is 100% @safe (not system and not trusted) you have a different language where write barriers would be cheaper to implement. Sadly you can’t “skip” write barriers in your @system code because it may run as part of larger @safe. Which is where they are the most costly. I was thinking you would use a generational or precise GC for @safe code and then fall back to the normal GC with @system/@trusted code. Wishful thinking. Memory flows through a program and things allocated in @safe get passed to @system (including the last reference cases) and vise versa. Also in D generational hypothesis may not bear as much value due to stack-allocation, libc heap allocations for temporaries likely via RAII. Not to mention cheap (thread-local) Ref Counting, C++ and many other language have to use atomics which makes RC costly. Basically the GC heap is not all of the heap, so a young objects is even smaller part of that. Lastly it is telling that new low-latency concurrent GCs do away without explicit generations. I’m thinking a more efficient way to takle temporaries would be to add Regions to GC. So the moment you enter a region all GC things are allocated in a special segment, once you leave it free the segment. The last trick is to tweak memory protection as guard pages over it. Boom! Now if somebody touches it - DanglingPointerException :) Not a panacea but: - libraries using too much of GC can be controlled (unless they build global state) - manual memory management without memory corruption - fast bump allocation, which is what all of sensible VM languages do And no need to create entire separate heap with its own generational schema. Not sure if that's possible or not, but in my head it would be a separate heap from the @safe code. And then I do append in @system on array allocated in @safe. Boom! Certainly would be added complexity.
Re: Thoughts about D
On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote: - It's quite clear that D was influenced a lot by Java at some point, which led to borrowing (copying?) a lot of Java features that may not appeal to everyone. Have you observed a human to exist who has complained about a specific feature in D that is similar to a feature in Java? Relaying their complaints would be much more useful. - The amount of trickeries required to avoid the GC and do manual memory management are not pleasant and counter productive. I feel they defeat any productivity gains the language was supposed to offer. Since so much of C++'s coding style revolves around memory management, the idea that you might be able to avoid manual memory management and still not see a giant reduction in performance is transformative. It means writing code in an entirely different style. And because Java is the point of comparison for using a garbage collector, it's easy to think that a GC is impossibly inefficient. But that's because Java abuses its GC so heavily (and because Java came out in an era when having 64MB of RAM on a home computer was pretty swish). Let's compare with how D uses the GC. Here's an example of code that I wrote in the most obvious way possible that is more efficient than the equivalent in C++, specifically because of the garbage collector: https://github.com/dhasenan/subtex The only nods to performance in that are when I have various Appenders reserve some space in advance. On my 410KB reference document, this completes in 50ms. (That's 90ms faster than a Java "hello world" program.) I ported it to C# for comparison, and it took over one second. I ran a GC profiler and discovered that it allocated 4GB in string data. The D version, by contrast, allocates a total of 12MB, runs three GC collections, and has a total pause time under 1ms. (If I add a call to `GC.collect()` just before the application exits, the total pause time exceeds 1ms but is still below 2ms.) You might say that I could use C++ style manual memory management and get even better performance. And you'd be wrong. The culprit for the C# version's poor performance was System.String.Substring, which allocates a copy of its input data. So "Hello world".Substring(5) creates a new char* pointing at a new memory allocation containing "Hello\0". C++'s std::string does the same thing. So if I reimplemented subtex naively in C++, its performance would be closer to the C# version than to the D version. I could probably get slightly better performance than the D version by writing a special `stringslice` struct. But that's a lot of work, and it's currently just barely fast enough that I realize that I've actually run the command instead of my shell inexplicably swallowing it. On the whole, it sounds like you don't like D because it's not C++. Which is fine, but D isn't going to become C++.
Re: Thoughts about D
On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote: - D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers gave a talk about the last thing D needs, which is a guy like him writing a lot of books covering the many subtleties of the language. However, it seems that the D community went ahead and created exactly this language! btw. I found this interesting article from Rob Pike (golang). https://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html He discusses the reasons why C++ developers are *not* flocking to Go...which interestingly, is the very opposite with regards to D (well 'flocking' might be a slight over exaggeration ;-) Neither (Go's) 'unnecessarily small philosophy', or (C++'s) 'unnecessarily huge philosophy' are good design philosophies. Go programmers will eventually look for 'more', and C++ programmers will continue to look for 'less'. "When all the forces acting upon an object balance each other, the object will be at equilibrium."
Re: Thoughts about D
On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote: I'm a full-time C++ software engineer in Silicon Valley. I've been learning D and using it in a couple of personal side projects for a few months now. First of all, I must start by saying that I like D, and wish to use it everyday. I'm even considering to donate to the D foundation. However, some of D features and design decisions frustrates me a lot, and sometimes urges me to look for an alternative. I'm here not to criticize, but to channel my frustrations to whom it may concern. I want D to become better and more widely used. I'm sure many others might share with me some of the following points: Forum discussions are valuable venue. Since you are in Silicon Valley, you might also consider attending one of the Silicon Valley D meetups (https://www.meetup.com/D-Lang-Silicon-Valley). It's hard to beat face-to-face conversations with other developers to get a variety of perspectives. The ultimate would be DConf, if you can manage to attend.
Re: Thoughts about D
On 11/26/2017 4:14 PM, IM wrote: I'm a full-time C++ software engineer in Silicon Valley. I've been learning D and using it in a couple of personal side projects for a few months now. Great! Glad you're enjoying it and took the time to post your thoughts. - D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers gave a talk about the last thing D needs, which is a guy like him writing a lot of books covering the many subtleties of the language. However, it seems that the D community went ahead and created exactly this language! You'll find the same language in 2014 as today, it hasn't changed much. All languages (except C) in common use accrete features. D does have some baggage that has been removed, like `typedef`, but on the whole whenever we try to remove something, someone always has built their store around it. The good news, however, is just use the subset of D that works for you. - D is very verbose. It requires a lot of typing. Look at how long 'immutable' is. Very often that I find myself tagging my methods with something like 'final override nothrow @safe @nogc ...' etc. The idea is if you just want to write code, you can eschew using them (except 'override'), and just write code. They're all used for optimization or to provide enforceable self-documentation. Other languages would require those to be documented in the comments, which is not enforceable and even more wordy :-) 'override' is as opposed to 'virtual' which C++ requires and D doesn't. - It's quite clear that D was influenced a lot by Java at some point, which led to borrowing (copying?) a lot of Java features that may not appeal to everyone. That's true. Java looked like it was going to take over the world when D was young. These days I'd get rid of inner classes in favor of lambdas if I could, but you can just ignore inner classes. - The amount of trickeries required to avoid the GC and do manual memory management are not pleasant and counter productive. I feel they defeat any productivity gains the language was supposed to offer. That's true. But it's hard to beat GC for just writing code and getting it to run safely and without pointer bugs. - The thread local storage, shared, and __gshared business is annoying and doesn't seem to be well documented, even though it is unnatural to think about (at least coming from other languages). The idea with TLS is to deal with endemic threading bugs other languages have. The default in C/C++ is for globals to be shared, which is completely impractical to examine a large code base for. __gshared is meant to stand out and be greppable, making code much more auditable. - D claims to be a language for productivity, but it slows down anyone thinking about efficiency, performance, and careful design decisions. (choosing structs vs classes, structs don't support hierarchy, use alias this, structs don't allow default constructors {inconsistent - very annoying}, avoiding the GC, look up that type to see if it's a struct or a class to decide how you may use it ... etc. etc.). D structs are value types, and classes are reference types. Everything flows from that. C++ structs and classes are the same thing, and can be used as both reference and value types at the same time, whether that works or not. I rarely find C++ classes with documentation saying if they are intended as a reference or value type, and the documentation won't prevent one from misusing it. I'm not the only one to suggest that making the value/ref design decision is a pretty crucial one to make before designing the code. :-) I could add more, but I'm tired of typing. I hope that one day I will overcome my frustrations as well as D becomes a better language that enables me to do what I want easily without standing in my way. Many people have difficulty with D when coming from, say, C++, because it does require a different way of thinking about code. This passes once one gains experience and comfort with D. After all, my early Fortran code looked just like BASIC, my C code looked like Fortran, my C++ code looked like "C with a few classes", and my D code looked a bit too much like C++ :-) I have recently finished converting the Digital Mars C++ compiler front end from "C with classes" to D. Even though it is a rote line-by-line translation, it simply looks better in D (much less of a snarl). Over time, as I refactor bits of it, it'll steadily look better. I find it significantly easier to write good looking code in D, and it is less verbose than C++. For some trivial examples, C++: unsigned long long D: ulong C++: template struct S { ... }; D: struct S(T) { ... } C++: for (int i = 0; i < 10; ++i) D: foreach (i; 0..10) C++: decltype D: auto
Re: Thoughts about D
On 27/11/2017 12:14 AM, IM wrote: snip - D is very verbose. It requires a lot of typing. Look at how long 'immutable' is. Very often that I find myself tagging my methods with something like 'final override nothrow @safe @nogc ...' etc. There be solutions here! struct Foo { final nothrow @safe @nogc { void a() {} void b() {} } }
Re: Precise GC state
On Sunday, 26 November 2017 at 19:11:08 UTC, Jonathan M Davis wrote: It wouldn't work. @safe code and @system code call each other all the time (using @trusted where necessary), and they freely exchange stuff that was allocated on the GC heap. [snip] I see. Fair enough.
Re: Thoughts about D
On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote: - D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers gave a talk about the last thing D needs, which is a guy like him writing a lot of books covering the many subtleties of the language. However, it seems that the D community went ahead and created exactly this language! IMO, I don't think it's too bad. I'd rather have those features, than not have them. One of the best features of D is it's modeling power. Due to the rich feature set of D, you can model your code exactly how you think about it; you don't have to change the way you think about a problem to accommodate the limitations of your programming language. Furthermore, compared to C++, the end results is MUCH better. I've written a small memory-mapped IO library in both C++ and D. It heavily leverages templates and compile-time features of both languages. The C++ version turned into a monstrosity that even I, the author, couldn't understand. The D version was quite beautiful and elegant, much less verbose, and even had a few features I couldn't figure out how to do in C++. - D is very verbose. It requires a lot of typing. Look at how long 'immutable' is. Very often that I find myself tagging my methods with something like 'final override nothrow @safe @nogc ...' etc. I agree, but I don't think it's as bad as C++ (see my comment above). But, unfortunately, D has chosen the wrong defaults, IMO: (1) We should be opting out of @safe, not opting into it (2) D should be final-by-default (See https://wiki.dlang.org/Language_design_discussions#final-by-default for how that got shot down) (3) Perhaps D should be nothrow by default, but I'm not sure exactly how that would work (4) As a systems programming language first and an applications programming language second, I argue that the GC should be something we opt into, not opt out of. With `scope` and DIP 1000 features, we may eventually get there. (5) I think variables should be `immutable` by default like they are in Rust, but others disagree. You get the idea. I think part of this is due to historical accidents. D is, unfortunately, carrying a lot of technical debt. - It's quite clear that D was influenced a lot by Java at some point, which led to borrowing (copying?) a lot of Java features that may not appeal to everyone. Many seem to think of D as a better C++, but like you, I see more of an influence from Java too. I like the convenience of *some* of those Java-like features. So, I consider the influence of Java somewhat of a strength in D. - The amount of trickeries required to avoid the GC and do manual memory management are not pleasant and counter productive. I feel they defeat any productivity gains the language was supposed to offer. I agree. See the documentation for `scope` and DIP1000. I think the situation may get better if we can continue momentum on those features. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md There's also been some recent work this month on RAII with -betterC which may be of interest to you. But I still see -betterC as a copout, avoiding the difficult work of decoupling the compiler from the runtime. - The thread local storage, shared, and __gshared business is annoying and doesn't seem to be well documented, even though it is unnatural to think about (at least coming from other languages). I think the thread local storage is a great feature of D. It's one of the defaults that D actually got right. I don't care for the double-underscore convention of __gshared that seems to be borrowed from C, but we're lucky to have it. It comes in handy sometimes. It's hard to know what difficulty users encounter when reading the documentation. If you think it can be improved, please submit a pull request to https://github.com/dlang/dlang.org - D claims to be a language for productivity, but it slows down anyone thinking about efficiency, performance, and careful design decisions. (choosing structs vs classes, structs don't support hierarchy, use alias this, structs don't allow default constructors {inconsistent - very annoying}, avoiding the GC, look up that type to see if it's a struct or a class to decide how you may use it ... etc. etc.). I run into those design dilemmas any time I start learning a new programming language, even with highly productive languages like C#. It takes time for me to work through a few ideas and finally arrive at the right idioms that work. But once they get worked out, it's cooking with gas. I could add more, but I'm tired of typing. I hope that one day I will overcome my frustrations as well as D becomes a better language that enables me to do what I want easily without standing in my way. Thanks for sharing your thoughts. It's always interesting to hear what people think. Mike
Re: Thoughts about D
On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote: Hi, I'm a full-time C++ software engineer in Silicon Valley. I've been learning D and using it in a couple of personal side projects for a few months now. First of all, I must start by saying that I like D, and wish to use it everyday. I'm even considering to donate to the D foundation. However, some of D features and design decisions frustrates me a lot, and sometimes urges me to look for an alternative. I'm here not to criticize, but to channel my frustrations to whom it may concern. I want D to become better and more widely used. I'm sure many others might share with me some of the following points: - D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers gave a talk about the last thing D needs, which is a guy like him writing a lot of books covering the many subtleties of the language. However, it seems that the D community went ahead and created exactly this language! - D is very verbose. It requires a lot of typing. Look at how long 'immutable' is. Very often that I find myself tagging my methods with something like 'final override nothrow @safe @nogc ...' etc. - It's quite clear that D was influenced a lot by Java at some point, which led to borrowing (copying?) a lot of Java features that may not appeal to everyone. - The amount of trickeries required to avoid the GC and do manual memory management are not pleasant and counter productive. I feel they defeat any productivity gains the language was supposed to offer. - The thread local storage, shared, and __gshared business is annoying and doesn't seem to be well documented, even though it is unnatural to think about (at least coming from other languages). - D claims to be a language for productivity, but it slows down anyone thinking about efficiency, performance, and careful design decisions. (choosing structs vs classes, structs don't support hierarchy, use alias this, structs don't allow default constructors {inconsistent - very annoying}, avoiding the GC, look up that type to see if it's a struct or a class to decide how you may use it ... etc. etc.). I could add more, but I'm tired of typing. I hope that one day I will overcome my frustrations as well as D becomes a better language that enables me to do what I want easily without standing in my way. Hi and welcome here, I've been using D for 10 years (fulltime since 3), and my frustrations almost mirrors yours. Probably the C++background? I don't think D complexity negates productivity in the long run, but you get to avoid a lot of the language in daily operations. For me: pure, shared, synchronized and TLS-by-default are _not_ pulling their weight (off the top of my head). Being a language "that can do what C++ can do" comes with large requirements both in capabilities and standard library. A language also seems more complex when we are more interested in it and eager to learn details (C++ may teach you to give up early on that point). If you think about it, D has only l-values and r-values which is much simpler than where we were before. Actually I think a "Scott Meyers of D" would have difficulty coming up with four books of guidelines. The good news is that you _can_ learn D in excrutiating detail, it's not something out of reach during a lifespan. The bad news is that the language accumulated complexity at one point and it can only be a long neural process (though initial familiarity helps a lot). I don't think anyone would have described D1 as verbose! (Now defending no-default-constructor-for-structs: it's because S.init is supposed to be a valid struct - which implies your destructors should be reentrant. Buy the book for 50+ other tips)
Re: Thoughts about D
On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote: - D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers gave a talk about the last thing D needs, which is a guy like him writing a lot of books covering the many subtleties of the language. However, it seems that the D community went ahead and created exactly this language! I hear this argument a lot, about this language or that. It has become an argument void of any real value, in my view. The reason is, programming needs have changed a lot, the problems being solved have changed alot, there is a great diversity in how people think about solving those problems, and a greater need to solve problems that are not solvable with current langauges. So languages necessarily evolve according to the pressures put upon them by the environment in which they exist. As for using features from other languages, this is a normal process of evolution - convergent evolution. A language that is getting smaller, is NOT a language that is evolving (such a language is useful in a particular domain only). The question is really not how 'huge' a language should or should not be. The question is how we can grasp that hugeness. The universe is huge, and extremely complex. But it can be understood (to an extent) according to some pretty basic principles. The human brain is equally 'huge' and 'complex'...but we are slowly coming to grips with (some of) it's basic princplez (deliberate spelling mistake for my friends ;-). - D is very verbose. It requires a lot of typing. Look at how long 'immutable' is. Very often that I find myself tagging my methods with something like 'final override nothrow @safe @nogc ...' etc. Sorry..what. You program in C++ and you're saying D is very verbose ;-) I do think though, that function headers are becoming far too long but this maybe something that one just has to accept, if one wants to have those choices. i.e. You can only really make them shorter, by not allowing the programmer to have those choices. And if D is about anything, it's about programmer choices. - D claims to be a language for productivity, but it slows down anyone thinking about efficiency, performance, and careful design decisions. (choosing structs vs classes, structs don't support hierarchy, use alias this, structs don't allow default constructors {inconsistent - very annoying}, avoiding the GC, look up that type to see if it's a struct or a class to decide how you may use it ... etc. etc.). Some very smart people who design programming languages think ALL inheritance should be completely banned. I'd be very happy if that were the case. Personally, I find it very easy to be productive in D, without classes. It's annoying language/library bugs that slow down my productivity. But think of D as a work in progress...like galaxies crashing into each other.. it doesn't happen very often..so enjoy it while you can.
Re: Thoughts about D
On 11/26/17 16:14, IM wrote: Hi, I'm a full-time C++ software engineer in Silicon Valley. I've been learning D and using it in a couple of personal side projects for a few months now. First of all, I must start by saying that I like D, and wish to use it everyday. I'm even considering to donate to the D foundation. However, some of D features and design decisions frustrates me a lot, and sometimes urges me to look for an alternative. I'm here not to criticize, but to channel my frustrations to whom it may concern. I want D to become better and more widely used. I'm sure many others might share with me some of the following points: - D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers gave a talk about the last thing D needs, which is a guy like him writing a lot of books covering the many subtleties of the language. However, it seems that the D community went ahead and created exactly this language! - D is very verbose. It requires a lot of typing. Look at how long 'immutable' is. Very often that I find myself tagging my methods with something like 'final override nothrow @safe @nogc ...' etc. - It's quite clear that D was influenced a lot by Java at some point, which led to borrowing (copying?) a lot of Java features that may not appeal to everyone. - The amount of trickeries required to avoid the GC and do manual memory management are not pleasant and counter productive. I feel they defeat any productivity gains the language was supposed to offer. - The thread local storage, shared, and __gshared business is annoying and doesn't seem to be well documented, even though it is unnatural to think about (at least coming from other languages). - D claims to be a language for productivity, but it slows down anyone thinking about efficiency, performance, and careful design decisions. (choosing structs vs classes, structs don't support hierarchy, use alias this, structs don't allow default constructors {inconsistent - very annoying}, avoiding the GC, look up that type to see if it's a struct or a class to decide how you may use it ... etc. etc.). I could add more, but I'm tired of typing. I hope that one day I will overcome my frustrations as well as D becomes a better language that enables me to do what I want easily without standing in my way. Well. D has it's own idioms and patterns. So we fully expect some of the idioms that are easy in C++ to be not easy in D, and indeed that's kind of the point. If you look at the those idioms that are hard in D, it's probably because said idiom allows you to do some fantastically unsafe (and insecure) thing in C++. Yes, I am sure that it gives some performance boost, but D is not trying to be the pinnacle of language performance. D is trying to be a memory-safe language, quite intentionally at the expense of speed (see this DConf 2017 talk: https://www.youtube.com/watch?v=iDFhvCkCLb4&index=1&list=PL3jwVPmk_PRxo23yyoc0Ip_cP3-rCm7eB). Bounds checking by default, GC, etc. are all memory safety features that come explicitly at the cost of performance. We are not trying to be C++ and we are not trying to replace C++. It sounds like C++ works better for you. We are OK with that. We always recommend using what works best for you. That is after all why WE are here. :) -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Thoughts about D
Hi, I'm a full-time C++ software engineer in Silicon Valley. I've been learning D and using it in a couple of personal side projects for a few months now. First of all, I must start by saying that I like D, and wish to use it everyday. I'm even considering to donate to the D foundation. However, some of D features and design decisions frustrates me a lot, and sometimes urges me to look for an alternative. I'm here not to criticize, but to channel my frustrations to whom it may concern. I want D to become better and more widely used. I'm sure many others might share with me some of the following points: - D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers gave a talk about the last thing D needs, which is a guy like him writing a lot of books covering the many subtleties of the language. However, it seems that the D community went ahead and created exactly this language! - D is very verbose. It requires a lot of typing. Look at how long 'immutable' is. Very often that I find myself tagging my methods with something like 'final override nothrow @safe @nogc ...' etc. - It's quite clear that D was influenced a lot by Java at some point, which led to borrowing (copying?) a lot of Java features that may not appeal to everyone. - The amount of trickeries required to avoid the GC and do manual memory management are not pleasant and counter productive. I feel they defeat any productivity gains the language was supposed to offer. - The thread local storage, shared, and __gshared business is annoying and doesn't seem to be well documented, even though it is unnatural to think about (at least coming from other languages). - D claims to be a language for productivity, but it slows down anyone thinking about efficiency, performance, and careful design decisions. (choosing structs vs classes, structs don't support hierarchy, use alias this, structs don't allow default constructors {inconsistent - very annoying}, avoiding the GC, look up that type to see if it's a struct or a class to decide how you may use it ... etc. etc.). I could add more, but I'm tired of typing. I hope that one day I will overcome my frustrations as well as D becomes a better language that enables me to do what I want easily without standing in my way.
Re: Precise GC state
On Sunday, 26 November 2017 at 19:11:08 UTC, Jonathan M Davis wrote: We can't even have different heaps for immutable and mutable stuff, because it's very common to construct something as mutable and then cast it to immutable (either explicitly or This is easy to fix, introduce a uniquely owned type (isolated) that only can transition to immutable. So it is more about being willing to tighten up the semantics. Same thing with GC, but everything has a cost. That said Adam has a point with getting more users, it isnt obvious that the costs wouldnt be offset by increased interest. Anyway, it seems like C# and Swift are pursuing the domain D is in by gradually expanding into more performance oriented programming mechanisms... We'll see.
Re: Precise GC state
On Sunday, November 26, 2017 18:58:04 jmh530 via Digitalmars-d wrote: > On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky > > wrote: > > If all of the code is 100% @safe (not system and not trusted) > > you have a different language where write barriers would be > > cheaper to implement. > > > > Sadly you can’t “skip” write barriers in your @system code > > because it may run as part of larger @safe. Which is where they > > are the most costly. > > I was thinking you would use a generational or precise GC for > @safe code and then fall back to the normal GC with > @system/@trusted code. Not sure if that's possible or not, but in > my head it would be a separate heap from the @safe code. > Certainly would be added complexity. It wouldn't work. @safe code and @system code call each other all the time (using @trusted where necessary), and they freely exchange stuff that was allocated on the GC heap. Heck, it's not even possible to have per-thread heaps (much as that would be desirable), because stuff can be passed between threads, and you can freely cast between shared and non-shared. You do have to be careful about it if you don't want to have problems, but just like @safe code can call @trusted code such that it's possible for @safe code be calling code that was vetted for memory safety by a programmer rather than the compiler, you can have code that casts to and from shared and works perfectly well so long as the programmer vets it properly. We can't even have different heaps for immutable and mutable stuff, because it's very common to construct something as mutable and then cast it to immutable (either explicitly or because it's returned from a pure function which is able to do the cast implicitly, because it knows that the return value couldn't possibly have been passed into the function and thus had to have been allocated inside it). D's type system protects you from all kinds of dumb mistakes, but it has way too many backdoors for the kind of stuff that requires that things be locked down like they would be inside a VM like Java has. Ultimately, if you're talking about a GC and what it can and can't do, I expect that there's very little difference between C and D in terms of what you types of GC you can get away with. D does protect the programmer, but ultimately, it lets you do just about anything that C lets you do if you really want to, and any GC that we use has to work with that. - Jonathan M Davis
Re: Precise GC state
On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky wrote: If all of the code is 100% @safe (not system and not trusted) you have a different language where write barriers would be cheaper to implement. Sadly you can’t “skip” write barriers in your @system code because it may run as part of larger @safe. Which is where they are the most costly. I was thinking you would use a generational or precise GC for @safe code and then fall back to the normal GC with @system/@trusted code. Not sure if that's possible or not, but in my head it would be a separate heap from the @safe code. Certainly would be added complexity.
Re: DIP 1006 - Preliminary Review Round 1
On 26/11/2017 11:59 AM, Joseph Rushton Wakeling wrote: On Tuesday, 21 November 2017 at 14:15:30 UTC, Martin Nowak wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md Has come up a couple of times and it's a good idea to allow more control over which checks are enabled. I find the suggested switch levels a bit counter-intuitive and would suggest -release=assert,in,out,invariant to be the equivalent of the current -release while allowing to enable any subset I like the idea of specializing the meaning of the -release flag via optional arguments. One suggestion: replace -release=assert with -release=body, so in the above, you would have: -release=body,in,out,invariant ... which has the nice intuitive property of specifying _which bits of code_ release criteria will be applied to. In other words, -release=body would result in asserts being removed from function bodies _and only there_. That would make clearer that we're not removing asserts from e.g. unittests (or indeed contracts or invariants). Agreed that looks good +1
Re: DIP 1006 - Preliminary Review Round 1
On Tuesday, 21 November 2017 at 14:15:30 UTC, Martin Nowak wrote: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md Has come up a couple of times and it's a good idea to allow more control over which checks are enabled. I find the suggested switch levels a bit counter-intuitive and would suggest -release=assert,in,out,invariant to be the equivalent of the current -release while allowing to enable any subset I like the idea of specializing the meaning of the -release flag via optional arguments. One suggestion: replace -release=assert with -release=body, so in the above, you would have: -release=body,in,out,invariant ... which has the nice intuitive property of specifying _which bits of code_ release criteria will be applied to. In other words, -release=body would result in asserts being removed from function bodies _and only there_. That would make clearer that we're not removing asserts from e.g. unittests (or indeed contracts or invariants).
Re: Precise GC state
On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky wrote: Sadly you can’t “skip” write barriers in your @system code because it may run as part of larger @safe. Which is where they Well, you can if you carefully lock the gc runtime or if you dont modify existing scannable pointers that points to existing objects (e.g. You could fill an empty array of pointers in unsafe code or pointers that point to something unscannable.), but all unsafe code would need vetting. So it isnt impossible technically, but it is impossible without a change of philosophy.
Re: Precise GC state
On Sunday, 26 November 2017 at 04:01:31 UTC, jmh530 wrote: On Friday, 24 November 2017 at 05:53:37 UTC, Dmitry Olshansky wrote: A better GC is a great direction. Generational one is not feasible unless we disallow quite a few of our features. What about @safe? If all of the code is 100% @safe (not system and not trusted) you have a different language where write barriers would be cheaper to implement. Sadly you can’t “skip” write barriers in your @system code because it may run as part of larger @safe. Which is where they are the most costly.
Re: .NET introduces Span, basically D slices
On Sunday, 26 November 2017 at 05:36:15 UTC, Guy wrote: It's funny you say that because they just announced the introduction of ranges and I believe they return Spans. Well, basic dataflow pipelines with implicit transfer of buffer ownership. So it is a language feature with implicit RAII lifetime management, which is why Span is limited to the stack. Then they have a counterpart to Span called Memory that can be stored on th GC heap. A reasonable tradeoff, but a general constraint would have been more interesting.