www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A reason to choose D over Go

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
This blog post describes what to consider when switching from python to go.

http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/#tips

It's very interesting, because the long list of things to give up for
more efficient go code reads like an argumentation against choosing go
from a D perspective.
And given that D is on par with Python's expressiveness, we should
really emphasize this aspect.

I recently made a pull request for a go tool and spent about half an
hour trying to find some function to test whether an array contains a
particular element. I also asked on #go-nuts to confirm I didn't miss
anything, but you're really supposed to write an explicit loop.

https://github.com/buger/gor/pull/149/files#diff-b8b346beabeabdf0fca6f0b6893ce82bR42

That's what you would write in other languages.

```py
if "chunked" in request.transfer_encodings:
    return
```

```ruby
return if request.transfer_encodings.include? 'chunked'
```

```d
if (request.transferEncodings.canFind("chunked"))
    return;
```

```c++
const auto& arr = request.transfer_encodings;
if (find(arr.begin(), arr.end(), string("chunked")) != arr.end())
    return;
```

There exists some functionality for sorted arrays (only int, float, and
string), but that isn't applicable here.
http://golang.org/pkg/sort/

While go will hardly ever have good support for algorithms, because of
the lack of overloads and generics, they also choose against adding such
trivial, but often needed, algorithms to the basic types.
With a functional programming (or C++ algo) background, I find this very
hard to get used to.
Repeatedly writing out such trivial code often mixes different levels of
abstraction and is one of the reasons why go code is so noisy, manual
error code handling being another one.
Mar 21 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
This is a funny workaround:

http://bouk.co/blog/idiomatic-generics-in-go/
Mar 21 2015
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Saturday, 21 March 2015 at 23:14:58 UTC, Ola Fosheim Grøstad 
wrote:

 This is a funny workaround:

 http://bouk.co/blog/idiomatic-generics-in-go/


And someone found a hole to implement it:

https://www.reddit.com/r/golang/comments/2hw356/idiomatic_generics_in_go/ckwpfms

"The interpretation of the ImportPath is implementation-dependent 
but it is typically a substring of the full file name of the 
compiled package and may be relative to a repository of installed 
packages." -- Go Spec


     import (
     "templates.Map{int, string}"
     )

Hahahaha.
Mar 26 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 26 March 2015 at 18:33:17 UTC, Jesse Phillips wrote:

     import (
     "templates.Map{int, string}"
     )

 Hahahaha.


It is crazy stuff like that that makes fringe languages more fun 
to read about than the big serious ones. ;)
Mar 26 2015
prev sibling next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
The moment I realised that Go requires you to write loops was the
moment I decided we were done.

I actually think that there are two large categories of
programmers: those like writing the same loops over and over
again and those who use algorithms.


On Saturday, 21 March 2015 at 22:16:10 UTC, Martin Nowak wrote:

 This blog post describes what to consider when switching from 
 python to go.

 http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/#tips

 It's very interesting, because the long list of things to give 
 up for
 more efficient go code reads like an argumentation against 
 choosing go
 from a D perspective.
 And given that D is on par with Python's expressiveness, we 
 should
 really emphasize this aspect.

 I recently made a pull request for a go tool and spent about 
 half an
 hour trying to find some function to test whether an array 
 contains a
 particular element. I also asked on #go-nuts to confirm I 
 didn't miss
 anything, but you're really supposed to write an explicit loop.

 https://github.com/buger/gor/pull/149/files#diff-b8b346beabeabdf0fca6f0b6893ce82bR42

 That's what you would write in other languages.

 ```py
 if "chunked" in request.transfer_encodings:
     return
 ```

 ```ruby
 return if request.transfer_encodings.include? 'chunked'
 ```

 ```d
 if (request.transferEncodings.canFind("chunked"))
     return;
 ```

 ```c++
 const auto& arr = request.transfer_encodings;
 if (find(arr.begin(), arr.end(), string("chunked")) != 
 arr.end())
     return;
 ```

 There exists some functionality for sorted arrays (only int, 
 float, and
 string), but that isn't applicable here.
 http://golang.org/pkg/sort/

 While go will hardly ever have good support for algorithms, 
 because of
 the lack of overloads and generics, they also choose against 
 adding such
 trivial, but often needed, algorithms to the basic types.
 With a functional programming (or C++ algo) background, I find 
 this very
 hard to get used to.
 Repeatedly writing out such trivial code often mixes different 
 levels of
 abstraction and is one of the reasons why go code is so noisy, 
 manual
 error code handling being another one.
