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

Go is boring

aerokode.com

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Go is boring

#21

Post by nly »

> Nouns are things, nouns do verbs.

Of course, not all nouns "do verbs", which is why we end up with warped associations between particular language utilities, like classes, with notions from one philosophy taken to weird limits.

Circles and Ellipses, for example, don't do anything. They're data structures. They're nouns, but they have no functionality. They have no verbs. The correct solution to the Circle-Ellipse problem, the most famous demonstration of one flaw with OOP, can be expressed elegantly and correctly, in C++ and other "C++ style languages", using classes. Doing so doesn't make anything object oriented, and we shouldn't associate giving things names with a requirement for any particular set of associated verbs.

All language features are tools, and while I'm not saying Go is an inferior tool if you're satisfied, we shouldn't make blunt instruments, or carry fewer tools, just because some people don't know what they're doing. I'm currently not satisfied with the set of features Go provides... but then I also want to see some Go features in C++. Let's not get hung up on it.

Re: Go is boring

#22

Post by dvisher »

arnehormann wrote: post #16
arnehormann wrote: post #10

Earlier quoted context omitted.

It doesn't need to. You could also write type Runes []rune but the struct variant has the advantage that you can get the array back without any conversions - it's pretty cheap. And you can embed it. That's an advantage if you e.g. don't define Less on Runes but define it on RunesAsc and RunesDesc. See http://golang.org/pkg/sort/ -> Examples (SortWrapper)

The costs: allocating the memory, having it set to zero values and keeping the garbage collector a little busier. All of that more than once if you don't keep the conversions down. Profile and disassemble your program, Go comes with pretty great tools!

The Go runtime sets all memory to zero at the start of the program's execution, meaning there is no overhead for 'setting the zero values'. The amount of extra memory allocated is minimal (probably zero). Records/structs tend to be figured out at compile time so no 'extra' information needs to be stored in it. And since we are storing a pointer (a slice) the struct is already aligned so no extra storage is needed there. What it might cost is one extra level of indirection per array access, but due to the simplicity of the program, I would not be surprised if this was removed at compile time or cached (in hardware). Looking at the disassembly itself, they seem to optimize out that extra layer of indirection as well (for the most part in Swap, Len, and Less).

The real cost of this is definitely the verbosity for something that could be much simpler.

Re: Go is boring

#23

Post by coldtea »

wyager wrote: post #20

Go is poorly designed. It has a mediocre type system, bad support for genericism, too much reliance on non-extensible language keywords (range, make, etc.). Want to range over a tree? Too bad. Or maybe wrap the tree with a chan and watch performance and simplicity go out the window. I mean, come on, what modern language actually recommends casting to the top type? That would be like if idiomatic C++ involved casting…

I like Go for some stuff, but yes, it's pretty restricted. Even for the design goals that are lauded (simplicity, being boring as a virtue, fast compilation speed, no magic, concurrency built-in etc), they could have achieved them with a little more flair.

One could say that if we compare the team that worked on C and Plan 9 to the Rolling Stones, Go is like their nineties albums.

Re: Go is boring

#24

Post by cnbuff410 »

wyager wrote: post #20

Go is poorly designed. It has a mediocre type system, bad support for genericism, too much reliance on non-extensible language keywords (range, make, etc.). Want to range over a tree? Too bad. Or maybe wrap the tree with a chan and watch performance and simplicity go out the window. I mean, come on, what modern language actually recommends casting to the top type? That would be like if idiomatic C++ involved casting…

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.

Re: Go is boring

#25

Post by st2p »

cnbuff410 wrote: post #24
wyager wrote: post #20

Go is poorly designed. It has a mediocre type system, bad support for genericism, too much reliance on non-extensible language keywords (range, make, etc.). Want to range over a tree? Too bad. Or maybe wrap the tree with a chan and watch performance and simplicity go out the window. I mean, come on, what modern language actually recommends casting to the top type? That would be like if idiomatic C++ involved casting…

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.

In 2 or 3 years when you move a few notches up on the developer continuum look back on this comment and reflect.

Re: Go is boring

#26

Post by pstuart »

st2p wrote: post #25
cnbuff410 wrote: post #24

Earlier quoted context omitted.

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.

In 2 or 3 years when you move a few notches up on the developer continuum look back on this comment and reflect.

It's blub all the way up.

Re: Go is boring

#27

Post by prescindor »

arnehormann wrote: post #4
bigdubs wrote: post #2

Clickbait headline aside, I think Go threw some baby out with the bathwater in the march to simplicity. An example; try to sort a slice of runes.

The setup needs a little boilerplate, but it's definitely possible. And it can support different sort orders after writing the boilerplate once. For those wanting to test drive it: http://play.golang.org/p/I_Vu34hUoV

You don't even need a stuct ...

http://play.golang.org/p/GHzsNdtiNf

Re: Go is boring

#28

Post by babawere »

wyager wrote: post #20

Go is poorly designed. It has a mediocre type system, bad support for genericism, too much reliance on non-extensible language keywords (range, make, etc.). Want to range over a tree? Too bad. Or maybe wrap the tree with a chan and watch performance and simplicity go out the window. I mean, come on, what modern language actually recommends casting to the top type? That would be like if idiomatic C++ involved casting…

I think you are evaluating 'go' based on feature set rather than the amount of friction a developer experience when using it to develop a good product.

C++ is fantastic but I personally experience far less friction when working with 'go' for most of my task.

Post reply on HN