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.

This is a funny workaround:

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

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.

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.

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

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;

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.

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.

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.

"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