Mar 21 2015
parent reply "Martin Nowak" <code dawg.eu> writes:
On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote:

 I actually think that there are two large categories of
 programmers: those like writing the same loops over and over
 again and those who use algorithms.


I agree, at some point I learned that there is a huge cultural 
distinction between C and C++ programmers.
Mar 21 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote:

 On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote:

 I actually think that there are two large categories of
 programmers: those like writing the same loops over and over
 again and those who use algorithms.


 I agree, at some point I learned that there is a huge cultural 
 distinction between C and C++ programmers.


yes, the other main distinction are the people who correctly put 
the * next to the type because it's part of the type, or the 
wrong people who put it next to the variable name because they're 
heathens
Mar 21 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote:

 On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote:

 On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote:

 I actually think that there are two large categories of
 programmers: those like writing the same loops over and over
 again and those who use algorithms.


 I agree, at some point I learned that there is a huge cultural 
 distinction between C and C++ programmers.


 yes, the other main distinction are the people who correctly 
 put the * next to the type because it's part of the type, or 
 the wrong people who put it next to the variable name because 
 they're heathens


What is the type of b here ?

int* a, b;
Mar 21 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 22 March 2015 at 02:32:38 UTC, deadalnix wrote:

 On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote:

 On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote:

 On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote:

 I actually think that there are two large categories of
 programmers: those like writing the same loops over and over
 again and those who use algorithms.


 I agree, at some point I learned that there is a huge 
 cultural distinction between C and C++ programmers.


 yes, the other main distinction are the people who correctly 
 put the * next to the type because it's part of the type, or 
 the wrong people who put it next to the variable name because 
 they're heathens


 What is the type of b here ?

 int* a, b;


int* because I don't use a language that's ruined by C baggage.
Mar 21 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 22 March 2015 at 02:36:03 UTC, weaselcat wrote:

 On Sunday, 22 March 2015 at 02:32:38 UTC, deadalnix wrote:

 On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote:

 On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote:

 On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves 
 wrote:

 I actually think that there are two large categories of
 programmers: those like writing the same loops over and over
 again and those who use algorithms.


 I agree, at some point I learned that there is a huge 
 cultural distinction between C and C++ programmers.


 yes, the other main distinction are the people who correctly 
 put the * next to the type because it's part of the type, or 
 the wrong people who put it next to the variable name because 
 they're heathens


 What is the type of b here ?

 int* a, b;


 int* because I don't use a language that's ruined by C baggage.


You answer a comment about, quoting "C and C++ programmers". If 
you don't understand what you are answering to, you probably 
shouldn't.
Mar 21 2015
parent "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 22 March 2015 at 04:53:06 UTC, deadalnix wrote:

 On Sunday, 22 March 2015 at 02:36:03 UTC, weaselcat wrote:

 On Sunday, 22 March 2015 at 02:32:38 UTC, deadalnix wrote:

 On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote:

 On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote:

 On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves 
 wrote:

 I actually think that there are two large categories of
 programmers: those like writing the same loops over and 
 over
 again and those who use algorithms.


 I agree, at some point I learned that there is a huge 
 cultural distinction between C and C++ programmers.


 yes, the other main distinction are the people who correctly 
 put the * next to the type because it's part of the type, or 
 the wrong people who put it next to the variable name 
 because they're heathens


 What is the type of b here ?

 int* a, b;


 int* because I don't use a language that's ruined by C baggage.


 You answer a comment about, quoting "C and C++ programmers". If 
 you don't understand what you are answering to, you probably 
 shouldn't.


