Live data from Hacker News

Go Rocks - How Can We Avoid Something This Bad In The Future?

acooke.org

11–20 of 68 posts

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#11

I still think the major stumbling block for Go is the syntax. I can't put my finger on it, but from the first time I saw it I thought it looked wrong. Can anyone who shares my opinion chime in on what things they think cause the syntax to suffer aesthetically?

It's the mix of old-school brace syntax, with the omitted parens which makes it look off to me.

I can't think of anyway to get around once you add Static Typing.

Dynamic languages have much more bare function/object definitions.

Haskell does make Types look sexy on the other hand. So yes there could have been some borrowing from there.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#12
Go's performance isn't good enough to broadly compete with C++ yet, and for everything higher level I don't see a strong enough advantage over Java or Scala to start all over with a new library ecosystem.

That said, I'm keeping an eye on it. If it takes off I'll learn it but it doesn't make sense to make it a priority yet, IMO.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#13

I still think the major stumbling block for Go is the syntax. I can't put my finger on it, but from the first time I saw it I thought it looked wrong. Can anyone who shares my opinion chime in on what things they think cause the syntax to suffer aesthetically?

It's the mix of old-school brace syntax, with the omitted parens which makes it look off to me.

I personally kinda like that decision. You don't need both parens and braces to remove ambiguity. Since braces are useful for denoting code blocks, parens are basically noise.

I'm not a language expert, so if anyone can correct me on the theory I would appreciate it.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#15
I know that this is the wrong mentality, but I want to become an expert in a language that is as good as it can be. Can Go evolve to address some of these issues? Would it even be go anymore?

I tried Googling, but why are Scala and Haskell automatically classified as "academic"? Is there value in learning them purely for that reason? I walked through some Haskell tutorials after reading this, but I'm rather stare at the sun than read Scala.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#16

I know that this is the wrong mentality, but I want to become an expert in a language that is as good as it can be. Can Go evolve to address some of these issues? Would it even be go anymore? I tried Googling, but why are Scala and Haskell automatically classified as "academic"? Is there value in learning them purely for that reason? I walked through some Haskell tutorials after reading this, but I'm rather stare at…

I tried Googling, but why are Scala and Haskell automatically classified as "academic"?

It's what people say when asked about languages they don't use or understand.

I.e., damning with faint praise.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#17

I still think the major stumbling block for Go is the syntax. I can't put my finger on it, but from the first time I saw it I thought it looked wrong. Can anyone who shares my opinion chime in on what things they think cause the syntax to suffer aesthetically?

I think it's kind of like as a portuguese speaker I can never learn to speak spanish properly. It's easy enough to understand, but I can never remember the different words because it's too similar to compartmentalize.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#19
post #7
post #4

I wrote a bunch of go code this morning. It's definitely got a few really neat ideas in it. I tend to write erlang or c++ mostly for my day job. I do really wish the designers had a bit more erlang experience. Just a touch. Just enough so that I had a way to propagate the death of a goroutine through a bunch of other goroutines without building all of that manually. For example, code I wrote today: http://pastebin.co…

If you modify your for loop to range over ch, you can make the sending side close(ch) when an error occurs, and then the loop will end and the receiver can shut itself down. http://pastebin.com/FMSLvFCn

Wow, that's not intuitive. :)

Throwing in a "defer close(ch)" and that range thing did exactly the right thing. I'm not sure my API is right, but I know how to get it right now. Thanks a lot.

Re: Go Rocks - How Can We Avoid Something This Bad In The Future?

#20
No syntactically lightweight way of writing anonymous recursive functions? I can't make myself care about that; I just spent 30 seconds trying, and failed. That's just not a use case worth optimizing for in a practical systems language.

Also, it's true that the Go spec doesn't guarantee tail calls are optimized. If Go were designed to be a functional language, that'd be problematic. However, guaranteeing TCO isn't free in implementation, and in the presence of features like "defer", it becomes non-trivial to understand when it is happening. So, while I like TCO as much as the next guy, I agree with the Go designers decision not to require it. Just like with a pile of other languages, the lack hasn't stopped people from writing good code, and not even stopped them from writing useful recursive code. I think there's some code in the Go standard library (parsing code, mostly) that uses trampolining to simulate it, and that code would be better off if it could just do a tail call, but on the balance that code still works well and isn't convoluted.

Anyway, not a bad blog post; I agree with most of it. But, as someone who has written a fair bit of code in functional languages and a fair bit of Go, I find that the more Go I write the less I care about the language features (or lack thereof) that I was horrified by at first, and the more I see most other languages as overcomplicated. Go isn't a very good language in theory, but it's a great language in practice, and practice is all I care about, so I like it quite a bit.

Post reply on HN