Re: Announcing Elembuf
On Tuesday, 18 December 2018 at 01:34:00 UTC, H. S. Teoh wrote: I'm not sure I understand what you mean by "globals"; AFAICT MmFile just has a bunch of member variables, most of which are only important on the initial mapping and later unmapping. Once you get a T[] out of MmFile, there's little reason to use the MmFile object directly anymore until you're done with the mapping. Even if you were to use it only once, you would still have to create all those variables and keep them around untill you no longer use the slice. While with Elembuf, you only need to keep the slice. In std.mmfile OpSlice returns a void[] instead of a T[], making it difficult to work with as it requires a cast, there would also be a need to do costly conversions should "T.sizeof != void.sizeof" be true. Are you sure? Casting void[] to T[] only needs to be done once, and the only cost is recomputing .length. (Casting an array does *not* make a copy of the elements or anything of that sort, btw.) Once you have a T[], it's pointless to call Mmfile.opSlice again; just slice the T[] directly. I was assuming that you were using mmfile directly. Yes, it is possible to just use the output, but the benefit I see from Elembuf is that you can use it directly without too much overhead, but you can also just take a slice and refill when needed as well. While the focus of this library is in socket receival, reading from a file doesn't seem to be bad either. Although if you are intending on sending the file through a socket to another computer, use splice instead.(http://man7.org/linux/man-pages/man2/splice.2.html) However, from purely a code perspective Elembuf attempts to have minimal runtime arguments and variables, with heavy reliance on compile time arguments. It also uses a newer system call for Linux (Glibc) that is currently not in druntime, the reason for this system call is that it allows for faster buffer construction. Read more about it here: https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/ Hmm. Isn't that orthogonal to mmap(), though? You could just map a memfd descriptor using mmap() to achieve essentially equivalent functionality. Am I missing something obvious? The main point from the post linked earlier is that using memfd_create instead of shm_open has many benefits. While it may not directly affect how files are read into memory,as mmfile is using open, it is still interesting to know when benchmarking your options. If you are writing the whole file into memory, then this library may be a better option for you just purely for the sake of saving memory. If you are not doing that and instead using file mmap with an offset, then benchmarking would give you the best answer.
Re: Announcing Elembuf
On Tuesday, 18 December 2018 at 08:00:48 UTC, Cyroxin wrote: use splice instead.(http://man7.org/linux/man-pages/man2/splice.2.html) This was a typo, corrected to "use sendfile instead (http://man7.org/linux/man-pages/man2/sendfile.2.html)"
Re: Blog post: What D got wrong
On Mon, 2018-12-17 at 12:16 -0800, Walter Bright via Digitalmars-d-announce wrote: > […] > > Going pure, however, is much harder (at least for me) because I'm not used > to > programming that way. Making a function pure often requires reorganization > of > how a task is broken up into data structures and functions. > > […] I can recommend a short period of working only with Haskell. And then a short period working only with Prolog. Experience with Java and Python people trying to get them to internalise the more declarative approach to software, shows that leaving their programming languages of choice behind for a while is important in improving their use of their languages of choice. For Java people this is quite easy since there is Frege (an implementation of Haskell on the JVM) and Clojure (a Lisp on the JVM). They do not have to leave the comfort of their JVM to get away from Java. On return to Java, people's use of Option, and lambda expressions, etc. was markedly different – and a lot more declarative, making testing as well as comprehensibility of their much better. For Python people you have to play slightly different games, such as requiring no use of for and while loops, since there is no pure declarative language on the PVM – the computational model of the PVM actually makes declarative programming quite hard, but it is possible, and it improves code comprehensibility and testability. The problem for people immersed in the C, and C++ world is internalising declarative as a concept. I have tried, and failed a few times, as well as succeeding some. As C++ evolves towards being more and more declarative, it seems hard for the average C++ programmer to really move on from "old style C++", despite all the literature on "modern C++". But as the standards committee drag C++ along the increasingly declarative code route, things change, albeit relatively slowly. Rust I feel has a pivotal role in all this. By emphasising the ML view on mixed declarative and imperative programming, it has found an interesting middle ground that seems to work very well. Many of the C programmers who though C++ overcomplicated and not worth looking at, are taking to Rust and in doing so leaving C behind. On a personal level, I am now doing most of my programming in Rust rather than D, but this is as much to do with the GStreamer community choosing Rust as the replacement for C for GStreamer. But this is from a library implementers perspective, rather than an application perspective – but the choice pushes through. D (with GtkD and GStreamerD) is in many ways as good a choice as gtk- rs and gstreeamer-rs for writing applications – except: – documentation for gtk-rs and gstreamer-rs is better than for GtkD and GStreamerD; and – the standard Rust executor and futures system has been integrated into gtk- rs, something not present in GtkD. – GStreamer core developers have an obsessive fear of the word "garbage collector". I did a lightning talk at the GStreamer conference in Edinburgh a couple of months ago, concluding that I think D (which about half the audience knew of) is overall better than Rust for GTK+ and GStreamer applications, but recognising that Rust is actually the replacement for C and C++ for GTK+ and GStreamer applications. (Obviously Python has an ongoing role in all this as well.) I think D has missed the opportunity to get significant traction in the GTK+ and GStreamer milieus. :-( -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Blog post: What D got wrong
On Tuesday, 18 December 2018 at 08:17:28 UTC, Russel Winder wrote: Rust I feel has a pivotal role in all this. By emphasising the ML view on mixed declarative and imperative programming, it has found an interesting middle ground that seems to work very well. Many of the C programmers who though C++ overcomplicated and not worth looking at, are taking to Rust and in doing so leaving C behind. AIU rust, clojure and prolog are impure.
Re: Blog post: What D got wrong
On Tue, 2018-12-18 at 09:59 +, Kagamin via Digitalmars-d-announce wrote: > […] > AIU rust, clojure and prolog are impure. Clearly Rust is because it allows for mutability, though it is not the default. Clojure is but you have to work hard for that, the initial language is effectively pure. I have no idea how the term impure can be applied to Prolog. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe
wrote:
On Thursday, 13 December 2018 at 10:29:10 UTC, RazvanN wrote:
Do you honestly think that they will ever take D into account
if @safe and immutable data will be the default?
D needs to stop chasing after what you think people think they
want and just start being good for us.
The majority of my code is written pretty permissively - I like
my pointers, my gotos, my GC, my exceptions. But I'm willing to
consider the change because I actually don't think it will be
that big of a hassle, and will be better overall. I wanna show
you something:
/// Static convenience functions for common color names
nothrow pure @nogc @safe
static Color transparent() { return Color(0, 0, 0, 0); }
The attribute spam is almost longer than the function itself.
Isn't it the way forward that the compiler deduces these
attributes and fills them in automatically? All these can be
inferenced. Only when the caller wants to guarantee, say pure, it
could add it explicitly. I read somewhere that the compiler
already does this to some degree. And even the generated docs
should be able to show it.
Re: LDC 1.13.0
On Sunday, 16 December 2018 at 15:57:25 UTC, kinke wrote: Glad to announce LDC 1.13: * Based on D 2.083.1. * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. * Substantial debug info improvements. * New command-line option `-fvisibility=hidden` to hide functions/globals not marked as export, to reduce the size of shared libraries. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.13.0 New Wiki page highlighting cross-compilation: https://wiki.dlang.org/Cross-compiling_with_LDC Thanks to all contributors! Awesome, thanks! How can the old visual studio linker be enabled? I tried to specify it trough -linker but it collides with the dmd linker.exe.
Re: Blog post: What D got wrong
On Tuesday, December 18, 2018 3:36:15 AM MST Pjotr Prins via Digitalmars-d-
announce wrote:
> On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe
>
> wrote:
> > On Thursday, 13 December 2018 at 10:29:10 UTC, RazvanN wrote:
> >> Do you honestly think that they will ever take D into account
> >> if @safe and immutable data will be the default?
> >
> > D needs to stop chasing after what you think people think they
> > want and just start being good for us.
> >
> > The majority of my code is written pretty permissively - I like
> > my pointers, my gotos, my GC, my exceptions. But I'm willing to
> > consider the change because I actually don't think it will be
> > that big of a hassle, and will be better overall. I wanna show
> > you something:
> >
> > /// Static convenience functions for common color names
> > nothrow pure @nogc @safe
> > static Color transparent() { return Color(0, 0, 0, 0); }
> >
> >
> > The attribute spam is almost longer than the function itself.
>
> Isn't it the way forward that the compiler deduces these
> attributes and fills them in automatically? All these can be
> inferenced. Only when the caller wants to guarantee, say pure, it
> could add it explicitly. I read somewhere that the compiler
> already does this to some degree. And even the generated docs
> should be able to show it.
In general, functions that have to have their source available have their
attributes inferred. So, templated functions, lambdas, and auto return
functions all have attribute inference at this point. Attribute inference
was introduced originally as being only for templated functions, because you
_have_ to have it for them for them to really work with attributes (at least
in any situation where whether an attribute is applicable depends on the
template arguments - which is frequently the case), but it's been expanded
over time. However, D's compilation model is such that many functions will
never have attribute inference, because it's frequently not guaranteed that
the compiler has the source code for a function in all cases where it's
called.
That being said, there are some serious downsides to attribute inference. It
makes it much harder to know which attributes actually apply to a function,
and it tends to result in folks not bothering with making sure that they're
code works with a particular attribute; they just let attribute inference
take care of it all and don't worry about it (in which case, the result is
comparable to not having attribute inference in some respects). Another big
issue is that when the attributes are inferred, it, becomes _very_ easy to
accidentally change which attributes a function has when changing its
implementation (similar to how its very easy to accidentally make it so that
a function no longer works with CTFE). The primary way to combat that is to
use explicit attributes on the unittest blocks which test the function, but
that's easy to forget to do, and in a way, it's just moving the explicit
attributes from the function itself to the unit tests. So, whether it
actually fixes anything is debatable.
In general, the cleanest approach is to be as explicit about attributes as
possible (which means still using attribute inference with templated
functions when the attribute should depend on the template arguments but to
not use it much of anywhere else). However, that then requires that you mark
up your functions everywhere, which can be very tedious, and many folks
don't want to do it. Of course, using more attribute inference reduces that
particular problem (which is why many folks want it), but you then get a
different set of problems due to the fact that attributes are inferred
instead of explicit.
So, there's really no winning. In some ways, minimizing attribute inference
is the best option, and in others, maximizing it would be better. Probably
the best solution to the problem would be to have the defaults better match
up with what your average program needs, but no set of defaults fits every
program, and different coding styles can result in very different opinions
on which set of attributes should be the default. I very much doubt that you
would find much of a consensus on it even just within the core set of
developers working on dmd, druntime, and Phobos.
My guess is that if code breakage were somehow not part of the question that
the majority of D programmers would be in favor of @safe by default, since
the vast majority of code can be @safe (though plenty of the time
programmers don't bother to mark it as @safe), and in theory, only small
portions of a program should typically need to be marked as @system. But I
expect that any other attribute would result in a lot of arguing. For
instance, in some respects, pure would be great as the default, but that
doesn't interact well at all with stuff like I/O, making it so that you have
to write your programs in a certain way for pure to work well for most
functions, and not everyone wants to do that. Some folks mi
Re: Blog post: What D got wrong
On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder wrote: Clojure is but you have to work hard for that, the initial language is effectively pure. https://ideone.com/y8KWja clearly it isn't, its site only claims that most code happens to be pure, but it looks like it's not checked in any way and not sure if purity can be even checked there.
Re: Blog post: What D got wrong
On Tuesday, 18 December 2018 at 12:20:48 UTC, Kagamin wrote: On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder wrote: Clojure is but you have to work hard for that, the initial language is effectively pure. https://ideone.com/y8KWja clearly it isn't, its site only claims that most code happens to be pure, but it looks like it's not checked in any way and not sure if purity can be even checked there. From the Clojure homepage: "Clojure is impure, yet stands behind the philosophy that programs that are more functional are more robust." The goal is to make it easy to program in a functional style, not to provide a pure functional programming language. It is like OCaml in that respect.
Re: Blog post: What D got wrong
On Tuesday, 18 December 2018 at 11:25:17 UTC, Jonathan M Davis wrote: Of course, even if we _did_ have a solution for reversing attributes, slapping an attribute on the top of the module would still potentially be a maintenance problem, because it's then really easy to miss that an attribute is in effect (it's a problem that we've had on several occasions with druntime and Phobos in the few cases where attributes are mass-applied). So, there is no silver bullet here (though regardless of whether mass-applying attributes is something that should ever be considered good practice, we really should add a way to be able to reverse them). Thanks Jonathan for your elaborate explanation. I personally have no problem with the attributes which - in practice - means I don't use them much unless I want to make sure something is nogc, for example. For library designers it makes sense to be explicit. I guess that is where the trade-off kicks in. Maybe it is just a feature. We argue against specifying them because other languages are not as explicit. It does add a little noise.
Re: Blog post: What D got wrong
On Tue, 2018-12-18 at 12:20 +, Kagamin via Digitalmars-d-announce wrote: > On Tuesday, 18 December 2018 at 10:19:14 UTC, Russel Winder wrote: > > Clojure is but you have to work hard for that, the initial > > language is effectively pure. > > https://ideone.com/y8KWja clearly it isn't, its site only claims > that most code happens to be pure, but it looks like it's not > checked in any way and not sure if purity can be even checked > there. Can we all agree that Haskell is a pure functional language. I think we must because: a) it says it is, and b) it is. f2 = print "Hello World." f1 = f2 main = do f1 result of running this: GHCi, version 8.0.1 > "Hello World." > OK so Haskell uses monads and Clojure just uses the JVM I/O. Haskell is pure, Clojure is impure. But I stand by my original statement: Clojure is best used as a pure language. Even if I/O is impure, you can make it pure with monads if you really have to. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: D is helping with porch pirates
On 12/17/18 6:13 PM, Daniel Kozák wrote: https://gma.abc/2zWvXCl Fixed subject, nice story! -Steve
Re: LDC 1.13.0
On Tuesday, 18 December 2018 at 10:45:13 UTC, Radu wrote: How can the old visual studio linker be enabled? I tried to specify it trough -linker but it collides with the dmd linker.exe. It's all in the README.txt, as mentioned in the release notes. ;) Use an absolute path in `-linker` if DMD's optlink takes precedence in your PATH.
DIP 1018--The Copy Constructor--Community Review Round 1 Begins
The first round of Community Review for DIP 1018, "The Copy Constructor", has begun. To participate, please visit the review thread for the details: https://forum.dlang.org/post/eoqddfqbjtgfydajo...@forum.dlang.org *Please leave all feedback in the review thread rather than here!* Thanks!
Re: Blog post: What D got wrong
On 12/17/18 4:42 AM, Dukc wrote: On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote: On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: @safe and pure though... Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed? Argh, I forgot that you are not supposed to @safe templates away. You can apply @safe to anything. It's @trusted you have to be careful with. Of course, it probably won't work for many templates. -Steve
Re: Blog post: What D got wrong
On Monday, 17 December 2018 at 11:04:13 UTC, Atila Neves wrote: Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed? Not quite. It doesn't work the way most people expect for member functions and causes problems for templates. Don't templates infer attributes? @safe didn't work well for trusted aggregates (including inference), not sure if dip1000 fixes that.
Re: Announcing Elembuf
On Tue, Dec 18, 2018 at 08:00:48AM +, Cyroxin via Digitalmars-d-announce wrote: > [...] While the focus of this library is in socket receival, reading > from a file doesn't seem to be bad either. [...] Ahh, I see. I thought the intent was to read from a file locally. If you're receiving data from a socket, having a circular buffer makes a lot more sense. Thanks for the clarification. Of course, a circular buffer works pretty well for reading local files too, though I'd consider its primary intent would be better suited for receiving data from the network. T -- Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye
Re: Blog post: What D got wrong
On Tue, Dec 18, 2018 at 08:17:28AM +, Russel Winder via Digitalmars-d-announce wrote: > On Mon, 2018-12-17 at 12:16 -0800, Walter Bright via Digitalmars-d-announce > wrote: > > […] > > > > Going pure, however, is much harder (at least for me) because I'm > > not used to programming that way. Making a function pure often > > requires reorganization of how a task is broken up into data > > structures and functions. Component-based programming helps a lot in this regard. It breaks the problem down in a way that, when done correctly, captures the essence of the algorithm in a way that's easily translated to pure code (esp. D's expanded definition of purity). [...] > I can recommend a short period of working only with Haskell. And then > a short period working only with Prolog. Experience with Java and > Python people trying to get them to internalise the more declarative > approach to software, shows that leaving their programming languages > of choice behind for a while is important in improving their use of > their languages of choice. [...] It's all about the mindset. Being forced to think about the problem from a purely functional perspective gives you a radically different perspective from the usual imperative paradigm, and IME often yields insight into the essential structure of your programming problem that is otherwise easily obscured by the imperative structure imposed upon it. T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney
Re: Blog post: What D got wrong
On Tue, 18 Dec 2018 08:17:28 +, Russel Winder wrote: > I did a lightning talk at the GStreamer conference in Edinburgh a couple > of months ago, concluding that I think D (which about half the audience > knew of) is overall better than Rust for GTK+ and GStreamer > applications, but recognising that Rust is actually the replacement for > C and C++ for GTK+ and GStreamer applications. (Obviously Python has an > ongoing role in all this as well.) Is there a video link for that talk? I'd be interested in hearing it.
Re: Blog post: What D got wrong
On Tue, 2018-12-18 at 16:50 +, Neia Neutuladh via Digitalmars-d-announce wrote: > On Tue, 18 Dec 2018 08:17:28 +, Russel Winder wrote: > > I did a lightning talk at the GStreamer conference in Edinburgh a couple > > of months ago, concluding that I think D (which about half the audience > > knew of) is overall better than Rust for GTK+ and GStreamer > > applications, but recognising that Rust is actually the replacement for > > C and C++ for GTK+ and GStreamer applications. (Obviously Python has an > > ongoing role in all this as well.) > > Is there a video link for that talk? I'd be interested in hearing it. The videos are here: https://gstconf.ubicast.tv/channels/#gstreamer-conference-2018 I think they recorded the lightning talks as a single video, so you'll have to fast forward to my little bit. I see from: https://pengutronix.de/de/2018-10-29-gstconf-2018.html That it has been described "an entertaining lightning talk about the history of MeTV, a live TV viewing application, up to the latest rewrite in Rust using GStreamer" -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Announcing Elembuf
On 12/18/18 10:36 AM, H. S. Teoh wrote: On Tue, Dec 18, 2018 at 08:00:48AM +, Cyroxin via Digitalmars-d-announce wrote: [...] While the focus of this library is in socket receival, reading from a file doesn't seem to be bad either. [...] Ahh, I see. I thought the intent was to read from a file locally. If you're receiving data from a socket, having a circular buffer makes a lot more sense. Thanks for the clarification. Of course, a circular buffer works pretty well for reading local files too, though I'd consider its primary intent would be better suited for receiving data from the network. Although I haven't tested with network sockets, the circular buffer I implemented for iopipe (http://schveiguy.github.io/iopipe/iopipe/buffer/RingBuffer.html) didn't have any significant improvement over a buffer that moves the data still in the buffer. -Steve
Re: Blog post: What D got wrong
On 18-12-2018 19:52, Russel Winder wrote: On Tue, 2018-12-18 at 16:50 +, Neia Neutuladh via Digitalmars-d-announce wrote: Is there a video link for that talk? I'd be interested in hearing it. The videos are here: https://gstconf.ubicast.tv/channels/#gstreamer-conference-2018 I think they recorded the lightning talks as a single video, so you'll have to fast forward to my little bit. If you are only interested in the MeTV part, this is the start of that lighting talk: https://gstconf.ubicast.tv/permalink/v125ac3127116gnuo89h/#start=2561 -- Mike Wey
Re: This Week in D is back
On Monday, 17 December 2018 at 22:01:07 UTC, Adam D. Ruppe wrote: Well, I am getting back into it: http://dpldocs.info/this-week-in-d/Blog.Posted_2018_12_17.html Cool. Keep it going!
Re: This Week in D is back
On Monday, 17 December 2018 at 22:01:07 UTC, Adam D. Ruppe wrote: Well, I am getting back into it: http://dpldocs.info/this-week-in-d/Blog.Posted_2018_12_17.html Fantastic, Adam! Look forward to reading your next posts. Thanks for everything you've done for the d community.
[neovim/vim] ncm2/ncm2-d autocompletion source for d
Hi, neovim/vim8 users out there, if you'd like to have an alternative to deoplete, ncm2 is async and really fast, works out of the box, and it has integration with UltiSnippets to further expand all the arguments of the completion in place. So far, I've been quite satisfied with it, been using for 4 months+, if you're interested check https://github.com/ncm2/ncm2-d out. Cheers.
Re: Blog post: What D got wrong
On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: Not the case in Rust, not the case in how I write D. TBH it's not such a big deal because something has to be typed, I just default to const now anyway instead of auto. @safe and pure though... I'd be interested in seeing some of that Rust code. My impression from Clojure is that an all-immutable style requires leaning heavily on the garbage collector and as far as I know Rust has none.
Re: Announcing Elembuf
On Tue, Dec 18, 2018 at 01:56:18PM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote: > On 12/18/18 10:36 AM, H. S. Teoh wrote: > > On Tue, Dec 18, 2018 at 08:00:48AM +, Cyroxin via > > Digitalmars-d-announce wrote: > > > [...] While the focus of this library is in socket receival, > > > reading from a file doesn't seem to be bad either. > > [...] > > > > Ahh, I see. I thought the intent was to read from a file locally. If > > you're receiving data from a socket, having a circular buffer makes > > a lot more sense. Thanks for the clarification. Of course, a > > circular buffer works pretty well for reading local files too, > > though I'd consider its primary intent would be better suited for > > receiving data from the network. > > Although I haven't tested with network sockets, the circular buffer I > implemented for iopipe > (http://schveiguy.github.io/iopipe/iopipe/buffer/RingBuffer.html) > didn't have any significant improvement over a buffer that moves the > data still in the buffer. [...] Interesting. I wonder why that is. Perhaps with today's CPU cache hierarchies and read prediction, a lot of the cost of moving the data is amortized away. T -- Береги платье снову, а здоровье смолоду.
Re: Blog post: What D got wrong
On Wed, 19 Dec 2018 01:04:24 +, Nathan S. wrote: > On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: >> Not the case in Rust, not the case in how I write D. TBH it's not such >> a big deal because something has to be typed, I just default to const >> now anyway instead of auto. @safe and pure though... > > I'd be interested in seeing some of that Rust code. My impression from > Clojure is that an all-immutable style requires leaning heavily on the > garbage collector and as far as I know Rust has none. It is greatly simplified by automatic memory management. Rust doesn't have a GC, but it has a complex ownership system instead, and that's the basis of its memory management. When that's insufficient, you use reference counting. Besides which, this is about defaults. In cases where your data is actually mutable and it would be awkward to switch to a more Haskell-like way of coding, you can still use that.
Re: Blog post: What D got wrong
On Tuesday, December 18, 2018 6:35:34 AM MST Pjotr Prins via Digitalmars-d- announce wrote: > On Tuesday, 18 December 2018 at 11:25:17 UTC, Jonathan M Davis > > wrote: > > Of course, even if we _did_ have a solution for reversing > > attributes, slapping an attribute on the top of the module > > would still potentially be a maintenance problem, because it's > > then really easy to miss that an attribute is in effect (it's a > > problem that we've had on several occasions with druntime and > > Phobos in the few cases where attributes are mass-applied). So, > > there is no silver bullet here (though regardless of whether > > mass-applying attributes is something that should ever be > > considered good practice, we really should add a way to be able > > to reverse them). > > Thanks Jonathan for your elaborate explanation. I personally have > no problem with the attributes which - in practice - means I > don't use them much unless I want to make sure something is nogc, > for example. For library designers it makes sense to be explicit. > I guess that is where the trade-off kicks in. Maybe it is just a > feature. We argue against specifying them because other languages > are not as explicit. It does add a little noise. In practice, library developers are forced to worry about it more, because it affects everyone using their code, whereas within a program, how valuable it is to worry about them depends on the size of the program and what you expect to get out of them. Very large programs can definitely benefit (especially with @safe and pure), because it reduces how much code you have to worry about when tracking down the problems that those attributes address, but with small programs, the benefit is far more debatable. And for simple scripts and the like, they're almost certainly a waste of time - which is part of why more restrictive attributes are not the default. It's supposed to be easy to write code that doesn't deal with attributes if you don't want to, but they're there for those who do care. The problem of course is that when you do care, they tend to become a bit of a pain. I confess that I do tend to think about things from the standpoint of a library designer though, in part because I work on stuff like Phobos, but also because I tend to break up my programs into libraries as much as reasonably possible. In general, the more that's in a reusable, easily testable library the better. And with that approach, a lot less of the code for your programs is actually in the program itself, and the attributes tend to matter that much more. - Jonathan M Davis
Re: Blog post: What D got wrong
On Tue, Dec 18, 2018 at 06:53:02PM -0700, Jonathan M Davis via Digitalmars-d-announce wrote: [...] > I confess that I do tend to think about things from the standpoint of > a library designer though, in part because I work on stuff like > Phobos, but also because I tend to break up my programs into libraries > as much as reasonably possible. In general, the more that's in a > reusable, easily testable library the better. And with that approach, > a lot less of the code for your programs is actually in the program > itself, and the attributes tend to matter that much more. [...] My recent programming style has also become very library-like, often with standalone library-style pieces of code budding off a messier, experimental code in main() (and ultimately, if the project is long-lasting, main() itself becomes stripped down to the bare essentials, just a bunch of library components put together). But I've not felt a strong urge to deal with attributes in any detailed way; mostly I just templatize everything and let the compiler do attribute inference on my behalf. For the few cases where explicit attributes matter, I still only use the bare minimum I can get away with, and mostly just enforce template attributes using the unittest idiom rather than bother with writing explicit attributes everywhere in the actual code. T -- He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter
Re: Blog post: What D got wrong
On Tuesday, December 18, 2018 7:02:43 PM MST H. S. Teoh via Digitalmars-d- announce wrote: > On Tue, Dec 18, 2018 at 06:53:02PM -0700, Jonathan M Davis via > Digitalmars-d-announce wrote: [...] > > > I confess that I do tend to think about things from the standpoint of > > a library designer though, in part because I work on stuff like > > Phobos, but also because I tend to break up my programs into libraries > > as much as reasonably possible. In general, the more that's in a > > reusable, easily testable library the better. And with that approach, > > a lot less of the code for your programs is actually in the program > > itself, and the attributes tend to matter that much more. > > [...] > > My recent programming style has also become very library-like, often > with standalone library-style pieces of code budding off a messier, > experimental code in main() (and ultimately, if the project is > long-lasting, main() itself becomes stripped down to the bare > essentials, just a bunch of library components put together). But I've > not felt a strong urge to deal with attributes in any detailed way; > mostly I just templatize everything and let the compiler do attribute > inference on my behalf. For the few cases where explicit attributes > matter, I still only use the bare minimum I can get away with, and > mostly just enforce template attributes using the unittest idiom rather > than bother with writing explicit attributes everywhere in the actual > code. That works when you're in control of everything and not making libraries public, but it tends to be worse when you're making stuff publicly available, because then there's a much higher risk of accidentally screwing up someone else's code by breaking an attribute. It's also much worse from a documentation standpoint, because users of the library can't look at the documentation to know which attributes are in effect. That's pretty much unavoidable with heavily templated code, but there are generally going to be fewer maintainence problems with a publicly available library if attributes are explicit. And the more heavily used the library is, the more likely it is that there are going to be problems. It's like how if you want your library to be stable with regards to CTFE, you pretty much have to test that CTFE works in your unit tests. It's easy to forget, and ideally, you wouldn't have to worry about it, but if someone else uses your library and uses one of its functions with CTFE, and you then make a change that doesn't work with CTFE and don't realize it, you'll break their code. Ideally, you wouldn't have to worry about ensuring that stuff works with CTFE (after all, D specifically doesn't require that stuff be marked to work with it), but with regards to publicly available libraries, if it's not tested for, it can become a problem. So, arguably, it's best practice to test that stuff works with CTFE (at least in publicly available libraries), but I doubt that all that many libraries actually do it. And attributes are in the same boat in many respects (especially if attribute inference is used heavily). But again, if you're not making stuff publicly available, it's usually easy to just not worry about attributes (or CTFE-ability) except in those cases where you have to or decide that you need to in order to ensure that a particular attribute and its benefits are in effect. It's when you make stuff publicly available that it becomes more of an issue - especially if the library is heavily used. - Jonathan M Davis
Re: Blog post: What D got wrong
On Tuesday, December 18, 2018 8:00:48 AM MST Steven Schveighoffer via Digitalmars-d-announce wrote: > On 12/17/18 4:42 AM, Dukc wrote: > > On Monday, 17 December 2018 at 09:41:01 UTC, Dukc wrote: > >> On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: > >>> @safe and pure though... > >> > >> Why @safe? Can't you just write "@safe:" on top and switch to > >> @system/@trusted as needed? > > > > Argh, I forgot that you are not supposed to @safe templates away. > > You can apply @safe to anything. It's @trusted you have to be careful > with. > > Of course, it probably won't work for many templates. @safe should only be used on a template if the @safety of the code does not depend on the template arguments, and it frequently does depend on them. Mass-applying attributes should rarely be done with templated code. It already causes enough problems with non-templated code, because it's easy to not realize that an attribute has been mass-applied, but without a way to explicitly mark a templated function so that an attribute is inferred in spite of it being mass-applied, mass-applying attributes with templated code will usually result in attributes being wrongly applied. Now, for any attribute other than @trusted, the worst that you're going to get out of incorrectly applying an attribute to a template is a compilation error when a particular instantiation doesn't work with that attribute, whereas for @trusted it's a disaster in the making. Mass-applying @trusted is almost always a terrible idea. The one exception would maybe be something like the bindings in druntime, where a number of modules do it, because it's just a bunch of C prototypes. But even then, there's a high risk of marking a function as @trusted later when someone adds it and doesn't realize that @trusted was applied. - Jonathan M Davis
Re: Blog post: What D got wrong
On Tuesday, December 18, 2018 1:17:28 AM MST Russel Winder via Digitalmars- d-announce wrote: > On Mon, 2018-12-17 at 12:16 -0800, Walter Bright via > Digitalmars-d-announce > wrote: > > […] > > > > Going pure, however, is much harder (at least for me) because I'm not > > used to > > programming that way. Making a function pure often requires > > reorganization of > > how a task is broken up into data structures and functions. > > > > […] > > I can recommend a short period of working only with Haskell. And then a > short period working only with Prolog. Experience with Java and Python > people trying to get them to internalise the more declarative approach to > software, shows that leaving their programming languages of choice behind > for a while is important in improving their use of their languages of > choice. +1 The only reason that I'm as good at writing functional-style code as I am is because I used Haskell as my goto language for a couple of years towards the end of college. By being forced to program functionally, I got _much_ better at things like recursion, and it significantly improved aspects of my programming in languages like C++ or D. That being said, I think that anyone who programs in such a language longterm by choice has got to be a masochist. Functional programming is a fantastic tool to have in your toolbox, but man does it force you to contort things to make it work in many cases. I've never spent as much time per line of code with any other language as I did with haskell. It's great for stretching your brain but terrible for being productive. I'm sure that folks who always program that way get much better at it, but some problems simply work better with other programming paradigms, and it's fantastic to use a language like D that allows you to program in a variety of paradigms rather than forcing a particular paradigm on you all the time. But without spending a lot of time in a language that forces a particular paradigm, you're likely to be much worse at that particular paradigm in a flexible language such as D. One side effect of having spent as much time as I did with haskell is that I've rarely found the functional nature of D's templates to be much of a problem. Sometimes, it can be, and the addition of static foreach is certainly welcome, but I rarely missed it, because I rarely needed it. The declaritive stuff just tends to fit nicely into the functional paradigm in ways that normal functions often don't. LOL. And it took quite a while before I realized that templates were really a functional language (in fact, I think that I only realized it when I read Bartosz's article on the subject). I just understood how to use them and didn't think about it, though once I did realize it, I felt stupid for not having realized it. - Jonathan M Davis
Re: This Week in D is back
On 12/17/2018 2:01 PM, Adam D. Ruppe wrote: Well, I am getting back into it: http://dpldocs.info/this-week-in-d/Blog.Posted_2018_12_17.html Thank you, Adam!
Re: Blog post: What D got wrong
On Wed, 2018-12-19 at 01:45 +, Neia Neutuladh via Digitalmars-d-announce wrote: > On Wed, 19 Dec 2018 01:04:24 +, Nathan S. wrote: > > On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote: > > > Not the case in Rust, not the case in how I write D. TBH it's not such > > > a big deal because something has to be typed, I just default to const > > > now anyway instead of auto. @safe and pure though... > > > > I'd be interested in seeing some of that Rust code. My impression from > > Clojure is that an all-immutable style requires leaning heavily on the > > garbage collector and as far as I know Rust has none. Rust is garbage collector free. This is why it is appealing to the C (and C++) people who think garbage collectors are anathema. Rust has let and let mut to introduce new bindings and variables respectively, you have to type less for immutable, which his the right way round. If you want mutability, you have to say so explicitly. Single assignment rocks. :-) > It is greatly simplified by automatic memory management. Rust doesn't have > a GC, but it has a complex ownership system instead, and that's the basis > of its memory management. When that's insufficient, you use reference > counting. With Rust (as with most languages) you have to separate stack and heap allocation. The Rust borrow checker carefully tracks all stack usage and (caveat unsafe activity) will not compile code that has any memory problems that the borrow checker can find. For the heap, Rust provides reference counted pointers which work a lot better than the equivalents in C++: std::shared_ptr and std::unique_ptr can be a right pain. Also of course, unlike C++, Rust has very good support for multi-threading in the language and the standard library, mostly built around std::Mutex. Rust integrates all this with std::Option, std::Error, if let, and match in a way that makes dealing with locks and RAII quite simple. C++ may have brought RAII to mainstream programming, but it's support for multiple threads is still very weak comparedto D, Rust, Go, etc. […] -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