yes, and I answered it with respect to D programmers.
the correct answer for C++ is: if you submit that as a PR, I'm 
going to hit you.
Mar 21 2015
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, March 22, 2015 02:32:36 deadalnix via Digitalmars-d wrote:

 On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote:

 On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote:

 On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote:

 I actually think that there are two large categories of
 programmers: those like writing the same loops over and over
 again and those who use algorithms.


 I agree, at some point I learned that there is a huge cultural
 distinction between C and C++ programmers.


 yes, the other main distinction are the people who correctly
 put the * next to the type because it's part of the type, or
 the wrong people who put it next to the variable name because
 they're heathens


 What is the type of b here ?

 int* a, b;


Which is one reason never to declare multiple variables on the same line in
C/C++. I never understood why C/C++ made it so that the * went with the
variable rather than being treated like part of the type, since in reality,
the * is part of the type. I'm definitely glad that D fixed that and made it
so that the a and b in your example are both pointers.

But much as I hate it when folks put the * next to the variable name in
C/C++ instead of putting it with the rest of the type, your example shows
exactly why many people put it with the variable name.

- Jonathan M Davis
Mar 22 2015
prev sibling next sibling parent =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
"weaselcat" <weaselcat gmail.com> wrote:

 On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote:

 On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote:

 I actually think that there are two large categories of
 programmers: those like writing the same loops over and over
 again and those who use algorithms.


 
 I agree, at some point I learned that there is a huge cultural >
 distinction between C and C++ programmers.


 
 yes, the other main distinction are the people who correctly put the *
 next to the type because it's part of the type, or the wrong people who
 put it next to the variable name because they're heathens


One could argue that in the declaration:
int *a;
the type of *a is int.
So it's not a pointer type but a dereference operator.

That actually similar to how patterns work in modern programming languages.

Tobi
Mar 22 2015
prev sibling parent "Moritz Maxeiner" <moritz ucworks.org> writes:
On Sunday, 22 March 2015 at 01:44:32 UTC, weaselcat wrote:

 On Sunday, 22 March 2015 at 01:24:10 UTC, Martin Nowak wrote:

 On Saturday, 21 March 2015 at 23:49:26 UTC, Atila Neves wrote:

 I actually think that there are two large categories of
 programmers: those like writing the same loops over and over
 again and those who use algorithms.


 I agree, at some point I learned that there is a huge cultural 
 distinction between C and C++ programmers.


 yes, the other main distinction are the people who correctly 
 put the * next to the type because it's part of the type, or 
 the wrong people who put it next to the variable name because 
 they're heathens


+1
Mar 28 2015
prev sibling next sibling parent reply "Mengu" <mengukagan gmail.com> writes:
On Saturday, 21 March 2015 at 22:16:10 UTC, Martin Nowak wrote:

 This blog post describes what to consider when switching from 
 python to go.

 http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/#tips

 It's very interesting, because the long list of things to give 
 up for
 more efficient go code reads like an argumentation against 
 choosing go
 from a D perspective.
 And given that D is on par with Python's expressiveness, we 
 should
 really emphasize this aspect.

 I recently made a pull request for a go tool and spent about 
 half an
 hour trying to find some function to test whether an array 
 contains a
 particular element. I also asked on #go-nuts to confirm I 
 didn't miss
 anything, but you're really supposed to write an explicit loop.

 https://github.com/buger/gor/pull/149/files#diff-b8b346beabeabdf0fca6f0b6893ce82bR42

 That's what you would write in other languages.

 ```py
 if "chunked" in request.transfer_encodings:
     return
 ```

 ```ruby
 return if request.transfer_encodings.include? 'chunked'
 ```

 ```d
 if (request.transferEncodings.canFind("chunked"))
     return;
 ```

 ```c++
 const auto& arr = request.transfer_encodings;
 if (find(arr.begin(), arr.end(), string("chunked")) != 
 arr.end())
     return;
 ```

 There exists some functionality for sorted arrays (only int, 
 float, and
 string), but that isn't applicable here.
 http://golang.org/pkg/sort/

 While go will hardly ever have good support for algorithms, 
 because of
 the lack of overloads and generics, they also choose against 
 adding such
 trivial, but often needed, algorithms to the basic types.
 With a functional programming (or C++ algo) background, I find 
 this very
 hard to get used to.
 Repeatedly writing out such trivial code often mixes different 
 levels of
 abstraction and is one of the reasons why go code is so noisy, 
 manual
 error code handling being another one.


