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

41–50 of 102 posts

Re: Less is exponentially more (2012)

#41

Post by ansible »

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.

Re: Less is exponentially more (2012)

#42

Post by decebalus1 »

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.

I don't think I agree. Anecdotally based on what was happening at companies I worked at which used Go, I think the main reason for its success was Google cargo-culting.

Re: Less is exponentially more (2012)

#43

Post by ex_amazon_sde »

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've worked with lots of languages as well and dependency management in Go is the worst.

Not being able to package build and runtime dependencies with proper versioning is an incredible pain.

Re: Less is exponentially more (2012)

#44

Post by hyperman1 »

jahaja wrote: post #13
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.…

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 had to generate a ton of test data programatically in java. So I wrote roughly a 3 line method

  T select(int index, T... values)
and used it on each of the fields with different types like this:

  struct.anInt=select(i,0,1,INT_MAX);
This allowed me to quickly iterate trough all combinations of common and edge cases. If I had to specify all cases individually, there was no chance I'd exhaustively test every combinations.

Re: Less is exponentially more (2012)

#45

Post by westicecoast32 »

I'm writing a language. I was wondering what you all suggest it have before you would seriously try it out? I don't think most people cares about syntax; does it need to be attached to a large project?

The beta of the last language I wrote had maybe half a dozen fans. I threw away the compiler/language because I didn't really know how to write a compiler back then. I'm writing a new one now

Re: Less is exponentially more (2012)

#46

Post by nobleach »

sanderjd wrote: post #33
eriktate wrote: post #31

Earlier quoted context omitted.

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

Yeah, I think the charge of "clever" is often thrown out when one uses a different way of thinking. I'm not an FP zealot at all, but I do think learning to think recursively does something to one's programming. (Working through SICP or even The Little Schemer) My own personal take it that I appreciated and enjoyed some of those paradigms far more. What I would NEVER try to do is turn Java or Go into those paradigms though. I would, however, like to have some of those handy niceties available by default. (I want to map over a collection and apply a function to each member). But again, that's a personal preference.

Re: Less is exponentially more (2012)

#47

Post by jatone »

nshepperd wrote: post #29

> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. > ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']... > If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition. How do you get all the way through designing a programming language with…

because generics generally are unncessary. there is a very small subset of programs where they are useful if you have arrays and maps already available.

there was no need to rush an implementation of generics.

Re: Less is exponentially more (2012)

#48

Post by ieRei6ae »

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…

> if you have a rotating team of engineers

That's the problem: burning out engineers.

Google has been developing a language to make it easier to change cogs in the machine.

The quotes from Pike are pretty clear:

http://nomad.uk.net/articles/why-gos-design-is-a-disservice-...

Re: Less is exponentially more (2012)

#49

Post by autarch »

nshepperd wrote: post #29

> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. > ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']... > If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition. How do you get all the way through designing a programming language with…

I was thinking exactly the same thing. I don't understand how you segue from generics to "too many types are bad" to "inheritance is bad". I totally agree with the last idea. Inheritance is not a great model for code and it quickly becomes unwieldy.

But that has nothing to do with having an expressive type system and generics.

We can look at Rust for an example. It's "OO model", such as it is, is fairly similar to Go's. You can define a thing that combines data and behavior. You can define traits/interfaces that objects can implement. You can use those trait/interface types in place of concrete types. But Rust also gives you generics, sum types, and pattern matching. IMO, that makes for much cleaner code than doing the equivalent in Go.

Re: Less is exponentially more (2012)

#50

Post by nobleach »

fwip wrote: post #27
tpaschalis wrote: post #17

Earlier quoted context omitted.

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…

One of the things that Go tries to do is keep you from accidentally calling expensive operations. Testing for membership in an array is O(n) in almost any language - and there's a lot of new coders who will happily call it inside a loop. My second internship, I reworked an O(n^4) method to O(n^2) for some code written in R by a senior statistician. This raised the feasible N from 4 to about 13 (in terms of what resul…

I absolutely get, and appreciate that. I'd never tell anyone NOT to use it. I'm simply sharing my own experience as I've been asked several times if I've ever considered Go for new services. I certainly have. I've produced. I just would choose not to do it again.
Post reply on HN