November 29, 2013 Re: D vs Go in real life | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris | On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote: > > [1] Raises the question whether we've been conditioned by C or whether C was intuitive. My theory is that Go is from the beginning intended to be a modernized C. If I look at C from that perspective I can always explain why things in Go are the way they are. The syntax is only in part awkward as Go is in some ways inspired by Oberon. But what suprises me is that with a language feature as simple as delegates you can solve so many design problems that well. I wonder whether this is a result of a lot of thought or only a result of adding some language feature that frees you from having to write myStruct1->field1->myStruct2->field2-> ... |
November 29, 2013 Re: D vs Go in real life | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bienlein | bearophile I wonder, if it's just the way I've learned how to program that I prefer byte[] buf; to buf []byte; // Which seems a bit awkward to me. "it's called 'buf' and it is an array of ... of what???? Drum roll r-r-r-r-r ... Of bytes! Yeah!!! Maybe it's because in my culture we read (and think?) from left to right. Mind you, the apple symbol on the Mac is in the upper left corner. The "Launcher" in Ubuntu is on the left hand side by default. The folders and contacts in Gmail are on the left hand side. Your mouse cursor is in the left half of the screen most of the time. On Friday, 29 November 2013 at 12:16:07 UTC, Bienlein wrote: > On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote: >> >> [1] Raises the question whether we've been conditioned by C or whether C was intuitive. > > My theory is that Go is from the beginning intended to be a modernized C. If I look at C from that perspective I can always explain why things in Go are the way they are. The syntax is only in part awkward as Go is in some ways inspired by Oberon. Very good point. But do we need to modernize C? C is only one step away form assembly. So if you modernize this, your still on the same level. > But what suprises me is that with a language feature as simple as delegates you can solve so many design problems that well. I wonder whether this is a result of a lot of thought or only a result of adding some language feature that frees you from having to write myStruct1->field1->myStruct2->field2-> ... I like structs and classes for the fact that they can handle stuff on their own. But we do have delegation in D and it is a useful feature in Objective-C too. structs/classes and delegation are not mutually exclusive. And your question is very good. Is delegation in Go a "work around" within a limited language or is it a design feature? If Go is modernized C, will it end up like C++? |
November 29, 2013 Re: D vs Go in real life | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris | On Friday, 29 November 2013 at 12:53:02 UTC, Chris wrote: > Very good point. But do we need to modernize C? C is only one step away form assembly. So if you modernize this, your still on the same level. Agree. If I accept a language that simple then it needs to deliver execution speed. And Go fails in that domain. > delegation are not mutually exclusive. And your question is very good. Is delegation in Go a "work around" within a limited language or is it a design feature? The question I ask myself whether delegation is a nglected gross concept. I don't mean 1:1 associations as such, of course, but I mean that you can simply say myStruct1-fieldN instead of myStruct1->field1-> ... myStructN->fieldN. >But we do have delegation in D and it is a useful feature in Objective-C too. Concerning D you mean mixins? Yeah, I wonder why no JVM language has them. On the JVM all languages on a higher level than Java have chosen to go with traits only (Scala, Kotlin). Groovy has the @Delegate annotation, but the Groovy compiler doesn't complain in case some diamond problem pops up in your code. So it's not truly for real. With regard to Objective-C you mean the instancesRespondToSelector: thing? But this is some kind of hack. In Go the compiler checks for correctness. > If Go is modernized C, will it end up like C++? Well, at least Go is very consistent. No tons of complicated special cases you need to know about. Rust did things very well here. It is made for speed and low memory consumption. The way it adds OO elements to the language is not that minimalistic. I don't see how Go can compete with Java when a company is already using Java as Go runs at about the same speed. They have done concurrency very well with goroutines and channels. Some of the excitement about Go clearly comes from concurrency being well done. They have a tool that can analyse the channels in some Go code and tell you whether a deadlock is inevitably bound to happen. That's not bad. I think Go is more for C or Python people and for Java/.NET people that want to do a little bit of system programming in their spare time. -- Bienlein |
November 29, 2013 Re: D vs Go in real life | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bienlein | On 2013-11-29 09:29, 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. You can do the exact thing in D with the help of UFCS. BTW, you need to decide in advance if you should use a class or a struct in D. That's basically the same thing as choosing if you need a template. -- /Jacob Carlborg |
November 29, 2013 Re: D vs Go in real life | ||||
---|---|---|---|---|
| ||||
Posted in reply to brad clawsie | On 2013-11-29 06:14, 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. > > 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. Why did you install dmd from source and not the same way as Go? It's a bit unfair comparison. Dub is a package manager for D, with many libraries available. -- /Jacob Carlborg |
November 29, 2013 Re: D vs Go in real life | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Friday, 29 November 2013 at 12:11:26 UTC, bearophile wrote:
> 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
"byte array named a" vs "a is an array of bytes". Either is fine.
I agree that sometimes the latter is better for complex types.
|
November 29, 2013 Re: D vs Go in real life | ||||
---|---|---|---|---|
| ||||
Posted in reply to Craig Dillabaugh | On 11/28/13 9:49 PM, Craig Dillabaugh wrote:
> On Friday, 29 November 2013 at 05:14:14 UTC, brad clawsie wrote:
>> 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.
Thanks Brad for the compare & contrast. Craig, I think funding is part of the story but not all - our community could get better at being perfectionist about the out-of-the box experience.
Go is underpowered but its good execution is undeniably attractive: the first experience, the implementation works as advertised, and the networking libraries show their authors' expertise. We stand to learn from that.
Andrei
|
November 29, 2013 Re: D vs Go in real life | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris Cain | On Friday, 29 November 2013 at 05:51:48 UTC, Chris Cain wrote: > 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. Huh? git clone https://github.com/D-Programming-Language/dmd.git git clone https://github.com/D-Programming-Language/druntime.git git clone https://github.com/D-Programming-Language/phobos.git cd ./dmd/src make -f posix.mak MODEL=64 RELEASE=1 cd ../../druntime make -f posix.mak MODEL=64 DMD=../dmd/src/dmd RELEASE=1 cd ../phobos make -f posix.mak MODEL=64 DMD=../dmd/src/dmd RELEASE=1 After that just make symlink to dmd binary and add Phobos/druntime paths to dmd.conf and you are ready to go. |
November 29, 2013 Re: D vs Go in real life | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Fri, 2013-11-29 at 13:11 +0100, bearophile wrote: > 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. I believe it should be read as "slice of bytes" not "array of bytes". -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder |
November 29, 2013 Re: D vs Go in real life | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris | On Friday, 29 November 2013 at 12:06:17 UTC, Chris wrote: > [1] Raises the question whether we've been conditioned by C or whether C was intuitive. I'll answer for you: C was very counter intuitive which is why no one has done exactly what it did since. Look up the spiral rule for reading types in C. Most often it can be thought of being read from right to left, but that's not the actual reading. http://c-faq.com/decl/spiral.anderson.html D fixes this massive issue to a certain degree, but it still feels backwards to me, despite me having been raised with "types on the left of the name". After using a language doing it "the right way" for awhile, you quickly adapt and realize it makes the most sense. At least, that's the way that I feel. |
Copyright © 1999-2021 by the D Language Foundation