trust me, from an undecided but experienced developer's
perspective there are so many reasons to choose D over Go. on the
otherhand same person has a lot more reasons to choose Go over D.

i'm writing a very long blog post about this. if anyone's
interested, i can happily share the draft with them.
Mar 22 2015
next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Sunday, 22 March 2015 at 20:35:31 UTC, Mengu wrote:

 trust me, from an undecided but experienced developer's
 perspective there are so many reasons to choose D over Go. on 
 the
 otherhand same person has a lot more reasons to choose Go over 
 D.

 i'm writing a very long blog post about this. if anyone's
 interested, i can happily share the draft with them.


Pretty interested in that, please shot me a mail.
Mar 24 2015
prev sibling parent reply "Bienlein" <jeti789 web.de> writes:
I recently made a pull request for a go tool and spent about 
half an
hour trying to find some function to test whether an array 
contains a
particular element.


There are libraries for this like gen: 
http://clipperhouse.github.io/gen. But it also suffers from the 
absence of generics.


trust me, from an undecided but experienced developer's
perspective there are so many reasons to choose D over Go. on the
otherhand same person has a lot more reasons to choose Go over D.


I earn my pay with Java development. In my spare time I learn 
some Scala hoping there might be some work for me with Scala in 
the future. Then I need to become familiar with all kinds of new 
frameworks, tools, libraries and systems that continue to pop up 
every year in the JVM eco system.

In the end there is not much time left for playing with a 
"systems language". As Go is very effortless it could be a good 
compromise here. I have thrown it away and refetched it due to 
lack of alternatives several times. I would like to play with D, 
but it has as step a learning curve as Scala. If you don't have a 
background in C or C++ the learning curve is even steeper. So it 
depends a lot from where you are coming.


i'm writing a very long blog post about this. if anyone's
interested, i can happily share the draft with them.


Please drop a comment in this thread or somewhere when it is 
published.

Cheers, Bienlein
Mar 25 2015
next sibling parent reply "Idan Arye" <GenericNPC gmail.com> writes:
On Wednesday, 25 March 2015 at 10:17:01 UTC, Bienlein wrote:

I recently made a pull request for a go tool and spent about 
half an
hour trying to find some function to test whether an array 
contains a
particular element.


 There are libraries for this like gen: 
 http://clipperhouse.github.io/gen. But it also suffers from the 
 absence of generics.


trust me, from an undecided but experienced developer's
perspective there are so many reasons to choose D over Go. on 
the
otherhand same person has a lot more reasons to choose Go over 
D.


 I earn my pay with Java development. In my spare time I learn 
 some Scala hoping there might be some work for me with Scala in 
 the future. Then I need to become familiar with all kinds of 
 new frameworks, tools, libraries and systems that continue to 
 pop up every year in the JVM eco system.

 In the end there is not much time left for playing with a 
 "systems language". As Go is very effortless it could be a good 
 compromise here. I have thrown it away and refetched it due to 
 lack of alternatives several times. I would like to play with 
 D, but it has as step a learning curve as Scala. If you don't 
 have a background in C or C++ the learning curve is even 
 steeper. So it depends a lot from where you are coming.



My case is the opposite - Go's easy learning curve is the exact 
thing that drove me away from it. While Go's simplicity makes it 
easy to learn - it also makes it uninteresting to learn. I like 
to learn new languages that introduce interesting concepts, 
because interesting concepts are interesting, and because they 
can change the way you program even in languages that don't 
support them directly. I'm currently trying to learn Rust, and 
while it's far from trivial to wrap your mind around it's concept 
of ownership, I feel that once I do it I can emerge a better 
programmer - so learning Rust will benefit me even if I never use 
Rust in actual projects.

Go, on the other hand, doesn't introduce any interesting 
concepts(more-elegant-C is far from being interesting). I don't 
care for just learning another set of syntax and another standard 
library - that knowledge won't have any effect on the way I'm 
thinking. As long as I don't have a specific project I need to 
use Go for - learning it is just a waste of time.
Mar 25 2015
parent "Chris" <wendlec tcd.ie> writes:
On Wednesday, 25 March 2015 at 15:36:16 UTC, Idan Arye wrote:

 On Wednesday, 25 March 2015 at 10:17:01 UTC, Bienlein wrote:

