Live data from Hacker News

Why Go Is Not Good

yager.io

71–80 of 367 posts

Re: Why Go Is Not Good

#71

Sheesh. A laundry list of issues. So why use Go at all? Quit yer whining and just use Haskell or whatever. Go works for some people, not for others. Why hang around and complain? Move on, use something else.

>So why use Go at all? Quit yer whining and just use Haskell or whatever. [...] Why hang around and complain?

Well, I think it's a good idea to get people thinking about programming language design. Sometimes it's really hard to tell what's wrong with something if you don't know about anything better.

Re: Why Go Is Not Good

#72
post #52

Possible error: >If you want to modify a data structure, you have to create an entirely new data structure with the correct changes. This is still pretty fast because Haskell uses lazy evaluation. I believe the issue is persistent data structures -- the new data structure "remembers" the old one (instead of recreating it) and records changes. (Clojure works like this as well) -- and not lazy evaluation.

I meant that, despite the fact that adding an element to a tree in Haskell naively constitutes "making a new tree", Haskell usually doesn't end up actually make a whole new tree (because of lazy evaluation), so trees are still really fast.

That's still not quite right. It's not lazy evaluation that makes it feasible to "make a new tree" in Haskell (although it doesn't hurt), it's the fact that the new tree shares most of the state of the old tree and the data structures make the asymptotic time complexity of both update and retrieval very close to (but not quite) O(n).

If you haven't looked at persistent data structures yet then I'd definitely recommend doing so because they are fascinating. A few people have written about Clojure's data structures and the following article looks like it gives a good introduction:

http://hypirion.com/musings/understanding-persistent-vector-...

Re: Why Go Is Not Good

#74
post #63
post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

> These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." They also tell me "now you don't have to wait for the language designers or compiler writers in order to 'implement another feature'." Not that _I_ would necessarily be this "brilliant" guy that implements these features. Most likely I will just find some third…

The problem is when you have to maintain your code with millions of lines, and hundreds of abstractions.. those "features" will hunt you in your nightmares at night

This is the "The Curse of C++" and some languages pointed in the article while beautiful and correct at first sight are going down in the same road..

Do we use a programming language to look smart, to create correct code or to efficiently solve problems in a maintanable and sane way?

Go is pragmatic.. theres nothing wrong with that.. but i agree that adding some features to it would not hurt either (like generics and enums) :)

Re: Why Go Is Not Good

#75
post #57

Earlier quoted context omitted.

People use the word "complex" in different ways. Do you mean number of features? Do you mean the size of the compiler? By some measures, operator overloading adds complexity; By another measure, it add simplicity.

I use complexity here the same way the Go community does: it is whatever its authors and users consider it to be. So chances are, if it slows down compilation, it's complexity. If it adds significantly to the grammar or syntax or keyword list, it's complexity. If it does things that can already be done, just differently, it's complexity. If it makes code less clear, it's probably complexity. (You get the idea.)

>If it does things that can already be done, just differently, it's complexity.

Doesn't that make programming languages themselves complexity? After all, you can already do anything in assembly.

That seems like a really weak argument. Sometimes having a more "complex" (in your terms) system leads to simplicity. For example, programming languages in general. Programming languages add "complexity" to computers over machine language programming, but the result is that making a program is a much simpler task.

Re: Why Go Is Not Good

#76
I've recently tryed out Go for its Unicode integration. What I liked at first sight...

* the indexing makes a map[something]boolean act like a set. Sets and maps are so similar it always felt wrong for them to be two separate constructs.

* making exported functions/vars/etc begin with a capital letter. When naming important stuff, it's a relief not worrying about naming conflicts with keywords. When naming locals, just use i,j,p,q,p2 anyway.

* using defer and recover instead of catch and finally. The catch clause is really two functionalities rolled into one and using defer and recover decomplects them.

Other languages should copy those.

What I'm concerned about...

