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!

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.

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.

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 :-)

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

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.

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.

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