I recently made a pull request for a go tool and spent about 
half an
hour trying to find some function to test whether an array 
contains a
particular element.


 There are libraries for this like gen: 
 http://clipperhouse.github.io/gen. But it also suffers from 
 the absence of generics.


trust me, from an undecided but experienced developer's
perspective there are so many reasons to choose D over Go. on 
the
otherhand same person has a lot more reasons to choose Go over 
D.


 I earn my pay with Java development. In my spare time I learn 
 some Scala hoping there might be some work for me with Scala 
 in the future. Then I need to become familiar with all kinds 
 of new frameworks, tools, libraries and systems that continue 
 to pop up every year in the JVM eco system.

 In the end there is not much time left for playing with a 
 "systems language". As Go is very effortless it could be a 
 good compromise here. I have thrown it away and refetched it 
 due to lack of alternatives several times. I would like to 
 play with D, but it has as step a learning curve as Scala. If 
 you don't have a background in C or C++ the learning curve is 
 even steeper. So it depends a lot from where you are coming.



 My case is the opposite - Go's easy learning curve is the exact 
 thing that drove me away from it. While Go's simplicity makes 
 it easy to learn - it also makes it uninteresting to learn. I 
 like to learn new languages that introduce interesting 
 concepts, because interesting concepts are interesting, and 
 because they can change the way you program even in languages 
 that don't support them directly. I'm currently trying to learn 
 Rust, and while it's far from trivial to wrap your mind around 
 it's concept of ownership, I feel that once I do it I can 
 emerge a better programmer - so learning Rust will benefit me 
 even if I never use Rust in actual projects.

 Go, on the other hand, doesn't introduce any interesting 
 concepts(more-elegant-C is far from being interesting). I don't 
 care for just learning another set of syntax and another 
 standard library - that knowledge won't have any effect on the 
 way I'm thinking. As long as I don't have a specific project I 
 need to use Go for - learning it is just a waste of time.


True. D has changed my way of thinking in other languages too. I 
sometimes find myself implementing (at least trying to) D 
concepts in other languages.

Go doesn't seem worth the trouble. Also, if it's so primitive and 
easy to learn, you don't need to bother learning it, you can just 
dip in when you need it for some reason.
Mar 27 2015
prev sibling next sibling parent reply "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
 I earn my pay with Java development. In my spare time I learn 
 some Scala hoping there might be some work for me with Scala in 
 the future. Then I need to become familiar with all kinds of 
 new frameworks, tools, libraries and systems that continue to 
 pop up every year in the JVM eco system.

 In the end there is not much time left for playing with a 
 "systems language". As Go is very effortless it could be a good 
 compromise here. I have thrown it away and refetched it due to 
 lack of alternatives several times. I would like to play with 
 D, but it has as step a learning curve as Scala. If you don't 
 have a background in C or C++ the learning curve is even 
 steeper. So it depends a lot from where you are coming.


I have never used Scala, never written in C++, and haven't done 
much C programming in about twenty years (and only occasional VBA 
for Excel programming in between).  I don't learn as quickly 
today as when a child.  But I was able to learn enough D to be 
productive in my domain in a few months, and found it easier to 
learn than Python.  So I haven't personally found the learning 
curve to be steep in the sense of learning enough to be 
reasonably productive.  The metaprogramming perhaps, but you can 
do a lot without being a ninja there if your orientation is just 
being able to solve the problems you have in a small to medium 
project.


Laeeth
Mar 25 2015
parent "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
On Wednesday, 25 March 2015 at 17:21:43 UTC, Laeeth Isharc wrote:

 I earn my pay with Java development. In my spare time I learn 
 some Scala hoping there might be some work for me with Scala 
 in the future. Then I need to become familiar with all kinds 
 of new frameworks, tools, libraries and systems that continue 
 to pop up every year in the JVM eco system.

 In the end there is not much time left for playing with a 
 "systems language". As Go is very effortless it could be a 
 good compromise here. I have thrown it away and refetched it 
 due to lack of alternatives several times. I would like to 
 play with D, but it has as step a learning curve as Scala. If 
 you don't have a background in C or C++ the learning curve is 
 even steeper. So it depends a lot from where you are coming.


 I have never used Scala, never written in C++, and haven't done 
 much C programming in about twenty years (and only occasional 
 VBA for Excel programming in between).  I don't learn as 
 quickly today as when a child.  But I was able to learn enough 
 D to be productive in my domain in a few months, and found it 
 easier to learn than Python.  So I haven't personally found the 
 learning curve to be steep in the sense of learning enough to 
 be reasonably productive.  The metaprogramming perhaps, but you 
 can do a lot without being a ninja there if your orientation is 
 just being able to solve the problems you have in a small to 
 medium project.


 Laeeth


