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

431–440 of 466 posts

Re: Why Go Is Not Good (2014)

#431

Post by seren »

koffiezet wrote: post #428
loudmax wrote: post #298

Earlier quoted context omitted.

Agreed. I foresee a great future for Rust, and also a great future for HN posts in the form: "I know I'll get downvoted for this, but Rust is a terrible language because it lacks the following features..."

While Rust in it's own little world is promising, it's issue is that it tries to solve problems C++ programmers were facing 10 years ago, but 'good practices' and C++ devs limiting themselves to a subset of features "solved" most of these problems for most C++ developers. And that's Rust's main target audience. Go's target audience are 2 groups: people previously writing stuff in C/C++ because they didn't have much c…

Servo is one, but I believe that Rust needs another high profile project targeted to the embedded or low level system world to gain mind share.

It has to demonstrate that

Rust > ( C/C++ + Static/dynamic analysis )

in terms of safety and productivity.

Re: Why Go Is Not Good (2014)

#432

Post by Depado »

mike_hearn wrote: post #196
Zikes wrote: post #87

I like Go. It's fun, it's fast, and it's introduced me to a lot of programming concepts I had never used before. The one thing that seems to be missing from these discussions is that Go fits in an unexpected niche. I come from a web development background. I grew up on Perl, ASP, PHP, and Javascript. I dabbled a bit in C in college, but I always felt like I was fighting to avoid shooting myself in the foot with it. F…

I think the main question then is, why don't you take a look at more modern languages than Go and see if you have the same experience (fun, fast, introduces to new programming concepts)? You could start by checking out https://kotlinlang.org/ - it targets the JVM so the tools are much better than what Go has and the library ecosystem is much larger. The language is a straightforward imperative style language that wil…

Targeting the JVM seems like a trending practice nowadays. But I can't really see why it's so great. You'll need to install the JVM to your platform before you can execute anything. You'll also need to install it on your server to serve a web application. I don't know how that works but it sure adds some complexity to the deployment.

Re: Why Go Is Not Good (2014)

#433

Post by mtrn »

koffiezet wrote: post #428
loudmax wrote: post #298

Earlier quoted context omitted.

Agreed. I foresee a great future for Rust, and also a great future for HN posts in the form: "I know I'll get downvoted for this, but Rust is a terrible language because it lacks the following features..."

While Rust in it's own little world is promising, it's issue is that it tries to solve problems C++ programmers were facing 10 years ago, but 'good practices' and C++ devs limiting themselves to a subset of features "solved" most of these problems for most C++ developers. And that's Rust's main target audience. Go's target audience are 2 groups: people previously writing stuff in C/C++ because they didn't have much c…

> For me it was the first language where diving into the source code of libraries - even the stdlib - was so effortless and has become a completely normal thing to do.

A great point. It is amazing how many little things Go and its ecosystem provides, that other languages have missed for years: go fmt. linked documentation. play.golang.org, and more. The language may look like it comes from the 80s, but the tooling is avant-garde.

Re: Why Go Is Not Good (2014)

#434

Post by burntsushi »

spion wrote: post #409
AnimalMuppet wrote: post #356

Earlier quoted context omitted.

You're coming from the same bias as the author of the article: Haskell and Rust are what a language should look like; Go doesn't look like that, therefore Go is bad. Take one of your points: > Go will never implement immutable data structures. Its impossible to write an immutable data structure library without generics. Fine; I won't argue whether your statement is correct. But so what? That only turns into something…

Once you get data races in Go, you realize that immutable data structures are indeed the right way. Too bad though. That non-threadsafe, racy map is your only generic data structure. I think that critics are generally cutting way too much slack to Go. Its a horrible language - with a decent library and excellent tooling and documentation, but still quite horrible.

> you realize that immutable data structures are indeed the right way

Well, that's false. Rust has mutable data structures but also statically prevents data races.

Re: Why Go Is Not Good (2014)

#435

Post by mike_hearn »

Depado wrote: post #432
mike_hearn wrote: post #196

Earlier quoted context omitted.

I think the main question then is, why don't you take a look at more modern languages than Go and see if you have the same experience (fun, fast, introduces to new programming concepts)? You could start by checking out https://kotlinlang.org/ - it targets the JVM so the tools are much better than what Go has and the library ecosystem is much larger. The language is a straightforward imperative style language that wil…

Targeting the JVM seems like a trending practice nowadays. But I can't really see why it's so great. You'll need to install the JVM to your platform before you can execute anything. You'll also need to install it on your server to serve a web application. I don't know how that works but it sure adds some complexity to the deployment.

If by "install" you mean "unzip", sure.

People like JVMs because they provide a lot of services that are really useful, such as:

• State of the art garbage collectors, which you can tune for throughput or low pause times (there's a fundamental tradeoff here, there's no one-size-fits-all GC algorithm)

• Visual debugging that always works, including remotely

• Stack traces that always works

• Advanced profiler and monitoring tools

