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

71–80 of 466 posts

Re: Why Go Is Not Good (2014)

#71

Post by [deleted] »

innerspirit wrote: post #64
justin_vanw wrote: post #48

Earlier quoted context omitted.

Type 1 defines: .add(x) Type 2 defines: .plus(x) Type 3 defines: .vector_add(x) Now, implement a function 'average' that can work on any of these three types. If you can get everyone in the world to agree to a convention of how to express 'addition', then there is no difference, except we already have a convention for 500 years, and it is the '+' operator. Why you think the '+' operator is confusing but .plus() is no…

At this point, operator overloading would simply be another convention, would it not? Your type would not work with mine if I used .add instead. You did not solve the problem of having to get everyone to agree on a convention.

[deleted]

Re: Why Go Is Not Good (2014)

#72

Post by ashark »

mydpy wrote: post #35

When I first learned Python and Scala, they 'hooked' me practically instantly. As my ability with these languages matured, I learned their strengths and weaknesses, and (try) use the tools where their strengths are complimented. Trying Go had practically the opposite emotional response: It didn't take long to get a bad taste in my mouth while using the language (a lot of, where is feature X from my favorite language,…

The Good: Goroutines, the tools, the standard library, YAGNI to the bone, less testing needed compared with Ruby, Python et c, if you'd otherwise be using one of those.

The Bad: Hard to keep DRY, writing testable code can require a bit more planning that one may be used to, frustrating newbie experience[1]

[1] go command errors if run after installing if you don't configure it (set proper env vars) first, tools that are basically essential to having a good experience with the language aren't packaged with it and have to be tracked down individually (probably someone's written a nice shell script that takes care of that, but it's silly that that was necessary)

Re: Why Go Is Not Good (2014)

#73

Post by TillE »

omginternets wrote: post #31
cmrdporcupine wrote: post #9

Earlier quoted context omitted.

I agree that operator overloading is probably a feature not wanted in a language with this target problem domain. However "working as intended" I think is also the response of Go to their lack-of-generics, which I think is kind of crap.

>I think is also the response of Go to their lack-of-generics, which I think is kind of crap. The response I've overwhelmingly observed from qualified voices isn't "boo generics!" but "generics are terribly difficult to get right, and we want to know more about Go's niche before making any design decisions in that realm". I suspect you're reading a lot of drivel from web programmers who discovered net/http last Thurs…

A huge variety of other languages have successfully implemented generics. The Go team seems to be looking for some mythical ideal solution with no tradeoffs, and will therefore never do it.

Re: Why Go Is Not Good (2014)

#74

Post by dgellow »

cloud_monk wrote: post #20
gendoikari wrote: post #4

Earlier quoted context omitted.

What do you think about goroutines and channels?

I think the way Go addresses concurrency is simple and straight-forward. It's trivial to write concurrent applications. If your target is writing semi-low-level infrastructure software I think Go is a great choice. It's definitely got a lot of fans in the world of people writing software for DevOpsy type applications. From a personal standpoint, it's missing a lot of the features I like, namely ADTs, list comprehensi…

> I think the way Go addresses concurrency is simple and straight-forward. It's trivial to write concurrent applications.

Yes, CSP[0] is a very interesting concept. But it's not something unique to the go language.

[0] https://en.wikipedia.org/wiki/Communicating_sequential_proce...

Re: Why Go Is Not Good (2014)

#75

Post by TeeWEE »

mydpy wrote: post #35

When I first learned Python and Scala, they 'hooked' me practically instantly. As my ability with these languages matured, I learned their strengths and weaknesses, and (try) use the tools where their strengths are complimented. Trying Go had practically the opposite emotional response: It didn't take long to get a bad taste in my mouth while using the language (a lot of, where is feature X from my favorite language,…

Ever wrote a big program in python? Then you know it works at runtime. Not at compile time. Go comes with more typesafety while being a bit more verbose. Its a tradeoff.

Re: Why Go Is Not Good (2014)

#76

Post by andrew_wc_brown »

Go is good enough when you're switching from Ruby to Go and all you do is build web-applications.

* Its forced syntax stops syntax wars. * Compiling down to one binary makes deployment easy. * Its has concurrency out of the box. * Its insanely fast. * A strong community to hire developers easily enough.

Does Haskel/Rust have the same criteria? Shurgs

Re: Why Go Is Not Good (2014)

#77

Post by jkaptur »

Using the author's standards, adding features to a language is always a good idea.

> All well-written code is easy to read, and most poorly-written code is hard to read. Obviously Go can't change that.

I completely disagree. Languages with lots of features can make poorly-written code vastly more difficult to read.

Re: Why Go Is Not Good (2014)

#79

Post by masklinn »

coldpie wrote: post #69
masklinn wrote: post #65

Earlier quoted context omitted.

> Operator overloading is consistently one of the worst ideas I see in programming languages Except when not having it is the worst. Working with BigDecimal in Java is hell because it does not have operative overloading, meaning while you avoid boostfs::path path("/some/path"); path /= "yourfile.txt"; you get saddled with bullshit like x.add(x.add(ONE).pow(2).subtract(x))

Eh, there's already no language symbols for exponentiation (unless you're really going to overload XOR in which case you're already part of the problem).

`.pow` is the least problematic part of my example by a fairly long shot. Even keeping it, with operator overloading you'd get

    x + ((x + ONE).pow(2) - x)
or

    x + (pow(x + ONE) - x)

Re: Why Go Is Not Good (2014)

#80

Post by pcwalton »

coldpie wrote: post #63
justin_vanw wrote: post #48

Earlier quoted context omitted.

Type 1 defines: .add(x) Type 2 defines: .plus(x) Type 3 defines: .vector_add(x) Now, implement a function 'average' that can work on any of these three types. If you can get everyone in the world to agree to a convention of how to express 'addition', then there is no difference, except we already have a convention for 500 years, and it is the '+' operator. Why you think the '+' operator is confusing but .plus() is no…

> Now, implement a function 'average' that can work on any of these three types. I'm not convinced this is such a large problem that its solution is worth the myriad downsides that operator overloading is chained to. There's lots of schoolbook examples like this, but I've almost never seen operator overloading used well in practice. There's a few examples, like boost shared pointers are somewhat easier to read, but t…

> There's lots of schoolbook examples like this, but I've almost never seen operator overloading used well in practice.

I do graphics programming and I literally rely on it all the time.

Post reply on HN