* printf and regex notation are used so much they're really part of the language, but have an entirely separate syntax embedded within strings which must be learnt. But unlike the rest of Go's syntax, they're unintuitive, especially regexes for Unicode. Unicode is meant to be one of Go's strengths. I understand quick parsing is one of Go's primary reason's for existing, but the regex and printf notations could have been cleaner. When you think about it, why are the arithmetic and bitwise operators generally part of a language's primary syntax, but string matching and formatting delegated to sub-languages?

* statements, like if/else and ++/--, don't return values in Go which is hard to get used to. I understand making statements generally be shorter so the code looks good after running through gofmt could have motivated this.

Overall, I think Go's a systems language intended for quick parsing and eliminating C++'s complexity, and the author's comparing it to languages with far higher level constructs. The correct solution is for people to implement languages like Haskell and Clojure in Go, making them execute as fast as possible.

Re: Why Go Is Not Good

#77
post #72
post #52

Earlier quoted context omitted.

I meant that, despite the fact that adding an element to a tree in Haskell naively constitutes "making a new tree", Haskell usually doesn't end up actually make a whole new tree (because of lazy evaluation), so trees are still really fast.

That's still not quite right. It's not lazy evaluation that makes it feasible to "make a new tree" in Haskell (although it doesn't hurt), it's the fact that the new tree shares most of the state of the old tree and the data structures make the asymptotic time complexity of both update and retrieval very close to (but not quite) O(n). If you haven't looked at persistent data structures yet then I'd definitely recommen…

That's fair. I'll fix the article. Thanks!

Re: Why Go Is Not Good

#78
post #24
post #3

This was a good read. Can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development? From my initial dabblings with the language, it feels like its constraints may not actually be a big deal in practice, and may even be more of a help than a hindrance in large projects. It would be nice to get some commentary from more experienced go users.

I'm an experienced Go user. I'm also a lover of Haskell and Hindley Milner type systems. and in practice these complaints are not that big of a deal. Generics may or may not get added in the future but in practice you can go a long way with just slices and maps. And while the Hindley Milner type system is a wonder to behold and I love working in languages that have them sometimes those same languages introduce a non-…

If Go has a slogan that slogan is "Frictionless Development". It's easily the simplest, least annoying, and most "get out of your way" language I've ever used.

I suspect this is where many philosophical differences in these discussions originate. I appreciate the value of having quick and easy tools, but for production software where I care about quality, I don't want the language to get out of my way if I'm doing something silly, like treating data as if it's a different type to what it really is or assuming there is data to work with at all if a null value is a possibility. The web is plagued by security problems, so it seems odd to me that anyone would promote a new language for writing web-based software that retains obvious and entirely avoidable ways to introduce vulnerabilities.

Re: Why Go Is Not Good

#79
post #44
post #30

Earlier quoted context omitted.

>The writer seems to believe that functions on nil pointers crash the program, this is not the case. It's a common pattern in lazy construction to check if the receiving pointer is nil before continuing. And what happens when you don't check? It crashes. That's the unsafe part. These crashes are simply not possible in Rust and Haskell, and the type system notifies you if failure is possible (because the function will…

Maybe "unsafe" is being used to mean different things, here. Some may interpret it as to refer to unsafe memory access. Others may use it to mean possibility of crashing at run time (due to null pointer dereference).

Null pointer dereference is unsafe memory access.

Re: Why Go Is Not Good

#80
post #24

Earlier quoted context omitted.

I'm an experienced Go user. I'm also a lover of Haskell and Hindley Milner type systems. and in practice these complaints are not that big of a deal. Generics may or may not get added in the future but in practice you can go a long way with just slices and maps. And while the Hindley Milner type system is a wonder to behold and I love working in languages that have them sometimes those same languages introduce a non-…

If Go has a slogan that slogan is "Frictionless Development". It's easily the simplest, least annoying, and most "get out of your way" language I've ever used. I suspect this is where many philosophical differences in these discussions originate. I appreciate the value of having quick and easy tools, but for production software where I care about quality, I don't want the language to get out of my way if I'm doing so…

I doubt that null pointers lead to security vulnerabilities. Panics, yes; worse performance, yes; vulnerabilities, unlikely. Null pointers are not dangling or wild pointers, which are the problematic ones.
Post reply on HN