On 11/28/13 8:07 AM, Bienlein wrote:
> On Friday, 22 November 2013 at 14:43:11 UTC, Chris wrote:
>
>> Go is web-oriented, so it seems, and I'm sure it will be marketed as
>> the "one size fits all" solution for web development, multi-core and
>> whatnot. But D goes deeper. D raises fundamental questions about how a
>> good program should look like, what is good / practicable. I know that
>> this approach doesn't sell, but it's the best I've ever come across. D
>> makes you think and re-assess your own code time and again.
>
> I basically I agree with this. But lately, I was asking myself, though,
> whether me classifying Go as simplistic was wrong. I programmed the
> canonical Scala trait sample in Go. In that sample from the Scala book
> there is a trait Rectangular with a upperLeft and bottomRight point.
> Some class Rectangle extends trait Rectangular. I could get the same
> accomplished using delegation in Go. The solution in Go is much much
> simpler and from what I can tell the power is the same. So this made me
> think.

Interesting. Could you please create a paste with the two code samples?

Thanks,

Andrei

On Thursday, 28 November 2013 at 16:07:47 UTC, Bienlein wrote:
> ...
> -- Bienlein

IMHO, problem with go simplicity is not as much as being not expressive enough to do something as with being forced to move lot of things to run-time. Which is not actually a problem for many applications but very discouraging for certain type of programmers.

this has been a great thread and I've found a lot of the replies  very insightful. I've been programming in Go at work for about a year or so now, so I have some opinions on Go that I believe are reasonably informed, while I am still a D novice but hope to continue learning.

First, let me say that it is obvious that, by design, D is a more powerful language than Go. Go's simplicity will either be an advantage or a deal-breaker based on who you ask.

On my vps instance last night I tried to create an initial D programming environment, with the following tools:

