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.

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

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.

>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

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.

> 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

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.

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.

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. ;)

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