Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The March Towards Go

zef.me

Post reply on HN
Print view View original

71–80 of 217 posts

Re: The March Towards Go

#71

Post by adamors »

Udo wrote: post #61

This sums up the problem: > Not looking at Go yet? It may be a good time to do so now — everybody else is. That's going to be a large albatross around Go's neck, as it has been around node.js', and Rails before that. Large amounts of developers flocking to a new thing because "this is the thing to use now and if you don't you're dead meat". Personally, I thought Node.js was a terrible platform for serving dynamic web…

> "this is the thing to use now and if you don't you're dead meat".

And not just because you'd be unfashionable, but because a lot of crucial libraries in these ecosystems will loose maintainers. The Node guy said the other day that (out of his hundreds of libraries) "Koa is the one project I’ll continue to maintain".

If I had any of his packages in production I would be terrified. The fact that he (and other "Node guys") are driving the hype train to Go tells me that I should stay as far from it as possible.

Re: The March Towards Go

#72

Post by davidw »

ovi256 wrote: post #6
jbb555 wrote: post #3

I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. I guess compared to javascript I can see the advantages though

Go could be improved in many ways. It lacks facilities that what we consider modern programming languages have, e.g. object-oriented programming, generics. The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}. These are the cons. The pros are of such value that they more than compensate for the cons: first class facilities for building conc…

> My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features. AFAIK, the existing GIL in the reference Python and Ruby interpreters makes adding true goroutines impossible.

Have you had a look at Erlang and Elixir? The former is not as dynamic as Ruby (not much is), but it's a nice environment, and another step up from Go in terms of all the facilities for fault tolerant and distributed programming.

Re: The March Towards Go

#73

Post by chx »

jbb555 wrote: post #3

I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. I guess compared to javascript I can see the advantages though

Strict typing after JS is like a breath of fresh air. Multiple returns are helpful. Parallelism is real, first class, brilliant. The whole thing is intuitive. Most importantly: at every interesting design decision it's easy to pinpoint which language they got burned by the opposite. It's written by truly experienced people standing on very practical grounds.

Re: The March Towards Go

#74

Post by lucian1900 »

facepalm wrote: post #42
skrebbel wrote: post #33

Zef writes this as if it's completely amazing that people are leaving Node for Go. Node is based on JavaScript. There are arguably more things wrong with JavaScript than with any other popular programming language, as evidenced by book titles like "JavaScript, the good parts". This is common knowledge; we're all trying to do good work despite JavaScript, seldom because of it. So Node: it's fast, we can share code wit…

There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. Apart from that JavaScript is brilliant. Few other languages can match it's simplicity. Python falls through because it doesn't have real lambda.

Having to name a function in Python annoys me a lot less than basically more than half of JavaScript that is entirely batshit crazy.

Re: The March Towards Go

#75

Post by Udo »

adamors wrote: post #71
Udo wrote: post #61

This sums up the problem: > Not looking at Go yet? It may be a good time to do so now — everybody else is. That's going to be a large albatross around Go's neck, as it has been around node.js', and Rails before that. Large amounts of developers flocking to a new thing because "this is the thing to use now and if you don't you're dead meat". Personally, I thought Node.js was a terrible platform for serving dynamic web…

> "this is the thing to use now and if you don't you're dead meat". And not just because you'd be unfashionable, but because a lot of crucial libraries in these ecosystems will loose maintainers. The Node guy said the other day that (out of his hundreds of libraries) "Koa is the one project I’ll continue to maintain". If I had any of his packages in production I would be terrified. The fact that he (and other "Node g…

True, I think you're expected to follow the cool people to wherever they go next ;)

Maybe some ecosystems are much more about the people leading them than they are about the technology behind them. And while this is not something I'd be interested in as a developer, I understand how there could be huge benefits in that kind of lifestyle. I imagine that's a very supportive, creative, and active community to be in.

Looking at some (mis-)uses of Node, maybe that's been the rationale behind some of these frameworks all along. And indeed the first image on the page is of a marching band...

Re: The March Towards Go

#76

Post by _pmf_ »

facepalm wrote: post #42
skrebbel wrote: post #33

Zef writes this as if it's completely amazing that people are leaving Node for Go. Node is based on JavaScript. There are arguably more things wrong with JavaScript than with any other popular programming language, as evidenced by book titles like "JavaScript, the good parts". This is common knowledge; we're all trying to do good work despite JavaScript, seldom because of it. So Node: it's fast, we can share code wit…

There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. Apart from that JavaScript is brilliant. Few other languages can match it's simplicity. Python falls through because it doesn't have real lambda.

> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use.

Defaulting to doubles and not having native integral types is not a "minor detail".

Re: The March Towards Go

#77

Post by adamlett »

facepalm wrote: post #42
skrebbel wrote: post #33

Zef writes this as if it's completely amazing that people are leaving Node for Go. Node is based on JavaScript. There are arguably more things wrong with JavaScript than with any other popular programming language, as evidenced by book titles like "JavaScript, the good parts". This is common knowledge; we're all trying to do good work despite JavaScript, seldom because of it. So Node: it's fast, we can share code wit…

There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. Apart from that JavaScript is brilliant. Few other languages can match it's simplicity. Python falls through because it doesn't have real lambda.

> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use.

If you really believe that, I can only assume that you either don't have very much experience with Javascript and haven't yet been burned (or haven't yet discovered that you've already been burned), or that you don't have any experience outside of Javascript and therefore are not aware that languages exist that have all the niceness of Javascript but almost none of the bad stuff. I say this as someone who is primarily a Javascript developer professionally.

Yes, there are languages that are worse than Javascript to work in (I'm looking at you Java and PHP), but there are many that are much better. It's worth noting that everything that is good about Javascript already existed in other languages before Javascript got invented. In fact Brendan Eich has stated that his intention was to create Scheme for the browser. If only he had just used Scheme as it existed, things would have been so much better!

Re: The March Towards Go

#78

Post by CmonDev »

otikik wrote: post #60
cgag wrote: post #19

Earlier quoted context omitted.

No generics (parametric polymorphism), no algebraic data types. You should learn some Haskell or Ocaml even if you don't plan on using it in production. Go's type system is weak. Edit: I don't think there's anything like type classes either but I'm not 100%.

> Go's type system is weak. It is strong enough for me. I see the lack of algebraic data types and type classes as a feature, honestly. It means I can learn the things I need and start working in 2 days instead of in 2 weeks or a month. I sometimes need generics, but not frequently enough to miss them. You think Go's type system is weak. I think Haskell's type system is overcomplicated. So, there.

It's a choice really: using a built-in exhaustive type system, or creating one manually with unit-tests. Unless you are happy with certain types of bugs.

Re: The March Towards Go

#79

Post by bcarrell »

ovi256 wrote: post #6
jbb555 wrote: post #3

I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. I guess compared to javascript I can see the advantages though

Go could be improved in many ways. It lacks facilities that what we consider modern programming languages have, e.g. object-oriented programming, generics. The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}. These are the cons. The pros are of such value that they more than compensate for the cons: first class facilities for building conc…

> My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features.

Clojure is dynamic and has goroutine and channel constructs through core.async.

Re: The March Towards Go

#80

Post by CmonDev »

nemasu wrote: post #2

When node first appeared, the thought of server side JS gave me shivers, maybe I should trust my instincts more often.

It's good when you are writing it but someone else will be maintaining it :).
Post reply on HN