cnbuff410

You don't even know what kind of project I'm talking about and you are saying "rather than the best tools available"? I don't get it. Do you really believe that problem field doesn't matter, and FP is "best tools available by default" for any field anyway?

Go to github and see the rank of project written in Go, you will see clearly what is the niche market(not that niche I would say) I'm talking about.

A lot of FP people tend to think people don't use FP are those who have "never heard of any modern functional languages". I don't know where does this kind of arrogance come from.

Sure, functional language can be used in almost all the programming related projects. But are they really a good fit or not is not decided by FP advocacy, but the people who actually tackle these problems.

Go for now shines in a pretty niche market, it is extremely good fit for this niche market, and this fact is not advocated by Go fans or Go team, but by large amount of open source projects and emerging usage in quite a few serious companies/startups.

You can certainly go ahead and ask them "Why not use OCaml, F#, Haskell or Scala", or you can use FP to make a better project in this field to show people FP is indeed much better fit.

To some of us, programming language is merely a tool to solve a problem, not to show off the shining design concept. For us, Go hits a incredibly sweet point on the balance of coding efficiency and running efficiency. Note that, coding efficiency has nothing to do with "how beautiful and elegant this code snippet is", it has everything to do with "if this project is easy to read, easy to maintain and easy to expand"

It's probably harder than just registering a new account and trolling here.

it's latest. Go 1.3 will have a minimum stack size back down at 4 kB. I think they have plan to even trim it down to 1-2 KB in Go 1.4

Why can't people love Go not because of Google, but the language itself?

Don't be deceived by your hate towards any specific company, otherwise you will miss a lot of beautiful, useful, adorable things in this world.

I use Pure in quite a few projects and I find it simple, fast to use. It's way more light-weight than Bootstrap yet still capable for all of my prototyping demands.

Just click on his profile and view his comment history. You won't find the examples lacking

For me, stdlib + some mux library is still the way to go until someday I see the shortcomings.

But this is a very classy and admirable way to answer all the critics. He didn't take them offensively at all. Instead he puts more thoughts on the design objectively and sincerely, and come up with what might be a better architecture in the end.

Hats off to codegangsta and good luck on Negroni.

So the more we use this app, the more contribution I can make back into OSM AUTOMATICALLY, is that correct?

Hopefully they will release Android version app soon.

As a Pythoner previously I have big interest in learning Julia and it indeed looks nice. But based on some small project I tried, it didn't show a significantly improved performance vs. Python. On the other hand, it doesn't have all the Python eco-system which is super nice for anybody who don't want to reinvent the wheel. Therefore, I don't have strong motivation to switch from Python to it for algorithm/learning related task.

Moreover, the benchmark you listed here are still mostly scientific computation related. Just from the benchmark, I'm not convinced enough that Julia beat Go from the perspective of a backend system, which is what I primarily use Go for.

Go and Julia really serves totally different purpose. Go want to replace Python in backend and the Python ecosystem matters little here. Julia want to replace Python in scientific computing and Python ecosystem matters a LOT here.

Lot's people don't care if language x is "poorly" designed or language y has "perfect" design. They evaluate language using two things:

1 Is it joyful to write without too much cognitive load? 2 Is it getting things done?

Go fits both for them.

Very clear. The reduction based scheduling certainly looks interesting. Thanks for your explanation!

> Erlang chose immutability for safety, while Go chose shared mutable state for practical reasons, but as a remedy Go recommends best practices to avoid the drawbacks caused by it.

That's my point. I didn't say it clearly before. I understand why shared state is bad in general. I don't understand if channel takes care of most scenarios why it's still one of biggest problem for Go listed by author.

> Erlang's reduction-based scheduling does not have this problem and can be very fair.

What's the key difference between Erlang's reduction based scheduling and cooperative scheduling?

Is it just me or the author fail to explain all the Go's detrimental design clearly? Most of the points he listed there are pretty much personal taste thing and basically what he was saying is "Go has so many problems because Go is not designed as Erlang".

For example, he said

"But when it comes to complex backends that need to be fault-tolerant Go is as broken as any other language with shared state."

Why? Why shared state is so bad in Go? Isn't it taken care by Go's channel anyway?

Also, why Pre-emptive Scheduling is bad? Isn't Error Handling still pretty much just a matter of personal preference?

Why Introspection makes Erlang so much better? What's the practical key problem for Go that can not be tackled without instrospection?

And I completely failed to understand the point of "Static Linking".

I'm not trolling. I don't have Erlang experience, and most of the problem the author pointed out was not bothering me, so I honestly want to see WHY they are problematic in Go

Cool project.

There are already a couple of Machine Learning libraries[1][2] written in Go and some of them are actually more mature than GoLearn.

Also just curious, I always thought Go is not really a good language for DM/ML stuff due to lack of good matrix library and generics. If someone here actually tried to write any ML library in Go, what's your genuine feeling about it?

[1] https://github.com/huichen/mlf [2] https://github.com/xlvector/hector

Complicate deployment is one of the major reason for me to stay away from using Self-hosted Git Server for my small team.

This one looks really interesting and promising. Being open source project is another major bonus.

here is the simplest way to handle it: Just make your whole source code folder(or even your home folder) which contains all your projects to be gopath, and forget about it.

Go can live peacefully with any other project.

Really? "What is it my Mac and iPad are failing to interoperate with"? Can you share your iCloud stuff with others not using Mac system?

Marco was blaming Google/Twitter/Facebook locking down devs/users in their own eco-system and your point is you get the interoperability within Apple's own garden? Come on.

BTW, you give a perfect example of what being hypocrite looks like. Sure, you can enjoy your time by hosting a closed service on top of open source infrastructure, that's hypocrite. You can also enjoy your time in a closed eco-system ever since from day 1 with absolutely no interoperate and still manage to find way to fuck those closed web based eco-system. That's also hypocrite.

Interoperate means what? Choice and competition. I see no spirit of either in Apple's eco-system. And somehow Marco always find a way to blame other companies for that.

Isn't it the same strategy Apple has been played all the time for its OS? And looks like Marco Arment has been enjoying it quite a lot? There is no freedom in terms of interoperability in your daily system and suddenly you are mad at "losing it"?

I think we should start to seriously challenge the overhype of "fail fast, failure is fine".

Ever since the adoption of "Lean startup" methodology, "failure" suddenly becomes a no big deal to entrepreneur. Making decision is like throwing a Hail Mary that you don't really care too much about the outcome. Yeah I failed. So what? Let's try it again. Let's try 100 more times and we may hit a home run.

If you can put a A-class work in front of people, why do you even want to settle on B/C/D-class stuff? The world doesn't, and shouldn't, work in this way. Failure is bad for your reputation, at anytime, anywhere, in front of anyone. There is a reason why nowadays, acq-hire is more and more popular, because it give others impression that, hey, I didn't fail, I sold my business because it's a good deal. Sure, 1 out of 10 cases is like this. But for the other 9? it just helps to cover your ass and avoid putting the tag "failure" on you in your future career.

Is failure end of world? Of course not. Does it mean you shouldn't set a high bar, think carefully, plan comprehensively, put as much effort as possible to maximize the outcome? Hell no. Remember, you can only control what you can control. So, whenever you do something you can control, you better do it right.

Sometimes you just don't get second chance.