March 18, 2013
On Saturday, 16 March 2013 at 14:42:58 UTC, Suliman wrote:
> http://versusit.org/rust-vs-d

I just saw this post on the Rust subreddit: http://www.reddit.com/r/rust/comments/1agj5i/rust_vs_dlang_d_programming_language_discussion/ (that is, oddly, linking to this discussion and not the original post), and was very confused by the "Rust" code. Quoting kibwen on Reddit, "Not only are the Rust snippets using ancient 0.0 syntax, they are written such that they would never compile in the first place."

The io module isn't in std, integers don't have a .times method (that I know about, anyway), "alt" is now "match" (I think), and there is no "try".
March 18, 2013
On Sunday, 17 March 2013 at 06:57:32 UTC, Russel Winder wrote:
>
> Comments such as "There are no threads in D out of the box, but they can
> be implemented with the use of language libraries" seems unfair all
> round. The D platform is compiler + Phobos so there are threads out of
> the box. D also has spawn just as Rust does; out of the box.

Well, there is an advantage of having stuff built-in. Look at C++, it's annoying to type #include <string> whenever you want to use such a basic type as string. In D a basic program will also require multiple imports for usually the same basic behaviour. In C# and Java this is remedied by IDE autocompleting the import list, in D we don't have it (yet ;)). Imagine if you had to import std.string; everytime you wanted to use a string type. It wouldn't be the most fun thing to use. IMHO there's nothing wrong in putting the basic functionality built-in. It doesn't matter if it's somehow baked into the language or as an auto-import library, it's a matter of convenience but in these cases it's worth it (IMHO).
March 18, 2013
On 3/18/2013 3:25 AM, bearophile wrote:
> Walter Bright:
>
>> That's just not an issue when you have 64 bits of address space. You can still
>> have 4 billion stacks of 4 billion bytes each.
>
> At this point I suggest you to study exactly why Rust developers have decided to
> use a segmented stack. It seems to work well for them.

If you know a reason, please post one.

March 18, 2013
Am 18.03.2013 13:21, schrieb Andrei Alexandrescu:
> On 3/18/13 1:46 AM, Rory McGuire wrote:
>> The reason I use golang and not dlang for development at work is because
>> debugging is straightforward no weird segfaults after you program has
>> been running for a couple of days.
>>
>> Their debugging and benchmark tools are really good and the
>> documentation is fantastic.
>
> Could you please go into details on the debugging and benchmarking
> tools? Thanks.

From the time I used Go.

You can use gdb or if you prefer something like a debugger IDE, LiteIDE

http://code.google.com/p/liteide/

For benchmarking there is an old blog entry about the tools.

http://blog.golang.org/2011/06/profiling-go-programs.html

Nothing that you cannot find in other languages, unless there is now something much better available.

--
Paulo



March 18, 2013
18-Mar-2013 14:25, bearophile пишет:
> Walter Bright:
>
>> That's just not an issue when you have 64 bits of address space. You
>> can still have 4 billion stacks of 4 billion bytes each.
>
> At this point I suggest you to study exactly why Rust developers have
> decided to use a segmented stack. It seems to work well for them.
>

Walter's position is crystal clear.

IMHO virtual memory was designed among other things to avoid piecing together segmented memory blocks by hand. Memory manager (OS) will od the whole dirty work for you and even hardware assists the process resulting in decent speed and complete transparency of operation. Why destroy this marvelous creation of hardware and OS developers?

The whole segmented stack thing smells a lot like good ol' 16-bit days and is a step backwards unless you assume that:

a) There is no virtual memory i.e. no MMU. Well, some MCU units are still like this but the trend goes towards having MMU even on tiny chips.

b) Virtual ram / physical ram relation is close to 1 or even worse, like in 32-bit OS running on 8G desktops. As for virtual memory to be truly exploitable address space better be many times the total ram, the more the better.

Both cases do not seem likely to be related to the future technology like at all.

> Bye,
> bearophile


-- 
Dmitry Olshansky
March 18, 2013
On 3/18/2013 12:08 PM, Paulo Pinto wrote:
> Am 18.03.2013 13:21, schrieb Andrei Alexandrescu:
>> On 3/18/13 1:46 AM, Rory McGuire wrote:
>>> The reason I use golang and not dlang for development at work is because
>>> debugging is straightforward no weird segfaults after you program has
>>> been running for a couple of days.
>>>
>>> Their debugging and benchmark tools are really good and the
>>> documentation is fantastic.
>>
>> Could you please go into details on the debugging and benchmarking
>> tools? Thanks.
>
>  From the time I used Go.
>
> You can use gdb or if you prefer something like a debugger IDE, LiteIDE
>
> http://code.google.com/p/liteide/
>
> For benchmarking there is an old blog entry about the tools.
>
> http://blog.golang.org/2011/06/profiling-go-programs.html
>
> Nothing that you cannot find in other languages, unless there is now something
> much better available.

