Re: Inout unclearness
On Wednesday, 22 July 2015 at 06:14:04 UTC, Max Klimov wrote: In this case I hope generated code will be the same. That's unsafe. Unsafe behavior should require a cast or something like that.
Re: Inout unclearness
How about this? const(A) f(const(B) b); auto constBack(R,P)(const R r, P p); Then invoke: B b; A a = f(b).constBack(b); So `f` takes const parameters and returns const result, you feed the result to the function `constBack` with one of parameters and it infers constness from that parameter and casts the result to the inferred constness.
What about GDC and LDC after DMD becomes D?
Once the front end of DMD becomes fully D, I read that the backend will also become D, but then what will happen to GDC and LDC whose backends are C++ IIUC? -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
Re: What about GDC and LDC after DMD becomes D?
On Wednesday, 22 July 2015 at 11:42:24 UTC, Shriramana Sharma wrote: Once the front end of DMD becomes fully D, I read that the backend will also become D, but then what will happen to GDC and LDC whose backends are C++ IIUC? I don't see an issue there. A compiler is a program that implements a standard, as long as it generates good asm it could be written in brainfuck there would be no reason to care. A D compiler written in D is a symbol, and D was written so that D-programmers could stop writting so much C++ so the idea of a DMD written in D is appealing, but that doesn't mean that all D compilers have to be written in D. The only question is "Do they copy DMD correctly?". There is no doubt that it is doable in C++.
Re: What about GDC and LDC after DMD becomes D?
On Wednesday, 22 July 2015 at 11:42:24 UTC, Shriramana Sharma wrote: Once the front end of DMD becomes fully D, I read that the backend will also become D, but then what will happen to GDC and LDC whose backends are C++ IIUC? The Rust compiler is written in Rust but uses LLVM as a backend, like LDC. I don't know the complexities of linking a D frontend with a C++ backend, but if the Rust team can do it, I'm sure that means GDC and LDC will continue to live on.
Re: What about GDC and LDC after DMD becomes D?
On Wed, 22 Jul 2015 17:12:14 +0530 Shriramana Sharma via Digitalmars-d wrote: > Once the front end of DMD becomes fully D, I read that the backend > will also become D, but then what will happen to GDC and LDC whose > backends are C++ IIUC? > They will use same dmd frontend written in D.
Re: dmd 2.068, 2.069, 2.0xx Evil Plan going forward
On Monday, 20 July 2015 at 21:10:57 UTC, Martin Nowak wrote: 6. Convert the back end to D as well. Waste of time IMO, there is nothing to gain here. - We already have a working C++ backend and can interface that from ddmd, the other compilers will have to work with a C++ interface anyhow. Just translating doesn't improve anything for D users. - The backend generates pretty bad code, we'll never be able to catch up with good optimizers. Why should we invest in an outdated backend? - Bugs in the backend are among the worst for users and time consuming to fix. Translating the backend risks to introduce new bugs.
3D Character Animations for character modeling & Regging
We Provide the best Character Modelling & Regging animation Service Worldwide. we design high & low poly 3D character modeling, rigging, animation, game assets with special effects and more. If any one is interested in any work done you can contact me from my website. Gameyan.com
Re: What about GDC and LDC after DMD becomes D?
On Wednesday, 22 July 2015 at 12:02:50 UTC, Xinok wrote: On Wednesday, 22 July 2015 at 11:42:24 UTC, Shriramana Sharma wrote: Once the front end of DMD becomes fully D, I read that the backend will also become D, but then what will happen to GDC and LDC whose backends are C++ IIUC? The Rust compiler is written in Rust but uses LLVM as a backend, like LDC. I don't know the complexities of linking a D frontend with a C++ backend, but if the Rust team can do it, I'm sure that means GDC and LDC will continue to live on. Both gcc and llvm expose a C api afaik
Re: std.experimental.testing PR review
On Monday, 20 July 2015 at 13:20:49 UTC, Atila Neves wrote: On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 It's my first Phobos PR, I tried reading the wiki and doing what's required but bear with me if I've screwed up somehow. I wasn't sure whether or not to split the PR. In the end I just took the existing library, edited it a lot and got it ready for review. Unit test blocks can be named with @Name. They execute in parallel by default but that's only if the default runner is used. Atila Bump. Bumpity bump?
Re: What about GDC and LDC after DMD becomes D?
On Wednesday, 22 July 2015 at 11:42:24 UTC, Shriramana Sharma wrote: Once the front end of DMD becomes fully D, I read that the backend will also become D, but then what will happen to GDC and LDC whose backends are C++ IIUC? Hi Shriramana! My current *plan A* for LDC is: Prerequisite: Enable LLVM Cpp backend For release: Compile DDMD frontend to C++ and distribute D and C++ version of DDMD. Bootstrap process: - Create stage1 ldc compiler from C++ version of frontend. - Use stage1 ldc to compile stage2 ldc compiler from D version of frontend. - For verification it could be useful to create a stage3 ldc compiler using the stage2 compiler. Advantage is that you only need a C/C++ compiler for bootstrap. Drawback is compile time. I have not yet tested this approach. Therefore *plan B*: Use a previous version of LDC to compile the current version. This will work as long as the used language in the frontend is stable. The non-frontend parts of LDC might slowly migrate from C++ to D. The pain point here is that LDC makes use of the LLVM C++ API which is really superior to the C API. Regards, Kai
Re: What about GDC and LDC after DMD becomes D?
On Wednesday, 22 July 2015 at 15:11:58 UTC, Kai Nacke wrote: Use a previous version of LDC to compile the current version. This will work as long as the used language in the frontend is stable. I have a feeling this is going to end up being an issue. Whatever D version ddmd is shipped with is going to need to be a LTS version.
Experience upgrading template code from 2.065 to 2.067
I updated a small template-heavy experimental library mostly for
compile-time introspection I write some time ago. The last time I
updated the code was probably using 2.065, but might also have
been as old as 2.063.
The code doesn't use much of the standard library, mostly parts
of std.traits and std.typetuple.TypeTuple. While upgrading, I
only encountered a single bug
(https://issues.dlang.org/show_bug.cgi?id=14820), which might
have been there for a long time as I didn't check when it was
introduced - I hit it when adding additional unittests when I got
weird compile-time errors.
There was however a breaking change that caused most of my
templates to fail. My templates supports both built-in types,
user-defined types and values. In order to do this, both
templates of `T` and `alias T` has to be created. In previous
versions of the compiler, user-defined types always picked the
`alias T` version first, while the newest compiler picks `T` for
all types. I found the old behavior pretty weird, so I'm all in
favor of the change though.
// 1
template Tmlp(T) {}
// 2
template Tmpl(alias T) {}
struct S {}
Tmpl!S; // 2 on 2.065 (/2.063?), 1 on 2.067
There's still an odd difference between built-in and user-defined
types:
template OnlyAlias(alias T) {}
struct S {}
OnlyAlias!S; // works
OnlyAlias!int; // doesn't work
I also had to make some dub related changes and a simple import
because `chain` moved from `std.algorithm` to `std.range`.
Just a little experience-report for upgrading between compiler
versions. I'm one of the people that is pro breaking-changes.
Keep in mind that this is a small project of just 4351 LOC where
a lot is tests and documentation and nearly no use of phobos or
druntime.
Anyway - happy to see breaking changes that improves the language.
Re: Stable partition3 implementation
On Saturday, 11 July 2015 at 02:56:55 UTC, Timon Gehr wrote:
...
The algorithm runs in O(n*log*(n)). It's not n log(n).
...
I understand now. I had never heard of an iterated logarithm
before. I took the asterisk to mean some constant, like a wild
card if you will. Sorry for the confusion.
I wonder if the true O(n) algorithm is still worth pursuing.
Although log*(n) may only be a factor of 2 or 3, the O(n)
algorithm may have a small constant factor which makes it 2-3x
faster.
That paper appears to be available here:
https://github.com/lispc/lispc.github.com/raw/master/assets/files/situ.pdf
No idea what the constant is though, I have not read the
paper (yet).
I don't know if there is anything relevant but that paper
focuses on a
different problem involving sorting.
No, it focuses on a few closely related problems, and the
O(n*log*(n))-algorithms solves a problem that is a
straightforward generalization of the problem you are looking
at. Stable three way partition is stable sorting where there
are only three "distinct" values (smaller, equal, greater). The
paper you provided builds on top of this algorithm. It is the
main reference and part (ii) of the "Algorithm B" part of the
O(n)/O(1) algorithm does not occur in the paper you provided,
but only in that other paper, so yes, it is relevant. :-)
I get that much now, but this paper is still way above my head.
There's some notation in the sample code that I don't understand.
In this statement:
e <- #{ j : L[j] = x, 1 <= j <= n }
I'm not sure what the pound # signifies or what exactly is being
assigned to e. I'm assuming it performs some operation on the
set, like "max", but I'm not sure what.
Re: std.experimental.testing PR review
On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 It's my first Phobos PR, I tried reading the wiki and doing what's required but bear with me if I've screwed up somehow. I wasn't sure whether or not to split the PR. In the end I just took the existing library, edited it a lot and got it ready for review. Unit test blocks can be named with @Name. They execute in parallel by default but that's only if the default runner is used. Atila Looks solid. I'm, shamefully, not a heavy user of unit testing but it appears to have everything I typically use from Google Test (C++) and is much more friendly to use thanks to the reflection and attributes. What's a scenario where you'd want a hidden test?
Re: Stable partition3 implementation
On Wednesday, 22 July 2015 at 16:59:29 UTC, Xinok wrote:
On Saturday, 11 July 2015 at 02:56:55 UTC, Timon Gehr wrote:
[...]
I understand now. I had never heard of an iterated logarithm
before. I took the asterisk to mean some constant, like a wild
card if you will. Sorry for the confusion.
I wonder if the true O(n) algorithm is still worth pursuing.
Although log*(n) may only be a factor of 2 or 3, the O(n)
algorithm may have a small constant factor which makes it 2-3x
faster.
[...]
I get that much now, but this paper is still way above my head.
There's some notation in the sample code that I don't
understand. In this statement:
e <- #{ j : L[j] = x, 1 <= j <= n }
I'm not sure what the pound # signifies or what exactly is
being assigned to e. I'm assuming it performs some operation on
the set, like "max", but I'm not sure what.
I haven't looked at the paper, but # followed by a set often
means cardinality, i.e. (assuming the set is is finite) the
number of elements in the set.
Re: Where will D sit in the web service space?
i currently use vibe.d in a couple of productive apps. i think it really shines when it comes to low latency, traffic heavy backend/api services. its true that the ORM is missing and multi-thread scaling is not very good. but after some tuning i am very happy with single core performance. no immediate need for a full fledged web app with all the html stuff but rather a blazing fast api server that provides the realtime/streaming (websocket/http2) interfaces so that apps that keep state over requests can be built. the time of stateless webservices (REST in peace...) is coming to an end. further down that line it would be pretty amazing to be able to compile web assembly from d and push it out from the server to the client. ( voltframework.com is an interesting approach in that direction) once libasync compiles under ldc and hopefully enters the webframework benchmark it better beats the shit out of the competition. and if so, people who do this stuff in C/C++ now will start to use it. On Saturday, 18 July 2015 at 14:07:30 UTC, Etienne Cimon wrote: On Saturday, 18 July 2015 at 11:19:45 UTC, Ola Fosheim Grøstad wrote: Nothing is as elegant and completely featured like D in the natively compiled world. I say natively, because that's the only way to resolve the "interpreter war", seeing your interpreter banned just like firefox did you flash.
Re: std.experimental.testing PR review
On 2015-07-22 17:05, Atila Neves wrote: Bumpity bump? So, what you're trying to say is that it's time for a vote ;) -- /Jacob Carlborg
Rant after trying Rust a bit
Long rant ahead - a bit dipsy.. TL;DR: Rust has momentum, manpower and tooling. Tooling matters. Safe defaults. Ergonomics like expressions and deconstructing rocks. I'm reluctantly confessing that I've had a small affair with Rust recently. While I think D is a really good language, there are several things I don't agree upon. Some are caused by historical reasons, some are caused by the lack of peer review. Lets look at a couple of things I think looks exiting about Rust after a bit experimentation. Manpower Silly stating this as why I have been playing with Rust, but it's probably one of the main reasons. Rust has momentum and a lot of manpower and well as some big compinies behind it. It should be of secondary importance, but this is something that really shows in the quality of Rust. I've been using D on and off since 2007, and the lack of manpower shows in every aspect of the language, design and ecosystem. Rust has a pretty nice ecosystem and tools given its very young age. Cargo - Rust has a default package manager much like Dub. The main difference is that Cargo has been endorsed by the Rust team and is an official product. This means it works very well with the compiler and feels like an integrated part of the language. Dub, on the other hand, is a product from the outside, and unfortunately, it feels this way too. Having Dub become the endorsed package manager for D sounds like a very good idea for me. In order to do this, some breaking changes might be necessary (I haven't used much D or Dub recently though..). If so, a good time to introduce breaking changes would be before integrating it into the "core" D ecosystem. The effects of Cargo is very visible by looking on the amount of libraries on https://crates.io as opposed to http://code.dlang.org. While code.dlang.org has 530 packages, crates.io has 2610 packages, and this is even if Rust is very new. Dubs repository website is a lot better than Rusts though :) Traits -- I think the ability to express an interface without buying into inheritance is the right move. The alternative in D is specifying the behavior as a template and verifying the contract in a unittest for the type. Algebraic data types Haven't looked into `Algebraic!`, so I won't start bashing D here :) But given the lack of pattern matching, I doubt it will be as pretty as Rust. Macros -- I haven't written more than extremely simple macros in Rust, but having macros that is possible for tools to understand is a win. Templates and string mixins is often used for this purpose, but trying to build tools when string mixins exists is probably extremely hard. If D had hygenic macros, I expect several features could be expressed with this instead of string mixins, making tooling easier to implement. Safe by default --- D is often said being safe by default, but D still has default nullable references and mutable by default. I don't see it being possible to change at this stage, but expressing when I want to be unsafe rather than the opposite is very nice. I end up typing a lot more in D than Rust because of this. Pattern matching Ooooh... I don't know what to say.. D should definitely look into implementing some pattern matching! final switch is good for making sure all values are handled, but deconstructing is just so ergonomic. Expressions --- This probably also falls in the "too late" category, but statements-as-expressions is really nice. `auto a = if ...` <- why not? Borrowing - This is probably the big thing that makes Rust really different. Everything is a resource, and resources have an owner and a lifetime. As a part of this, you can either have multiple aliases with read-only references, or a single reference with a writeable reference. I won't say I have a lot of experience with this, but it seems like it's not an extremely unergonomic trade-off. I cannot even remotely imagine the amount of possible compiler optimizations possible with this feature. Why have I been looking at Rust? I haven't been using D in production since 2008, which was an utterly disaster. I did some work on the native mysql client, but that was mostly making the code more D than C. Some small experimentations thereafter. The constant breakage in the language and standard library haven't been an real issue for me as I haven't used it in production - the problem when I used it was partly the phobos vs tango with incompatible runtimes together with an extremely buggy compiler. On the breaking part, the real issue is the "We're not going to break any code!" stance, while each release still breaks every codebase. The effect is that a lot of really long-term necessary breaking changes is never accepted - the only breaking changes is the unintended breaking changes! I'm in the "break-it" camp. If you don't mind living
Re: Implement the "unum" representation in D ?
On 7/13/15 1:20 AM, Nick B wrote: On Sunday, 12 July 2015 at 03:52:32 UTC, jmh530 wrote: On Saturday, 11 July 2015 at 03:02:24 UTC, Nick B wrote: FYI John Gustafson book is now out: I wouldn't have known about this way to deal with it if you hadn't bumped this thread. So thanks, it's interesting (not sure if this book will adequately address Walter's original concern that it won't really reduce power consumption). I also found the discussion of rational numbers earlier in the thread interesting. I glad that you guys have found this interesting :) Nick Just read http://radiofreehpc.com/tmp/TheEndofErrorSampleChapter.pdf, very interesting stuff. I assume the definition of various primitives for unum are as compelling as alluded. The treatment angles toward a hardware representation and primitives, yet these ideas seem reasonably actionable at language level. We'd be able to implement the primitives in software, and the result would be a competitor for infinite-precision arithmetic libraries, which do exist and are being used. Yet the software implementation would be very slow compared to IEEE floats, which limits applications quite a bit. All we can do now, with our limited resources, is to keep an eye on developments and express cautious interest. If someone able and willing comes along with a unum library for D, that would be great. Andrei
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: I've been using D on and off since 2007, and the lack of manpower shows in every aspect of the language, design and ecosystem. Rust has a pretty nice ecosystem and tools given its very young age. Only one way to fix this. Volunteer. Rust has a default package manager much like Dub. The main difference is that Cargo has been endorsed by the Rust team and is an official product. This means it works very well with the compiler and feels like an integrated part of the language. Dub, on the other hand, is a product from the outside, and unfortunately, it feels this way too. Having Dub become the endorsed package manager for D sounds like a very good idea for me. Dub is endorsed by the leadership and is included in the same Github organization as the complier and the standard library While code.dlang.org has 530 packages, crates.io has 2610 packages, and this is even if Rust is very new. Dubs repository website is a lot better than Rusts though :) I attribute this to hype. Also, while dub may feel a little bare at times, I always think of the worse alternative in node, so many packages that are crap that they push out anything of value. Traits -- I think the ability to express an interface without buying into inheritance is the right move. The alternative in D is specifying the behavior as a template and verifying the contract in a unittest for the type. I don't know enough about rust to comment. Macros -- I haven't written more than extremely simple macros in Rust, but having macros that is possible for tools to understand is a win. Templates and string mixins is often used for this purpose, but trying to build tools when string mixins exists is probably extremely hard. If D had hygenic macros, I expect several features could be expressed with this instead of string mixins, making tooling easier to implement. Maybe tooling would become easier to write, but in my personal experience, macros are much harder for programmers to understand than mixins, and much easier to abuse. Safe by default --- D is often said being safe by default, but D still has default nullable references and mutable by default. I don't see it being possible to change at this stage, but expressing when I want to be unsafe rather than the opposite is very nice. I end up typing a lot more in D than Rust because of this. This would break so much code it's not even funny. I agree that immutable by default is the best paradigm, but as far as breaking changes go, you can only have so many before people abandoned a language. Expressions --- This probably also falls in the "too late" category, but statements-as-expressions is really nice. `auto a = if ...` <- why not? Don't quite know what you mean here. Borrowing - This is probably the big thing that makes Rust really different. Everything is a resource, and resources have an owner and a lifetime. As a part of this, you can either have multiple aliases with read-only references, or a single reference with a writeable reference. I won't say I have a lot of experience with this, but it seems like it's not an extremely unergonomic trade-off. I cannot even remotely imagine the amount of possible compiler optimizations possible with this feature. I think that someone was working on this, but I think it got sidelined (as it should) to fixing RefCounted and other things in the std lib. The constant breakage in the language and standard library haven't been an real issue for me as I haven't used it in production - the problem when I used it was partly the phobos vs tango with incompatible runtimes together with an extremely buggy compiler. The tango vs Phobos issue has been mostly settled after the transition from d1 to d2, and the complier is a lot better now than it was. On the breaking part, the real issue is the "We're not going to break any code!" stance, Who, in the leadership or a contributor, has ever said this.
Re: Rant after trying Rust a bit
I'm not at all familiar with Rust, so forgive me if I'm misinterpreting something. On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: Cargo - Rust has a default package manager much like Dub. The main difference is that Cargo has been endorsed by the Rust team and is an official product. I think I read that this may happen soon. Traits -- ... You can make a `conformsToSomeInterface!T` template, and use `static assert`. D ranges, and the upcoming std.allocator, already use this sort of 'interfaces without polymorphism'. Ex. `static assert(isInputRange!(MyCoolRange));` Macros -- ... Most of what macros in C were used for are now done with templates, static if, etc. (I don't know how Rust's macros work). Tools could theoretically execute `mixin`, but it effectively requires a D interpreter. A library to do that would be really nice. Borrowing - ... Look into `std.typecons.Unique`, though I've seen people posting that they don't like it (I haven't used it much; I had one use case for it, which was sending it through `std.concurrency.send`, but it doesn't work with that function). Yes, D's community is pretty small. It's not something you can just code; you have to market the language. And it's the community that creates the many tools and packages.
Re: Rant after trying Rust a bit
Traits system is awesome and pure win. Pattern matching is not that game changing but helps often enough to feel important. Borrowship system is damn smart but totally impractical for most real-world cases. Macros are utterly horrible and pretty much unusable outside of advanced library internals. Recently I attended local Rust meetup for curious newcomers - it was very interesting to observe reaction of unbiased devs not familiar with D at all. General reaction was "this is awesome interesting language that I would never use for any production system unless I am crazy or can throw away money like crazy". Because, well, productivity. D has done many things wrong, but there is one right thing that totally outshines it all - it is cost-effective and pragmatical tool for a very wide scope of applications.
Re: Implement the "unum" representation in D ?
On Wednesday, 22 July 2015 at 19:28:41 UTC, Andrei Alexandrescu wrote: On 7/13/15 1:20 AM, Nick B wrote: All we can do now, with our limited resources, is to keep an eye on developments and express cautious interest. If someone able and willing comes along with a unum library for D, that would be great. The book has quite a bit of Mathematica code at the end. A first pass at a unum library could probably just involve porting that to D.
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote: On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: I've been using D on and off since 2007, and the lack of manpower shows in every aspect of the language, design and ecosystem. Rust has a pretty nice ecosystem and tools given its very young age. Only one way to fix this. Volunteer. Yes, I agree. I haven't done much good for the D community, although I believe some of the code I've written for mysql native is in production. Let me add a point for Rust somewhat related :) Community - The community is nice, helpful and doesn't condecent people. On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote: On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: Expressions --- This probably also falls in the "too late" category, but statements-as-expressions is really nice. `auto a = if ...` <- why not? Don't quite know what you mean here. When "everything" is an expressions, you can write things like auto a = if(e) c else d; In D you have to write type a = invalid_value; if(e) a = c; else a = d; assert(a != invalid_value); On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote: On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: (... snip [regarding phobos/tango runtime incompatibility] ...) The tango vs Phobos issue has been mostly settled after the transition from d1 to d2, and the complier is a lot better now than it was. There are probably nothing in newer times that can be credited as much pain as the incompatible runtimes of phobos and tango, but I've still encountered a lot of compiler and phobos bugs. Yes, it's just every 500 or so lines now, but I've only encountered a couple of bugs in the C# compiler and a couple more in the .Net library in several years - again credited to a lot more manpower available. On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote: On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: On the breaking part, the real issue is the "We're not going to break any code!" stance, Who, in the leadership or a contributor, has ever said this. I'm pretty sure Walter Bright has said this on a lot of occations. He seemed to believe a failure of adoption of D was due to the constant breaking changes, which might be true. On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote: On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: Rust has a default package manager much like Dub. The main difference is that Cargo has been endorsed by the Rust team and is an official product. (... snip ...) Dub is endorsed by the leadership and is included in the same Github organization as the complier and the standard library I didn't know that. Very nice. I hope it's in a clean state when it gets pulled in. On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote: On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: While code.dlang.org has 530 packages, crates.io has 2610 packages, (... snip ...) I attribute this to hype. (... snip ...) Yes, but the hype is probably driving even more developers to the language, and I believe a large user-base is of paramount importance for a language to become good. On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote: On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: Macros -- (... snip ...) Maybe tooling would become easier to write, but in my personal experience, macros are much harder for programmers to understand than mixins, and much easier to abuse. I disagree. String mixins are much easier to abuse than hygenic macros. String mixins allows anything, and while it offers infinite possibilities, it also encourage abuse.
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 19:52:34 UTC, Alex Parrill wrote: On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: Traits -- ... You can make a `conformsToSomeInterface!T` template, and use `static assert`. D ranges, and the upcoming std.allocator, already use this sort of 'interfaces without polymorphism'. Ex. `static assert(isInputRange!(MyCoolRange));` Exactly. D is a lot more flexible, but looking just at MyCoolRange, you cannot actually see it conforms to InputRange without looking at the unittests (or wherever else the static assert is inserted). On Wednesday, 22 July 2015 at 19:52:34 UTC, Alex Parrill wrote: On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: Borrowing - ... Look into `std.typecons.Unique`, though I've seen people posting that they don't like it (I haven't used it much; I had one use case for it, which was sending it through `std.concurrency.send`, but it doesn't work with that function). I haven't actually tried to recreate the stuff that Rust does with types in D. I expect some of it is possible, but the addition is things like Unique (which I haven't tried). And this escalates. You end up with `Unique!(NonNull!(MyClass))` and probably even more type decorators. On Wednesday, 22 July 2015 at 19:52:34 UTC, Alex Parrill wrote: Yes, D's community is pretty small. It's not something you can just code; you have to market the language. And it's the community that creates the many tools and packages. If I'm not mistaken, people of the D community have tried to market the language quite heavily. I don't know why more people haven't joined, and it's even more baffeling to see the comments on Reddit calling D related posts spam and speaking negatively of the marketing on a site where upvotes dictates the ranking on the front page.
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 20:43:04 UTC, simendsjo wrote: When "everything" is an expressions, you can write things like auto a = if(e) c else d; In D you have to write type a = invalid_value; if(e) a = c; else a = d; assert(a != invalid_value); That's what the ternary expression is for: auto a = e ? c : d; Though the ternary is unnecessary with statements as expressions, common cases like this are handled.
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 19:54:05 UTC, Dicebot wrote:
Traits system is awesome and pure win.
Agreed.
Pattern matching is not > that game changing but helps often
enough to feel important.
The fact that you can use pattern matching many places makes it
very much a win.
if Some(InnerClass::SomeType(value)) = some_call() {
// here you can use `value`
}
Borrowship system is damn smart but totally impractical for
most real-world cases.
I haven't used Rust enough to really have a voice on the subject.
It looks like a pardigm shift, and it might only take some getting
used to, but it might also be very difficult to use. There are
some big stuff written in Rust though - the rust compiler and the
servo browser engine. The fact that it makes a lot of errors
impossible is the exiting thing for me.
Macros are utterly horrible and pretty much unusable outside
of advanced library internals.
Not sure what you are referencing here. Macros expand to code. If
you compare this to string mixins, they are a lot easier for tool
writers, but a lot less powerful.
Recently I attended local Rust meetup for curious newcomers -
it was very interesting to observe reaction of unbiased devs
not familiar with D at all. General reaction was "this is
awesome interesting language that I would never use for any
production system unless I am crazy or can throw away money
like crazy". Because, well, productivity.
I'm having some problems interpreting this. This is people in
a Rust meetup - in other words, early adopters. And they thing
D is crazy "becuse productivity"? I don't understand what you
mean.
D has done many things wrong, but there is one right thing that
totally outshines it all - it is cost-effective and pragmatical
tool for a very wide scope of applications.
Yes, D is pragmatic and extremely powerful and meldable to every
usecase.
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 20:59:11 UTC, Adam D. Ruppe wrote: On Wednesday, 22 July 2015 at 20:43:04 UTC, simendsjo wrote: When "everything" is an expressions, you can write things like auto a = if(e) c else d; In D you have to write type a = invalid_value; if(e) a = c; else a = d; assert(a != invalid_value); That's what the ternary expression is for: auto a = e ? c : d; Though the ternary is unnecessary with statements as expressions, common cases like this are handled. :) The example was written to save space. I recon you understand what I mean.
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 21:03:52 UTC, simendsjo wrote: On Wednesday, 22 July 2015 at 19:54:05 UTC, Dicebot wrote: Recently I attended local Rust meetup for curious newcomers - it was very interesting to observe reaction of unbiased devs not familiar with D at all. General reaction was "this is awesome interesting language that I would never use for any production system unless I am crazy or can throw away money like crazy". Because, well, productivity. I'm having some problems interpreting this. This is people in a Rust meetup - in other words, early adopters. And they thing D is crazy "becuse productivity"? I don't understand what you mean. What I understood that he meant was that it was interesting to see the reaction of folks who have nothing to with D when they learned about Rust. So, they weren't likely colored by whatever preconceptions you'd get out of someone who's already invested in D. They were reacting to Rust without D being in the picture at all. And their reaction to Rust was that it was cool and interesting but that it would be crazy to use it in production, because it's not productive (or at least, they didn't think that it was) - presumably because some of its features make it too hard to use, but dicebot would have to elaborate. - Jonathan M Davis
Re: Where will D sit in the web service space?
On Friday, 17 July 2015 at 12:06:08 UTC, Ola Fosheim Grøstad wrote: On Friday, 17 July 2015 at 11:23:28 UTC, Kagamin wrote: An attractive platform is which gets the job done, not the best one, which doesn't actually exist (if it existed, there wouldn't be a list of options). And it's not like D has nothing to show, one must consider requirements for his task to decide which tool to choose and there's no single answer that suits everyone. There is always a relatively small set of best solutions for a given problem. One needs to find a rational and obvious answer to the question: For what domain is D the best choice? Just a single, well argued answer that stands up to scrutiny. Without it, few people will feel like endorsing it. (loss of marketing effect) The finance guys seem to be coming on board, the Dconf '15 talk by the fund guy, Smith, probably helps. I thought this was a nice endorsement recently, a reddit comment by a high-frequency trader which ended with: "[W]e've loved D so much that we're in the middle of a full rewrite from C++11 to D. The productivity boost is absolutely worth it." http://www.reddit.com/r/programming/comments/3cg1r0/lessons_learned_writing_a_filesystem_in_d/csvyxn8 While you may be right from a marketing and strategy perspective that D would be better off to focus on some carefully chosen niche and try to excel there to begin with, D is a general-purpose, native language developed by random volunteers from an online community of users. Even if the community agreed with your concept of focusing D on some domain, it's hard enough to get most people in a _company_ to agree on what that plan should actually be, let alone getting this free-floating community to agree on a domain. And as I've said before, focusing on a domain means you optimize for it, which inevitably means you become less general. Php has proven to be highly optimized for the web programming domain, in that it is highly successful at being chosen for many web projects, but almost nobody would want to use it for anything else, for a variety of reasons, but mainly that the qualities that make it successful on the web hurt it in other domains. So your superior marketing/business strategy has its technical and strategy downsides too, at least for a general-purpose language. Now, you can argue that the market for programming languages has become highly fragmented and that unless you are _the_ language for statistics, R, or concurrency, erlang, you cannot get anywhere. But some of us think general-purpose, native languages are coming back, with mobile made up only of native/AoT-compiled languages these days and successful web properties moving all their high-volume backend work to such languages. Even if the pendulum doesn't swing all the way back as far as we think it will for general-purpose native languages, that's a very large niche, one with few choices- C, C++, D, Rust, Go (the first two legacy)- and well worth competing in. Ask yourself: why did a weird language like Erlang grow? It has certainly had a resurgence in recent years, but has it really gone anywhere? Certain highly concurrent apps, like Whatsapp, have made good use of it, but it's not like it's roaring past D. If your only point is that it's done better than it has a right to because it has a very specific strength, I'll point out that it's also a good example of what I said above: focusing on one area can leave you significantly weaker in many other areas and doom you to that one niche.
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 20:43:04 UTC, simendsjo wrote:
When "everything" is an expressions, you can write things like
auto a = if(e) c else d;
In D you have to write
type a = invalid_value;
if(e) a = c;
else a = d;
assert(a != invalid_value);
I prefer this example from one of the various Rust tutorials
let foo = if x == 5 {
"five"
}
else if x == 6 {
"six"
}
else {
"neither"
}
You're basically using a conditional expression as an rvalue. You
can do the same thing with a { } block.
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 21:03:52 UTC, simendsjo wrote: Macros are utterly horrible and pretty much unusable outside of advanced library internals. Not sure what you are referencing here. Macros expand to code. If you compare this to string mixins, they are a lot easier for tool writers, but a lot less powerful. Compared to string mixins they require much much more effort to learn and reason about. In our meetup group no one was able to figure out meaning of any small sample macro without detailed explanation. Compared to string mixins they are much harder to abuse because of inherent hygiene but also much harder to start using, while in D the concept comes quick and naturally but requires discipline to get used in maintainable fashion. And they definitely don't feel any easier for library writers from my personal experience. More maintainable - yes, but not easier at all. Recently I attended local Rust meetup for curious newcomers - it was very interesting to observe reaction of unbiased devs not familiar with D at all. General reaction was "this is awesome interesting language that I would never use for any production system unless I am crazy or can throw away money like crazy". Because, well, productivity. I'm having some problems interpreting this. This is people in a Rust meetup - in other words, early adopters. And they thing D is crazy "becuse productivity"? I don't understand what you mean. Not early adopters, more like curious group learning new stuff together. And "crazy" was about Rust and how impractical it is for real business needs they have. No one has ever mentioned D there.
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 21:36:58 UTC, jmh530 wrote:
On Wednesday, 22 July 2015 at 20:43:04 UTC, simendsjo wrote:
When "everything" is an expressions, you can write things like
auto a = if(e) c else d;
In D you have to write
type a = invalid_value;
if(e) a = c;
else a = d;
assert(a != invalid_value);
I prefer this example from one of the various Rust tutorials
let foo = if x == 5 {
"five"
}
else if x == 6 {
"six"
}
else {
"neither"
}
You're basically using a conditional expression as an rvalue.
You can do the same thing with a { } block.
Admittedly nowhere near as clean, but if you can bear to see the
"return"s, function literals can turn any bunch of code in to an
expression:
auto foo = { if(x == 5)
return "five";
else if(x == 6)
return "six";
else
return "neither";
}();
or of course there's the perhaps overly terse (brackets optional,
i like them to visually group the condition with the ? ):
auto foo = (x == 5)? "five"
: (x == 6)? "six"
: "neither";
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 22:35:54 UTC, John Colvin wrote: Admittedly nowhere near as clean, but if you can bear to see the "return"s, function literals can turn any bunch of code in to an expression: Honestly, I don't mind doing things the D way (and I probably wouldn't have even done that your way). I just think it's interesting when another programming language has a cool feature.
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: Traits -- I think the ability to express an interface without buying into inheritance is the right move. The alternative in D is specifying the behavior as a template and verifying the contract in a unittest for the type. Rust only has structs. I'm not as familiar with them so it's not as clear how they overlap with D's structs and classes. It seems like you can put Rust structs on the stack or heap. Others have already commented on how you can basically accomplish the same thing with templates, static ifs, and assert. That was my first thought as well. Nevertheless, I would add that Rust's ability to use multiple traits in the template constraints is a positive. However, it seems like the essence of a trait in Rust is forcing some user-defined type to implement some functionality. That sounds a lot like an interface in D to me. In fact, Rust's traits seem different from Scala and PHP traits in that I don't see any examples with them using implementation. The two biggest differences between Rust traits and D interfaces are 1) inheritance of Rust traits (to my knowledge D does not have inheritance for interfaces, am I wrong?), 2) Rust traits can be easily used in template constraints. Those both seem like positives to me, though I'm not sure if they can be easily changed in D. If you look at the Rust book's main example on traits. They use them to implement a print_area function that can only be called with structs that have a trait HasArea defined. Classes in pretty much any OOP language could use inheritance to implement a simpler version where print_area is a method instead of a separate function. To play devil's advocate, writing a bunch of code with templates/static ifs/assert is definitely more confusing for someone new to the language than Rust's traits are. A lot of the D code makes quite a bit of sense when you understand how the different ideas combine together, but it takes a while to figure it out. If traits were deemed important enough to add to D, I would suggest just extending interfaces so that they have inheritance and can be easily used in template constraints. I would be more interested in seeing some of these OOP features come to structs, but I have no idea how much work that requires. I feel like alias this is hacky compared to real inheritance. Algebraic data types Haven't looked into `Algebraic!`, so I won't start bashing D here :) But given the lack of pattern matching, I doubt it will be as pretty as Rust. It seems like D's Algebraic does not allow for recursive Algebraic Types currently, whereas Rust's does. I'm honestly not that familiar with the concept. Seems cool, but I'm not sure I've ever really needed it. Borrowing - This is probably the big thing that makes Rust really different. Everything is a resource, and resources have an owner and a lifetime. As a part of this, you can either have multiple aliases with read-only references, or a single reference with a writeable reference. I won't say I have a lot of experience with this, but it seems like it's not an extremely unergonomic trade-off. I cannot even remotely imagine the amount of possible compiler optimizations possible with this feature. I feel like it's hard to separate borrowing from Rust's variety of pointers (& is borrowed pointer, ~ is for unique pointer, @ is for managed pointer). Nevertheless, I think having them part of the language with relatively straightforward syntax is a positive for Rust. Also, my understanding is that they are checked at compile-time for safety (at least unique and managed). However, I feel like borrowing and lifetimes have a bit of a learning curve to them. I've read a few tutorials without a good sense of them. I would probably need to program a bit in it to grok it. I think part of it is that Rust has = potentially meaning copy or move depending on whether it is defined. Perhaps they need a separate move assignment, like <- and -> or something (to steal syntax from R, even though that's not what <- and -> do in R).
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: ... I think rust makes the ugliness of D's "push everything into phobos for simplicity" become very visible. D and Rust share many equal constructs, but D's is almost always uglier.
Re: Rant after trying Rust a bit
On 2015-07-22 20:47, simendsjo wrote: Traits -- I think the ability to express an interface without buying into inheritance is the right move. The alternative in D is specifying the behavior as a template and verifying the contract in a unittest for the type. I completely agree and don't really like the approach D has implemented template constraints. Yeah I know, Andrei will destroy this :) Macros -- I haven't written more than extremely simple macros in Rust, but having macros that is possible for tools to understand is a win. Templates and string mixins is often used for this purpose, but trying to build tools when string mixins exists is probably extremely hard. If D had hygenic macros, I expect several features could be expressed with this instead of string mixins, making tooling easier to implement. I completely agree. String mixins are one of the most ugliest features. Safe by default --- D is often said being safe by default, but D still has default nullable references and mutable by default. I don't see it being possible to change at this stage, but expressing when I want to be unsafe rather than the opposite is very nice. I end up typing a lot more in D than Rust because of this. Agree. Pattern matching Ooooh... I don't know what to say.. D should definitely look into implementing some pattern matching! final switch is good for making sure all values are handled, but deconstructing is just so ergonomic. Yeah, pattern matching is s nice. I've been trying to implement something similar in D as a library, something like this: auto foo = Foo(); match!(foo Foo, (int a, int b) => writeln(a, b); ); Which kind of works for deconstructing variable pattern. But then you want to have a pattern where "a" is 1, they it becomes much harder: match!(foo Foo, (value!(1), int b) => writeln(b); ); Or match!(foo Foo, 1, (int b) => writeln(b); ); But now you need to use different syntax for value pattern and variable pattern and soon everything becomes a big mess. It will never be as good as proper language support. Expressions --- This probably also falls in the "too late" category, but statements-as-expressions is really nice. `auto a = if ...` <- why not? I really like, I use it a lot in Scala. The with the combination of automatically return the last thing in a method and methods not needing curly braces for single expression methods is really nice: def foo(a: String) = if (a == "foo") 1 else if (a == "bar") 2 else 3 On the breaking part, the real issue is the "We're not going to break any code!" stance, while each release still breaks every codebase. The effect is that a lot of really long-term necessary breaking changes is never accepted - the only breaking changes is the unintended breaking changes! Agree. -- /Jacob Carlborg
Re: Rant after trying Rust a bit
I've not used Rust, but don't plan to. On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: While code.dlang.org has 530 packages, crates.io has 2610 packages, I think this tells something foremost about the size of the community. More people leads to more code. Traits -- I think the ability to express an interface without buying into inheritance is the right move. The alternative in D is specifying the behavior as a template and verifying the contract in a unittest for the type. Traits can't do Design by Introspection aka compile-time duck. C++ can on the other hand. Algebraic data types Haven't looked into `Algebraic!`, so I won't start bashing D here :) But given the lack of pattern matching, I doubt it will be as pretty as Rust. You can pattern-match with visit. Macros -- I haven't written more than extremely simple macros in Rust, but having macros that is possible for tools to understand is a win. Templates and string mixins is often used for this purpose, but trying to build tools when string mixins exists is probably extremely hard. If D had hygenic macros, I expect several features could be expressed with this instead of string mixins, making tooling easier to implement. There is a difference though: Rust forces macros on you on the get go, while in D string mixing are quite a rare occurence thanks to other meta things and don't have a weird separate syntax. Regular templates + tuple foreach + static if is just easier to debug. Borrowing - This is probably the big thing that makes Rust really different. Everything is a resource, and resources have an owner and a lifetime. As a part of this, you can either have multiple aliases with read-only references, or a single reference with a writeable reference. I won't say I have a lot of experience with this, but it seems like it's not an extremely unergonomic trade-off. I cannot even remotely imagine the amount of possible compiler optimizations possible with this feature. The problem I see with this is that it is exactly like C++ scoped ownership except enforced. Even in Rust meeting they said they were converging on C++. It remotely feels like the same language to me. I've worked in fully scoped ownership codebases, it's very nice and consistent, and you don't feel like you would need anything else while doing it. You must train everyone to do it. Enforcing it in the language? I'm not sure about this. There are time where you debug and you have to comment stuff out wildly. Also if you are going to replace C++, it is a given to at least compile faster, make solve problem #1.
Re: Rant after trying Rust a bit
On 2015-07-22 21:41, Jack Stouffer wrote: Dub is endorsed by the leadership and is included in the same Github organization as the complier and the standard library It's not available in the Downloads, Compiler & Tools or Resources sections on dlang.org, so I disagree. -- /Jacob Carlborg