• Very robust and portable build systems

• Extremely fast compiles (this is touted as an advantage of Go, but I never find myself waiting for a compiler when working with Java or Kotlin).

• Giant standard library and even larger ecosystem of well designed and documented libraries to do many different tasks

• Language interop - you can normally use libraries written in one JVM language from others. This obviously helps with the former point.

• In some cases (e.g. actor frameworks and big web servers) code hotswapping and dynamic loading.

The Go runtime lacks a good chunk of these useful features: the last time I worked with a Go shop they told me debugging hardly worked, because error handling was "propagate an error code" they never had stack traces in their logs for failures, profiling was primitive or not available at all depending on platform, the standard library was small (compared to the JDK), and language interop was "it can call C". Also the GC sucked, though I heard they have a better one now. But it's still a one-size-fits-all approach, which has well known problems.

Re: Why Go Is Not Good (2014)

#436

Post by mike_hearn »

geodel wrote: post #260
mike_hearn wrote: post #196

Earlier quoted context omitted.

I think the main question then is, why don't you take a look at more modern languages than Go and see if you have the same experience (fun, fast, introduces to new programming concepts)? You could start by checking out https://kotlinlang.org/ - it targets the JVM so the tools are much better than what Go has and the library ecosystem is much larger. The language is a straightforward imperative style language that wil…

Are you saying Kotlin has strict superset of all Go features. As I think it does not have value types or inbuilt concurrency.

If by "inbuilt concurrency" you mean Go-style channels/green threads, there's something called Quasar which adds that. Otherwise Kotlin inherits all the concurrency support the JVM provides, including quite advanced things like speculative hardware transactional memory.

Re: Why Go Is Not Good (2014)

#438

Post by 4ad »

iofj wrote: post #422
exDM69 wrote: post #324

Earlier quoted context omitted.

Huh? Care to elaborate on this? As far as I know, GTK (and Qt IIRC) use a single threaded event loop. That's not at all the same thing (albeit can be used for similar things).

Qt and Gtk's single threaded event loop are akin to what Go calls it's scheduler. That scheduler in Go is also (partially) single threaded, but event handlers run in other threads. Having event handlers run in separate threads is very much supported in both Qt and Gtk (they can't be UI event handlers in quite a few cases, but network events and file reading in separate threads scheduled by the central event loop like…

Go scheduler is not single threaded (whatever that means).

Re: Why Go Is Not Good (2014)

#439

Post by superskierpat »

dkuntz2 wrote: post #372
sanderjd wrote: post #369

Earlier quoted context omitted.

I'm not sure that I've heard the argument that generics as a concept are bad , per se, but I believe I've heard the argument that they aren't very useful. I (again, non-empirically) disagree with that, but I don't know if it is a common belief in the Go community, and I don't disagree with you at all that generics wouldn't fit very well into Go's philosophy and design and probably don't belong in the language. I thin…

In practice I'm not sure I see where a PotentiallyErorredResponse object that wraps a response and error together is different from returning a response and an error. The advantage of Optional over returning a value or null is partially that it makes the programmer more aware of the fact that they're dealing with something that might be null. The same thing would be true of an Errorable wrapper. I'd argue that Go mak…

One thing I liked about the Option type in java is that it not only offered better clarity, it also came with a few cool methods, like ifPresent()

Re: Why Go Is Not Good (2014)

#440

Post by thegeekpirate »

innocentoldguy wrote: post #378
thegeekpirate wrote: post #309

Earlier quoted context omitted.

Your post (and in turn, my reply) had absolutely nothing to do with the article. > I don't think a language's popularity has anything to do with it being a good, well-thought-out language. Just look at Javascript. My point is that it's popular because we've been forced into using it, and the web is now much larger than it used to be. I'm explaining why it became popular, despite it's downfalls. No other recent (past…

Furthermore, there are plenty of less-than-stellar languages out there that are popular for a time, so companies flock to them, build applications and services in them, and are then forced to maintain that code for years and years to come; which is one of the points of this article. You are the only one who inferred Javascript's unique circumstances and then extrapolated an irrelevant argument with me based on your o…

If that's the case, care to name off some instances of a language becoming wildly popular for businesses and then just as quickly dying off outside of the JavaScript ecosystem in the last decade?

You seem to be missing the forest for the trees here. You said:

> I don't think a language's popularity has anything to do with it being a good, well-thought-out language.

Then used JavaScript as an example of this:

> Just look at Javascript.

I have sufficiently explained why your correlation does not equal causation, as JavaScript is the only language I'm aware of to have gone through being popular while at the same time being a poorly-built language in the past decade, and hence, being a poor analogy as an attempt to prove your point.

If you'd care to at the very least show some other examples, I'd be overjoyed to see them.

For the record, I completely agree with your point—I also don't believe popularity is directly correlated by the design of the language—but I don't have a single shred of evidence to back it up, only examples from outside of the programming ecosystem. That's why I'm inquiring.

Post reply on HN