dmd has the -profile, to automatically generate a profile report, and -cov, to tell you which lines were executed and how many times.

March 19, 2013
On Monday, 18 March 2013 at 19:39:38 UTC, Walter Bright wrote:
> On 3/18/2013 12:08 PM, Paulo Pinto wrote:
>> Am 18.03.2013 13:21, schrieb Andrei Alexandrescu:
>>> On 3/18/13 1:46 AM, Rory McGuire wrote:
>>>> The reason I use golang and not dlang for development at work is because
>>>> debugging is straightforward no weird segfaults after you program has
>>>> been running for a couple of days.
>>>>
>>>> Their debugging and benchmark tools are really good and the
>>>> documentation is fantastic.
>>>
>>> Could you please go into details on the debugging and benchmarking
>>> tools? Thanks.
>>
>> From the time I used Go.
>>
>> You can use gdb or if you prefer something like a debugger IDE, LiteIDE
>>
>> http://code.google.com/p/liteide/
>>
>> For benchmarking there is an old blog entry about the tools.
>>
>> http://blog.golang.org/2011/06/profiling-go-programs.html
>>
>> Nothing that you cannot find in other languages, unless there is now something
>> much better available.
>
> dmd has the -profile, to automatically generate a profile report, and -cov, to tell you which lines were executed and how many times.

That was my point.

I was initially attracted to Go given its similarity with Oberon concepts and was even enthusiastic to try to contribute something.

However the way some Go concepts are sold as being new, while other languages outside the C world have had them for years, and the resistance of Go community to anything new look elsewhere.

This answer from one of their developers is a good example,
http://9fans.net/archive/2008/08/134

--
Paulo



March 25, 2013
On Mon, Mar 18, 2013 at 2:21 PM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

>
> Could you please go into details on the debugging and benchmarking tools? Thanks.
>

Hi Andrei,

Apologies for not replying sooner.

Perhaps it is actually just the "feel" of the debugging and benchmarking,
and the general completeness of the *documentation*.
This set of slides: http://talks.golang.org/2012/simple.slide introduces
pretty much everything you need to know about Go. Graphs that show memory
allocation
by which function allocated, and the time taken of each function (d has a
way to get the data as Walter points out). Ah the profiling was only
mentioned in that slide set.
The profiling doc is here:
http://blog.golang.org/2011/06/profiling-go-programs.html
It is all super easy, and documented so that you can do it now. All in one
place. And I think possibly the most important thing about it is that it
does what it says.
The standard library all works together as a whole. Another thing which is
different and makes Go easier or faster to pick up is that there is often
only one way to
do something. D excels in allowing a multitude of ways to do things.

Do you know of any all encompassing slide set of document that one can pick up the information contained in http://talks.golang.org/2012/simple.slide? Is there an equivalent to http://blog.golang.org/2011/06/profiling-go-programs.html?


March 25, 2013
On 3/25/13 8:02 AM, Rory McGuire wrote:
> Perhaps it is actually just the "feel" of the debugging and
> benchmarking, and the general completeness of the *documentation*.
> This set of slides: http://talks.golang.org/2012/simple.slide introduces
> pretty much everything you need to know about Go. Graphs that show
> memory allocation
> by which function allocated, and the time taken of each function (d has
> a way to get the data as Walter points out). Ah the profiling was only
> mentioned in that slide set.
> The profiling doc is here:
> http://blog.golang.org/2011/06/profiling-go-programs.html
> It is all super easy, and documented so that you can do it now. All in
> one place. And I think possibly the most important thing about it is
> that it does what it says.
> The standard library all works together as a whole. Another thing which
> is different and makes Go easier or faster to pick up is that there is
> often only one way to
> do something. D excels in allowing a multitude of ways to do things.
>
> Do you know of any all encompassing slide set of document that one can
> pick up the information contained in
> http://talks.golang.org/2012/simple.slide? Is there an equivalent to
> http://blog.golang.org/2011/06/profiling-go-programs.html?

Thanks, Rory, these are good reads. We should get some articles too, we definitely have most of the technical pieces in place!

Andrei

March 26, 2013
On 3/25/2013 5:02 AM, Rory McGuire wrote:
> The profiling doc is here: http://blog.golang.org/2011/06/profiling-go-programs.html
> It is all super easy, and documented so that you can do it now.

What it says about profiling:

"To start tuning the Go program, we have to enable profiling. If the code used the Go testing package's benchmarking support, we could use gotest's standard -cpuprofile and -memprofile flags. In a standalone program like this one, we have to import runtime/pprof and add a few lines of code:"
[... bunch of code you have to copy/pasta in ...]
"After adding that code, we can run the program with the new -cpuprofile flag and then run gopprof to interpret the profile."


How to do profiling with the dmd D compiler:

1. Add the -profile switch to the command line.

2. Read the report generated.

To do coverage analysis:

1. Add the -cov switch to the command line.

2. Read the report generated.

That's it.