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

Why Go Is Not Good (2014)

yager.io

Post reply on HN
Print view View original

461–466 of 466 posts

Re: Why Go Is Not Good (2014)

#461

Post by burntsushi »

spion wrote: post #460
burntsushi wrote: post #459

Earlier quoted context omitted.

> I admit to not knowing when you would prefer statically checked mutable data structures to immutable ones except for a few cases (dynamic programming arrays, fast matrix libraries, memory constrained environments). Those sound like pretty compelling use cases to me, and also ones that seem to be well suited for Rust. You might also consider looking at Servo; I bet its engineers could list a myriad number of reasons…

Its not just that shared mutable state is hard, I'm thinking of the whole reasoning apparatus you get at your disposal: http://www.haskellforall.com/2013/12/equational-reasoning.ht... That indeed seems very much like something that can be called the "right way". If all functions in a given subset of the code are pure I can even imagine a tool that combines hoogle with your function's type signature and existing types…

> That indeed seems very much like something that can be called the "right way".

No. It's just another useful tool in the toolbox. It comes with costs. Sometimes you don't want to pay them. Stop trying to monopolize "the right way."

Re: Why Go Is Not Good (2014)

#462

Post by spion »

burntsushi wrote: post #461
spion wrote: post #460

Earlier quoted context omitted.

Its not just that shared mutable state is hard, I'm thinking of the whole reasoning apparatus you get at your disposal: http://www.haskellforall.com/2013/12/equational-reasoning.ht... That indeed seems very much like something that can be called the "right way". If all functions in a given subset of the code are pure I can even imagine a tool that combines hoogle with your function's type signature and existing types…

> That indeed seems very much like something that can be called the "right way". No. It's just another useful tool in the toolbox. It comes with costs. Sometimes you don't want to pay them. Stop trying to monopolize "the right way."

I am not trying to monopolize "the right way". We were originally talking about Go, a language with a garbage collector made for writing concurrent servers. This is an area where immutable data structures are a no-brainer "right way" to avoid data races in the majority of cases, and I was expressing my frustration at the inability to write them in Go.

I really have no idea how the conversation became one about writing browser engines, embedded systems or systems with realtime constraints in Rust :)

Re: Why Go Is Not Good (2014)

#463

Post by burntsushi »

spion wrote: post #462
burntsushi wrote: post #461

Earlier quoted context omitted.

> That indeed seems very much like something that can be called the "right way". No. It's just another useful tool in the toolbox. It comes with costs. Sometimes you don't want to pay them. Stop trying to monopolize "the right way."

I am not trying to monopolize "the right way". We were originally talking about Go, a language with a garbage collector made for writing concurrent servers. This is an area where immutable data structures are a no-brainer "right way" to avoid data races in the majority of cases, and I was expressing my frustration at the inability to write them in Go. I really have no idea how the conversation became one about writin…

> This is an area where immutable data structures are a no-brainer "right way" to avoid data races in the majority of cases

I continue to find your phrasing extremely off-putting, condescending and snobbish. I suggested a few ways of wording your concerns better, but it seems you're intent on remaining a snob.

I disagree that anything about your suggestion is a "no-brainer."

Re: Why Go Is Not Good (2014)

#464

Post by spion »

burntsushi wrote: post #463
spion wrote: post #462

Earlier quoted context omitted.

I am not trying to monopolize "the right way". We were originally talking about Go, a language with a garbage collector made for writing concurrent servers. This is an area where immutable data structures are a no-brainer "right way" to avoid data races in the majority of cases, and I was expressing my frustration at the inability to write them in Go. I really have no idea how the conversation became one about writin…

> This is an area where immutable data structures are a no-brainer "right way" to avoid data races in the majority of cases I continue to find your phrasing extremely off-putting, condescending and snobbish. I suggested a few ways of wording your concerns better, but it seems you're intent on remaining a snob. I disagree that anything about your suggestion is a "no-brainer."

> I continue to find your phrasing extremely off-putting, condescending and snobbish. I suggested a few ways of wording your concerns better, but it seems you're intent on remaining a snob.

Thats a bit over the top, but I'll concede that my wording needs work. I enjoy discussing concrete problems and projects - hopefully fixing this will help get more of that. You did make some very good points as to why we avoid mutation, and I will try and evaluate Rust in more depth.

Re: Why Go Is Not Good (2014)

#465

Post by gbhn »

ionforce wrote: post #282
gbhn wrote: post #235

Earlier quoted context omitted.

My (inexpert) opinion is that the kind of computer language researcher or practitioner interested in exploring how far you can go with type systems is dissatisfied with Go. But there are many types of static analysis which accomplish similar (or more dramatic) goals than what can be down with type analysis, and the simplicity of a language makes those kinds of analyses more reachable. Examples: gofmt and gofix. I thi…

What part of types is change resistant?

To me, a lot of the more interesting areas of type research basically involve embedding logic into types. So types for sequencing of operations, types that constrain the data in them, etc. Those are awesome in that they enable static analysis to detect more sorts of logic errors in a digestible way, but my impression is that they end up encoding constraints in the type system that are then harder to change as the demands on the system evolve.

Re: Why Go Is Not Good (2014)

#466

Post by jbeja »

Veedrac wrote: post #47
pmilot wrote: post #12

I like this article and I agree with most of what was said there. Against that type of point-by-point criticism, fans of a language will usually use the argument: "but that language was not designed for that!". Then the question becomes: What was that language designed for? My impression was that Go was meant to be a slightly higher-level systems language with better constructs for concurrent programming. With that i…

I can't really see a world in which Rust is a "better Go". Rust is one of the more complex languages in existence, largely because it competes with C++ and thus can't afford to lose many features nor do many things the easy way. Go is one of the simplest languages in existence. It's on the other side of the charts.

> Go is one of the simplest languages in existence

Are you saying that is simple because:

1) Is so anemic and have a relatively small specification?

2) Let you solve problems in the most simple ways?

I could (maybe) kinda agree if you refer to 1...kinda.

Post reply on HN