There is something about languages that is very personal, though. 
  D just seemed right aesthetically.  One is going to find it 
easier to become an expert on a composer - say Beethoven, if he 
speaks to something in your soul, than if you simply can't stand 
his music.  (And there are many gradations in between).  It is an 
unfashionable perspective, but I think this is true of 
programmimg languages too.  People have different aesthetic and 
emotional organisations, and the appeal of different languages 
will not be the same to every person, holding ability constant.
Mar 25 2015
prev sibling parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2015-03-25 10:17:00 +0000, Bienlein said:


 
 I recently made a pull request for a go tool and spent about half an
 hour trying to find some function to test whether an array contains a
 particular element.


 
 There are libraries for this like gen: 
 http://clipperhouse.github.io/gen. But it also suffers from the absence 
 of generics.
 

 trust me, from an undecided but experienced developer's
 perspective there are so many reasons to choose D over Go. on the
 otherhand same person has a lot more reasons to choose Go over D.


 
 I earn my pay with Java development. In my spare time I learn some 
 Scala hoping there might be some work for me with Scala in the future. 
 Then I need to become familiar with all kinds of new frameworks, tools, 
 libraries and systems that continue to pop up every year in the JVM eco 
 system.
 
 In the end there is not much time left for playing with a "systems 
 language". As Go is very effortless it could be a good compromise here. 
 I have thrown it away and refetched it due to lack of alternatives 
 several times. I would like to play with D, but it has as step a 
 learning curve as Scala. If you don't have a background in C or C++ the 
 learning curve is even steeper. So it depends a lot from where you are 
 coming.
 

 i'm writing a very long blog post about this. if anyone's
 interested, i can happily share the draft with them.


 
 Please drop a comment in this thread or somewhere when it is published.
 
 Cheers, Bienlein


D is a superset of go's functionality aside from the structural typing 
(which in my opinion is a huge fail for a variety of reasons you will 
see if you try to use it for anything extensive).  If you don't want to 
learn about templates and metaprogramming, then don't.  I fail to 
understand why having extra features is a deterrant?

-Shammah
Mar 27 2015
parent "cym13" <cpicard openmailbox.org> writes:
On Friday, 27 March 2015 at 14:21:18 UTC, Shammah Chancellor 
wrote:

 D is a superset of go's functionality aside from the structural 
 typing (which in my opinion is a huge fail for a variety of 
 reasons you will see if you try to use it for anything 
 extensive).  If you don't want to learn about templates and 
 metaprogramming, then don't.  I fail to understand why having 
 extra features is a deterrant?

 -Shammah


That's what I thought for a long time, and I still think that it 
is a valid approach, but it should be noted that more features 
makes reading and understanding other's code more difficult.

1/ if you don't know templates, then reading a code making use of 
it needs a long time to identify the construct, read about it, 
understand it and then apply this new knowledge to the original 
piece of code. The identification part is important, how often 
when learning a language did you found a weird syntax that you 
just could'nt identify because it was generic enough not to get 
any useful results in a web search?

2/ more paradigms allow people to write different solutions for a 
same problem. Of course, that's the whole point of accepting 
different paradigms, but it makes it difficult to have a 
uniformed programming style. If you take a language that emphasis 
having one good, elegant, performant way to do things (like 
python) then the code I write will be very similar to the code 
you would have written. Of course there are divergences but there 
is one style that is said to be good and sticking to it means 
that nobody will have problem understanding what I'm writting.

