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

31–40 of 102 posts

Re: Less is exponentially more (2012)

#31

Post by eriktate »

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…

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

I tend to conflate higher expressiveness with being "clever" until you're really proficient in the language. I think Go's main value prop is that it performs well with very little ramp up time compared to languages with more powerful features.

If you have a team of people who are really strong with something like OCaml or Scala, they'll be amazingly productive. But if you have a rotating team of engineers with varying backgrounds, it's hard to beat Go when you're talking about time-to-productivity.

Re: Less is exponentially more (2012)

#32

Post by sanderjd »

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…

To the "everything in Go is for loops" point of the parent, I really think the value of higher-level abstractions of common loop patterns are often underrated for readability and correctness. The advantage is that it is a lot more obvious when code veers from the pattern, which alerts the reader to spend more time thinking through what it is actually doing. Put another way, it is easier to write a for loop that looks like a 1:1 map from one set of values to another but actually does something a bit different, than it is to write a map operation that does something besides mapping.

Re: Less is exponentially more (2012)

#33

Post by sanderjd »

eriktate wrote: post #31
LandR wrote: post #16

Earlier quoted context omitted.

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…

> And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using. I tend to conflate higher expressiveness with being "clever" until you're really proficient in the language. I think Go's main value prop is that it performs well with very little ramp up time compared to languages with more powerful features. If you have a team of people who are really strong with something like OCaml…

The basic set of more expressive operations (like map, filter, and reduce/collect) are not "clever", they exist in lots of "boring" languages, not just languages like OCaml and Scala. It is true that their semantics must be learned, but this is also true of the semantics of for, while, if, switch, function(), object.method(), etc. etc. We don't lament that learning how function calls work is lengthening the ramp-up time of people who already know how to write straight-line code and jumps.

Re: Less is exponentially more (2012)

#34

Post by AnimalMuppet »

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.

OK, but for Go to succeed in that environment, it had to be better than Python and Java at programming for the cloud. It doesn't matter that Python and Java were "aging" - programming languages don't die from old age. Go had to be better than what was there.

And in what ways was it better? Power and simplicity (at least for writing those kinds of programs).

Re: Less is exponentially more (2012)

#35

Post by goatlover »

tpaschalis wrote: post #19
LandR wrote: post #16

Earlier quoted context omitted.

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.

2x more compared to ... C++, Java, Python/PHP/JS/Ruby, Haskell? Which kind of language is the comparison?

Re: Less is exponentially more (2012)

#36

Post by ses1984 »

ChrisSD wrote: post #7
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?

To be honest programmers have a habit of being very loose with language. Terms like "OOP" and "types" have very context dependent meanings. Given the context, I took him to simply be talking about people coming from "class-based" languages, not anything to do with types in general.

Yeah but it feels almost like a strawman, it feels out of place.

Re: Less is exponentially more (2012)

#37

Post by MereInterest »

For any new language that I learn, my go-to thing to try is to implement 4th-order Runge-Kutta solving of an ODE. This implementation must be usable for both built-in types and user-defined types, and must have reasonable performance for the language.

* C++, easily doable with templates.

* Python, easily doable with duck typing.

* Rust, doable, though with some restrictions. I needed to require the derivative function to return the same type as its input, rather than returning something that can be scalar multiplied and added to the same type as the input.

* Java, not possible. Adding/multiplying of built-in types can be done with + and * , but user-defined types require .add() and .multiply()

* Go, not possible. Go doesn't support generics, and I'm certainly not going to copy/paste a numeric method once for every system that I examine. Also, same issue as Java with no operator overloading.

Complexity has to go somewhere. By aiming for a simple language, Go forces the complexity to be in the developer side instead.

Re: Less is exponentially more (2012)

#38

Post by AnimalMuppet »

pjmlp wrote: post #23
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.

Go is basically Limbo combined with Oberon-2 method syntax, two very successful programming languages from Bell Labs and ETHZ respectively, hence why Go was such a guaranteed success.

First, combining two successful languages in no way guarantees success. (Imagine combining Lisp with C++ syntax.) There are lots of ways to do it where the whole is less than either of the parts.

Second, you seem to have a strange definition of "success". Limbo was a success? Well, some people used it, and some software got written in it, and some people used the software. Not much software and not many people, though, in the grand scheme of things. Same with Oberon-2. Even if you consider those two languages to have been successes, Go is a far greater success - it's successful in a way that neither Limbo nor Oberon-2 ever were.

Re: Less is exponentially more (2012)

#39

Post by pydry »

throwaway894345 wrote: post #22
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…

It's interesting the things that people think are essential and the things they are willing to put up with. I'm willing to put up with writing my own sort.Interface, adding in a few lines of boilerplate for error handling, loops, and the odd linked-list/btree/etc. I'm not willing to script my own build system in an imperative DSL or deal with dependency hell a la Java, Python, C/C++, etc. I'm willing but very relucta…

>I'm not willing to script my own build system in an imperative DSL or deal with dependency hell a la Java, Python, C/C++, etc.

Ironically, the fact go tried to make me use GitHub as a stopgap package manager (& denied one was necessary) while they built their own was what made me run away screaming.

They've since fixed that but seeing them fail at what Perl managed in 1995 and what became standard is larger languages around the turn of the millenium in a brand new language in 2010 wasn't a great omen.

Re: Less is exponentially more (2012)

#40

Post by smoorman1024 »

I've been working in golang professionally for about a year now coming from a long career in C++. Although there is some simplicity to golang that can be appreciated things like this below make me think that the premise of less is more is fundamentally incorrect if you cannot accomplish everything that is necessary.

https://github.com/protocolbuffers/protobuf-go/blob/master/i...

Specifically the last one of embedding an empty array of mutexes into a struct prevents that struct from being copied. This is something that is easily and explicitly accomplished in C++ by making the constructors private.

Post reply on HN