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

Less is exponentially more (2012)

commandcenter.blogspot.com

Post reply on HN
Print view View original

11–20 of 102 posts

Re: Less is exponentially more (2012)

#11

Post by spyspy »

hyperman1 wrote: post #5

A few years ago I started to play with go. First impression was great. But a month or so in I started to having more and more doubts. As a Java/C++ programmer I was missing especially the generic collections. Slice and map are a good start, but not enough. Then one day I had to implement the swap operation for sorting. Again. And I thought that even C's qsort was better, and WTF am I wasting my time on this half-asse…

The sort library has been massively upgraded since you used it. There are a lot more helpers so you don’t need to reimplement the swap and less functions for each slice type.

Re: Less is exponentially more (2012)

#12

Post by dhsksndjsb »

ses1984 wrote: post #4

>Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive. Whoa, hold it there... inheritance and subclassing are OOP, types is a different subject, right?

OOP involves a type hierarchy, which is a prerequisite for giving meaning to the idea of inheritance. You can't talk about classes without actually talking about types, and inheritance creates a type hierarchy.

From golang documentation:

"Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes).

Also, the lack of a type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java."

Re: Less is exponentially more (2012)

#13

Post by jahaja »

hyperman1 wrote: post #5

A few years ago I started to play with go. First impression was great. But a month or so in I started to having more and more doubts. As a Java/C++ programmer I was missing especially the generic collections. Slice and map are a good start, but not enough. Then one day I had to implement the swap operation for sorting. Again. And I thought that even C's qsort was better, and WTF am I wasting my time on this half-asse…

> I'm not working with an ecosystem where my human time is less important than the language philosophy. I want to express a repetitive pattern in the language, and then never think about dumb bureaucratics again.

Writing code is not where time is spent. Repeating oneself, duplicating code, is fast and easy. Debugging someones code that felt like "expressing" themselves through it however, takes time, and a lot of it.

I really have no idea why some people so often need to use generics, and similar, beyond the built-in map and slice/array, when I seemingly do not, even though I write Go as my full-time job. Sure there a lot of difference between apps/domains, but the bulk of the code is usually not that different.

Re: Less is exponentially more (2012)

#15

Post by FpUser »

"People who are excited about C++11's new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more."

I find Go too limiting and definitely not offering "so much more". The author is probably right mentioning "big teams". Sure if I have whole shebang of programmers each nibbling at small particular task and appropriate budget it will work. But comparing the amount of work per developer per time I can have with more sophisticated "traditional" languages does not put Go in any good standing in my opinion.

Re: Less is exponentially more (2012)

#16

Post by LandR »

nobleach wrote: post #9

While this philosophy has a lot of value, it just isn't for me. I did a few apps in Go, and fought my way to a decent level of proficiency. I got to a point where I could solve some problems without constantly consulting the docs. But in the end, I wasn't enjoying the experience. The speed was great, the compilation was great. All the selling points were true. But it was missing so many things that I enjoyed using fr…

I feel the same, we are starting to use Go now and I really don't like it.

Things that in other languages I can do in half a dozen lines of code, I find I'm writing 4x time more in go.

And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using.

There's too many missing features I use heavily in other languages that make my life easier that I really miss them in go.

I will say I do like that its opinoinated on the formatting. Just takes away an entire tiresome argument.

Re: Less is exponentially more (2012)

#17

Post by tpaschalis »

nobleach wrote: post #9

While this philosophy has a lot of value, it just isn't for me. I did a few apps in Go, and fought my way to a decent level of proficiency. I got to a point where I could solve some problems without constantly consulting the docs. But in the end, I wasn't enjoying the experience. The speed was great, the compilation was great. All the selling points were true. But it was missing so many things that I enjoyed using fr…

Of course it's a matter of preference and being the right tool for the right job! Personally after using Go to build a simple ray-tracer and having to do numerical computations with it, I would really think twice before doing it again.

Want to reverse an array? You can't just list.reverse() or list[::-1] like you'd do in Python. Want a simple lookup if a value exists? You can't ['a', 'b', 'c'].include? 'a' like you'd do in Ruby. Want to reach for low-level primitives? You'd have to delve into CGO territory, which is not always "elegant". Want different concurrent paradigms (eg. an actor model), well, maybe you're better off without it.

But it's up to you whether that kind of 'simplicity' is desirable or not.

Re: Less is exponentially more (2012)

#18

Post by ggregoire »

pot8n wrote: post #10

Golang didn't succeed because it is simple or powerful or any of the, I apologize, nonsense your hear from the Gophers. Golang succeeded because it was the only available relevant option and alternative to the aging Python and Java when the cloud took off in the early 2010s.

Isn't Golang as simple as Python while being as powerful* as Java?

* I guess many people will disagree for the lack of generics (among other things), but the compiler and static types are powerful tools.

Re: Less is exponentially more (2012)

#19

Post by tpaschalis »

LandR wrote: post #16
nobleach wrote: post #9

While this philosophy has a lot of value, it just isn't for me. I did a few apps in Go, and fought my way to a decent level of proficiency. I got to a point where I could solve some problems without constantly consulting the docs. But in the end, I wasn't enjoying the experience. The speed was great, the compilation was great. All the selling points were true. But it was missing so many things that I enjoyed using fr…

I feel the same, we are starting to use Go now and I really don't like it. Things that in other languages I can do in half a dozen lines of code, I find I'm writing 4x time more in go. And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using. There's too many missing features I use heavily in other languages that make my life easier that I really miss them in go. I will say I do…

I think you're right regarding the verbosity, but I personally find this is outweighed by the fact that my code is 2x more likely to run correctly on the first try, and do what I expect it to.

Re: Less is exponentially more (2012)

#20

Post by api »

I love Go for this reason. It minimizes it's own cognitive load, freeing the mind to spend more time thinking about being clever solving the problem rather than being clever with the language.

I also adore goroutines and miss them in any other language. They are really fibers and let you do light concurrency without fiddling with async constructions. Async programming is just an ad hoc way of implementing fibers, and it imposes more cognitive load because now you have two different approaches to every problem in the same language (one async, one not).

IMHO minimizing language-imposed cognitive load should be a core goal of any programming language. Human brains are finite, and programmers should spend the majority of their mental energy thinking about the problem being solved not the language.

Post reply on HN