A language that famously took the other path and decided that it 
should allow programmers to solve the same problem in as many 
ways as possible is perl. And if perl is often praised for its 
expressiveness, it is disturbing to see that even perlers are 
often having a hard time deciphering other's code.
Mar 29 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Saturday, 21 March 2015 at 22:16:10 UTC, Martin Nowak wrote:

 This blog post describes what to consider when switching from 
 python to go.

 http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/#tips

 It's very interesting, because the long list of things to give 
 up for
 more efficient go code reads like an argumentation against 
 choosing go
 from a D perspective.
 And given that D is on par with Python's expressiveness, we 
 should
 really emphasize this aspect.

 I recently made a pull request for a go tool and spent about 
 half an
 hour trying to find some function to test whether an array 
 contains a
 particular element. I also asked on #go-nuts to confirm I 
 didn't miss
 anything, but you're really supposed to write an explicit loop.

 https://github.com/buger/gor/pull/149/files#diff-b8b346beabeabdf0fca6f0b6893ce82bR42

 That's what you would write in other languages.

 ```py
 if "chunked" in request.transfer_encodings:
     return
 ```

 ```ruby
 return if request.transfer_encodings.include? 'chunked'
 ```

 ```d
 if (request.transferEncodings.canFind("chunked"))
     return;
 ```

 ```c++
 const auto& arr = request.transfer_encodings;
 if (find(arr.begin(), arr.end(), string("chunked")) != 
 arr.end())
     return;
 ```

 There exists some functionality for sorted arrays (only int, 
 float, and
 string), but that isn't applicable here.
 http://golang.org/pkg/sort/

 While go will hardly ever have good support for algorithms, 
 because of
 the lack of overloads and generics, they also choose against 
 adding such
 trivial, but often needed, algorithms to the basic types.
 With a functional programming (or C++ algo) background, I find 
 this very
 hard to get used to.
 Repeatedly writing out such trivial code often mixes different 
 levels of
 abstraction and is one of the reasons why go code is so noisy, 
 manual
 error code handling being another one.


So it's basically like JavaScript? You have to re-invent the
wheel over and over again.

  From the blog post:

"Also, and this counts for something I think, Go is a trendy
language right now, so when it comes to recruiting, I think
having Go as a critical part of Repustate’s tech stack will help."

Stop the world, I wanna get out!
Mar 27 2015
parent reply "Martin Nowak" <code dawg.eu> writes:
On Friday, 27 March 2015 at 19:00:16 UTC, Chris wrote:

 "Also, and this counts for something I think, Go is a trendy
 language right now, so when it comes to recruiting, I think
 having Go as a critical part of Repustate’s tech stack will 
 help."

 Stop the world, I wanna get out!


I was recently told by a commercial D user, that using D helps 
them to more easily identify good programmers.
Mar 27 2015
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 27 March 2015 at 19:27:38 UTC, Martin Nowak wrote:

 On Friday, 27 March 2015 at 19:00:16 UTC, Chris wrote:

 "Also, and this counts for something I think, Go is a trendy
 language right now, so when it comes to recruiting, I think
 having Go as a critical part of Repustate’s tech stack will 
 help."

 Stop the world, I wanna get out!


 I was recently told by a commercial D user, that using D helps 
 them to more easily identify good programmers.


It would be nice, if not just D users had this attitude :-)
Mar 27 2015
parent "Bienlein" <jeti789 web.de> writes:
 I was recently told by a commercial D user, that using D helps 
 them to more easily identify good programmers.


 It would be nice, if not just D users had this attitude :-)


It's also a bit like that for Scala when companies look for Java 
people. Alas, Scala is a bit overloaded ...
Mar 29 2015
prev sibling parent Shammah Chancellor <anonymous coward.com> writes:
On 2015-03-27 19:27:37 +0000, Martin Nowak said:


 On Friday, 27 March 2015 at 19:00:16 UTC, Chris wrote:

 "Also, and this counts for something I think, Go is a trendy
 language right now, so when it comes to recruiting, I think
 having Go as a critical part of Repustate’s tech stack will help."
 
 Stop the world, I wanna get out!


 
 I was recently told by a commercial D user, that using D helps them to 
 more easily identify good programmers.


Every programmer I know who was worth their salt was at least interested in D.

-S.
Mar 28 2015