- dmd
- dub
- vibe.d
- ldc (not strictly necessary but I've heard so many good things about it)

First I tried installing dmd from source, which was fine but then I would get strange errors about referring to a file "object.d" when trying to build dub. Some poking around on the web resulted in the advice of installing the pre-built dmd binary that is in the release distribution. Now I was able to build dub, although it was strange to see two completely different build mechanisms for dmd and dub - dmd using a makefile and dub using a sh script wrapper. vibe.d was easier to install once dub worked. Over an hour just to get basic tools installed, although I feel HTTP serving is so common that it should be one of the accepted "batteries included" by default.

If this were Go, I would have installed the default build for my platform and had an http server in my standard sdk and everything else available by "go get", which has never failed to work flawlessly for me in a year of dealing with code from the web. This is one reason why there are already so many libraries for Go - it is trivial to expose your code to other developers via the supported toolchain.

This might not be a fair assessment given my shallow experience with D, but it seems much less polished relative to Go for setting up a development environment and working with code from the web.

Go's tools can be criticized as precluding operating system package managers, if people feel that criticism is valid, maybe a solution is something like the Haskell Platform, which was a reasonable response to the same criticism with haskell in years back - that setting up a development environment with basic consistent libraries was very painful. Haskell Platform does not seek to preclude operating system package managers.

Anyway, I hope this didn't seem too harsh. I still am playing with D and hopefully at some point in the future, package managers will address some of these needs.

brad

On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:
> this has been a great thread and I've found a lot of the replies  very insightful. I've been programming in Go at work for about a year or so now, so I have some opinions on Go that I believe are reasonably informed, while I am still a D novice but hope to continue learning.
>
> First, let me say that it is obvious that, by design, D is a more powerful language than Go. Go's simplicity will either be an advantage or a deal-breaker based on who you ask.
>
> On my vps instance last night I tried to create an initial D programming environment, with the following tools:
>
> - dmd
> - dub
> - vibe.d
> - ldc (not strictly necessary but I've heard so many good things about it)
>
> First I tried installing dmd from source, which was fine but then I would get strange errors about referring to a file "object.d" when trying to build dub. Some poking around on the web resulted in the advice of installing the pre-built dmd binary that is in the release distribution. Now I was able to build dub, although it was strange to see two completely different build mechanisms for dmd and dub - dmd using a makefile and dub using a sh script wrapper. vibe.d was easier to install once dub worked. Over an hour just to get basic tools installed, although I feel HTTP serving is so common that it should be one of the accepted "batteries included" by default.

So when you say you would install Go using the default build,
did you mean as a binary, or do you mean some sort of default
build configuration (from source) for your platform?
If as binary then this comparison is a bit unfair here.

For me (OpenSuse) all I need to do is:
sudo zypper in dmd

I've used the pre-built binaries on various Windows & Linux
OSs with no troubles.

If you want to build from source you might want to have a look at DVM:

https://bitbucket.org/doob/dvm/wiki/Home

(I don't have any experience with it personally, so I can't say how trouble free your experience would be).

>
> If this were Go, I would have installed the default build for my platform and had an http server in my standard sdk and everything else available by "go get", which has never failed to work flawlessly for me in a year of dealing with code from the web. This is one reason why there are already so many libraries for Go - it is trivial to expose your code to other developers via the supported toolchain.
>
> This might not be a fair assessment given my shallow experience with D, but it seems much less polished relative to Go for setting up a development environment and working with code from the web.
Well D is a volunteer effort while Go is being backed by the worlds biggest web company!  That sort of accounts for that I suppose. There has been recognition in the community that this needs to improve, but progress is only so fast with the limited resources.

>
> Go's tools can be criticized as precluding operating system package managers, if people feel that criticism is valid, maybe a solution is something like the Haskell Platform, which was a reasonable response to the same criticism with haskell in years back - that setting up a development environment with basic consistent libraries was very painful. Haskell Platform does not seek to preclude operating system package managers.
>
> Anyway, I hope this didn't seem too harsh. I still am playing with D and hopefully at some point in the future, package managers will address some of these needs.
>
> brad

Hope you enjoy your experience with D.

On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:
> First I tried installing dmd from source, which was fine but then I would get strange errors about referring to a file "object.d" when trying to build dub. Some poking around on the web resulted in the advice of installing the pre-built dmd binary that is in the release distribution.

I really have to agree. I recently had to set up an environment for contributing to phobos but the whole experience was a bit ... tedious. I ended up just using dmd.2.064.2.zip and putting the git repos in the src folder and making a bunch of scripts to move the built binaries into their correct positions. Being in the unique position of programming on Windows, Mac, and Linux, I've had to rewrite the coping script differently for each one. Windows is the worst for that sort of thing, but that's to be expected.

The whole build process is a lot more involved than it really should be. Ideally you should be able to clone dmd, phobos, and druntime and just have everything compile and be put into a relative path together and just "work". Maybe alert you if you don't have phobos and druntime to build. Ultimately, you really "have to" download the binary version if you want it to work transparently, but it would be nice if it were easy enough to build from source that a printed 1 page guide would get you 100% running.

> I feel HTTP serving is so common that it should be one of the accepted "batteries included" by default.

That I'm not sure I'd agree with. Maybe getting stuff via HTTP (we have curl at a.t.m.) but serving HTTP files really needs something more substantial than I'd feel comfortable being in the standard library. Something too simple would likely not be used in favor of something like vibe.d while something the size of vibe.d probably is a bit too expansive to really be considered for part in the standard library. Not to mention the fact that vibe.d is in reasonably rapid development. The speed of vibe.d releases outpaces DMD releases and I think that's a positive thing overall.

Plus I feel like such an approach might make "simpler" things suffer (or, at least, make them feel like they suffer). Every time I use python I think "it's so nice that I can write an advanced http server with ssl encryption serving up a calculated meaning of life and the last digit of pi in one line, but I have to write an iterator to iterate over elements pairwise, which I'd really think should be in the standard library somewhere." (A "recipe" for it is in itertools which, strangely, suggests that they know how often it might be needed but failed to add it as an actual part of the standard library, but I digress...)

This reply is not intended as a specific reply to Brad, so no pun inside, really, but...

I always wonder for how much attention there's out there regarding the setting up of the development environment: from my experience, I very very like the D simplicity, just grab a zip, and inside you have all the basic for every supported os. The _only_ missing thing in the zip is dub (guys, that MUST be in the official distribution).

It's so easy that when I hear about installer, packager, etc, etc I scratch my head... O_o

/Paolo

On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:

<snip>
> This might not be a fair assessment given my shallow experience with D, but it seems much less polished relative to Go for setting up a development environment and working with code from the web.
<snip>
>
> brad

On Thursday, 28 November 2013 at 19:22:06 UTC, Andrei Alexandrescu wrote:

> Interesting. Could you please create a paste with the two code samples?
>
> Thanks,
>
> Andrei

Hello,

here is the Go code:

package main

import (
	"fmt"
)

type Point struct {
	x, y int
}

type Rectangular struct {
	topLeft, bottomRight Point
}

func (self Rectangular) Left() int {
	return self.topLeft.x
}

func (self Rectangular) Right() int {
	return self.bottomRight.x
}

func (self Rectangular) Width() int {
	return self.Right() - self.Left()
}

type Rectangle struct {
	Rectangular
}

func NewRectangle(topLeft, bottomRight Point) *Rectangle {
	rectangle := new(Rectangle)
	rectangle.Rectangular.topLeft = topLeft
	rectangle.Rectangular.bottomRight = bottomRight
	return rectangle
}

func main() {
	rectangle := NewRectangle(Point{1, 2}, Point{12, 2})
	fmt.Println(rectangle.Width())
}

And this is the Scala code:

import java.awt.Point

trait Rectangular {

  protected val topLeft: Point
  protected val bottomRight: Point

  def width : Int = bottomRight.x - topLeft.x
}

class Rectangle(val topLeft: Point, val bottomRight: Point) extends Rectangular

object RunIt extends Application {

  val rectangle = new Rectangle(new Point(1, 2), new Point(12, 2))
  println(rectangle.width)

}

I guess in D you would do something like this:

mixin template Rectangular() {
  Point x, y;
}

mixin Rectangular;

struct Rectangle {
  mixin Rectangular;
}


Note that in the Scala code Rectangular.topLeft and Rectangular.bottomRight are protected. Since the solution in Go makes use of delegation this can only be accomplished in Go through making getters public or defining Rectangle in the same package as Rectangular. Since Go does not have constructors the way to initialize a Rectangle in Go looks more clumsy.

An interesting point to me is that Rectangular in Go is just an ordinary struct whereas Rectangular is a special construct in Scala (being a trait) and in D (being a mixin). So Scala and D force you to design ahead, e.g. you have to decide in advance whether to make Rectangular a trait or mixin. Thereafter, Rectangular is not of use on its own, only when used as a trait or mixin.

What makes me think is whether delegation as a language construct has been underrated and whether Go now makes this obvious.

-- Bienlein

On Thursday, 28 November 2013 at 19:25:56 UTC, Dicebot wrote:
> On Thursday, 28 November 2013 at 16:07:47 UTC, Bienlein wrote:
>> ...
>> -- Bienlein
>
> IMHO, problem with go simplicity is not as much as being not expressive enough to do something as with being forced to move lot of things to run-time.

Could you just quickly describe what you mean by "being forced to move
lot of things to run-time"? I simply don't see what you are refering to.

Thanks.

On Friday, 29 November 2013 at 08:29:04 UTC, Bienlein wrote:
> On Thursday, 28 November 2013 at 19:22:06 UTC, Andrei Alexandrescu wrote:
>
>> Interesting. Could you please create a paste with the two code samples?
>>
>> Thanks,
>>
>> Andrei
>
> Hello,
>
> here is the Go code:
>
> package main
>
> import (
> 	"fmt"
> )
>
> type Point struct {
> 	x, y int
> }
>
> type Rectangular struct {
> 	topLeft, bottomRight Point
> }
>
> func (self Rectangular) Left() int {
> 	return self.topLeft.x
> }
>
> func (self Rectangular) Right() int {
> 	return self.bottomRight.x
> }
>
> func (self Rectangular) Width() int {
> 	return self.Right() - self.Left()
> }
>
> type Rectangle struct {
> 	Rectangular
> }
>
> func NewRectangle(topLeft, bottomRight Point) *Rectangle {
> 	rectangle := new(Rectangle)
> 	rectangle.Rectangular.topLeft = topLeft
> 	rectangle.Rectangular.bottomRight = bottomRight
> 	return rectangle
> }
>
> func main() {
> 	rectangle := NewRectangle(Point{1, 2}, Point{12, 2})
> 	fmt.Println(rectangle.Width())
> }
>
> And this is the Scala code:
>
> import java.awt.Point
>
> trait Rectangular {
>
>   protected val topLeft: Point
>   protected val bottomRight: Point
>
>   def width : Int = bottomRight.x - topLeft.x
> }
>
> class Rectangle(val topLeft: Point, val bottomRight: Point) extends Rectangular
>
> object RunIt extends Application {
>
>   val rectangle = new Rectangle(new Point(1, 2), new Point(12, 2))
>   println(rectangle.width)
>
> }
>
> I guess in D you would do something like this:
>
> mixin template Rectangular() {
>   Point x, y;
> }
>
> mixin Rectangular;
>
> struct Rectangle {
>   mixin Rectangular;
> }
>
>
> Note that in the Scala code Rectangular.topLeft and Rectangular.bottomRight are protected. Since the solution in Go makes use of delegation this can only be accomplished in Go through making getters public or defining Rectangle in the same package as Rectangular. Since Go does not have constructors the way to initialize a Rectangle in Go looks more clumsy.
>
> An interesting point to me is that Rectangular in Go is just an ordinary struct whereas Rectangular is a special construct in Scala (being a trait) and in D (being a mixin). So Scala and D force you to design ahead, e.g. you have to decide in advance whether to make Rectangular a trait or mixin. Thereafter, Rectangular is not of use on its own, only when used as a trait or mixin.
>
> What makes me think is whether delegation as a language construct has been underrated and whether Go now makes this obvious.
>
> -- Bienlein

Thanks for the example. To be honest the Go code looks like a glorified version of JavaScript to me. I think it is way too "obfuscated", and Go syntax seems a bit like someone _always_ wanted to do it differently, just a personal preference, no matter what people intuitively expect.[1]

x, y int

I prefer left-to-right:

"type integer named x (or whatever)", i.e. int x;

But why on earth (a []byte)? The type is important, not the name. I can give it any name. a, inComing, inBytes, response, draculaBytes ...

[1] Raises the question whether we've been conditioned by C or whether C was intuitive.

Chris:

> But why on earth (a []byte)? The type is important, not the name. I can give it any name. a, inComing, inBytes, response, draculaBytes ...

I read that type "array of byte(s)", I find it a bit better than D syntax, especially when types become a little more complex.

Bye,
bearophile