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

51–60 of 102 posts

Re: Less is exponentially more (2012)

#51

Post by throwaway894345 »

pydry wrote: post #39
throwaway894345 wrote: post #22

Earlier quoted context omitted.

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 language…

People scoff about "GitHub as a package manager", but it hasn't chafed me much. Moreover, the scoffing isn't very substantial--it's often some variation of "but GitHub goes down all the time?! You will never be able to build/distribute your software!", which is trivially refuted (the GitHub UI goes down all the time, but its git service going down is much rarer; you can use a caching proxy if you're really concerned about reliability of the git service just like you would with a more typical package repo; GitHub isn't necessary to distribute Go applications unlike Pypi/NPM/etc for Python/JS apps). There are probably lots of good reasons for why the GitHub model is inadequate, but for whatever reason these aren't brought up in the aforementioned scoffing and I haven't stumbled on them (e.g., I don't have any private repo dependencies for my projects, but perhaps it would be a PITA for those who do?).

Re: Less is exponentially more (2012)

#52

Post by jahaja »

hyperman1 wrote: post #44
jahaja wrote: post #13

Earlier quoted context omitted.

> 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.…

Partially I agree,and I'm not happy to see this downvoted. But more code written equals more code to read. Adding a field to a struct means modifying all the boilerplate too. It is all to common to forget just one place. Boilerplate plus maintenance attracts bugs. Generics are easily overused and abused, but a well placed generic can save a ton of time. As an example, and the pnly generic I wrote in a week, today I h…

I agree of course that there will always be situations where generics/expressiveness will be convenient. But my argument is about proportionality. I'd like to optimize for the 98% of the time spent, not the last 2%. It's like when people insists on buying an ultraportable laptop for work even though they'll never move it from their desk. - "But imagine how nice it will be that time I'll be on the train!".

Re: Less is exponentially more (2012)

#53

Post by tonyedgecombe »

ansible wrote: post #41
acarl005 wrote: post #28

Whenever the topic of generics comes up, especially in Go, things seem to devolve into a ragefest about inheritance and OOP. Why? I don't want the mess of inheritance any more than the next chap. I just want generics for algebraic types—a single definition for a List, Set, Map. I wish the error-handling looked more like Rust's Result type instead of the double-return idiom. Algebraic types alone (without inheritance)…

> I wish the error-handling looked more like Rust's Result type instead of the double-return idiom. After this and a few other issues I had with Go's design, I just started learning Rust. Though I hear good things about Swift these days, hopefully they will provide full support for all popular platforms in the future.

Swift is nice but I don't see it making much sense outside of the Apple ecosystem.

Re: Less is exponentially more (2012)

#54

Post by winrid »

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…

Go has been by far the worst language for me to deal with dependencies. Java probably being the best, especially if you factor in build times.

Re: Less is exponentially more (2012)

#55

Post by dunefox »

AnimalMuppet wrote: post #34
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).

It didn't have to be better (since it isn't), it juset had to be backed and pushed by Google.

Re: Less is exponentially more (2012)

#56

Post by dunefox »

DLA wrote: post #26

I'm going to jump in and take a hard Pro-Go stance. Based on experience developing for more than 5 year with Go and deploying systems around the world--in-house hosted and cloud. I have immensely enjoyed the "less is exponentially more" philosophy with Go. In Go there is one or a small number of way to do something. Contrast that with C++ where there are any number of ways to do something and at least as many styles…

> I abhor the Java ecosystem for so many reasons I just don't have the energy to go into.

If you can gather some energy, I'd be interested in that.

Re: Less is exponentially more (2012)

#57

Post by winrid »

tonyedgecombe wrote: post #53
ansible wrote: post #41

Earlier quoted context omitted.

> I wish the error-handling looked more like Rust's Result type instead of the double-return idiom. After this and a few other issues I had with Go's design, I just started learning Rust. Though I hear good things about Swift these days, hopefully they will provide full support for all popular platforms in the future.

Swift is nice but I don't see it making much sense outside of the Apple ecosystem.

It's a wonderful language. I'd love to work with it server side it I found said job.

Re: Less is exponentially more (2012)

#58

Post by sl1ck731 »

AnimalMuppet wrote: post #34
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).

Why did it have to be better? It just had to be created and evangelized to a specific group (and likely because it was by a specific company). I don't think it has anything to do with "better" in one way or the other.

Developers are constantly looking for new languages to fiddle with without any objective reasoning.

Re: Less is exponentially more (2012)

#59

Post by winrid »

dunefox wrote: post #56
DLA wrote: post #26

I'm going to jump in and take a hard Pro-Go stance. Based on experience developing for more than 5 year with Go and deploying systems around the world--in-house hosted and cloud. I have immensely enjoyed the "less is exponentially more" philosophy with Go. In Go there is one or a small number of way to do something. Contrast that with C++ where there are any number of ways to do something and at least as many styles…

> I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. If you can gather some energy, I'd be interested in that.

Same!! Although, an experienced C++ dev might just abhor the thought of pointer chasing everywhere, even if it's not a big deal in 90% of web backends.

Re: Less is exponentially more (2012)

#60

Post by pjmlp »

AnimalMuppet wrote: post #38
pjmlp wrote: post #23

Earlier quoted context omitted.

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, thoug…

Exactly, that is why it was needed to add the Google branding into the mixing potion.

Had Go been created at Bell Labs or ETHZ, and it would have shared the same fate as its influences.

You missed the sarcasm on my comment.

Post reply on HN