Hacker News Reader

Comment by 12298765 | Hacker News Reader

I'm curious, what is painful about it?

I came to Go from mainly C++, Java, and Python background, and I feel like it's the best of all 3 (to me). It's compiled and really fast (like C++), it has a great set of libraries and community interaction/support (like Java), and it has simple syntax that is clear and quick to understand (like Python).

It's not a perfect language (nothing can ever be), but it's become my favorite to use for back-end web services and even taken over some of my scripting workflow.

I can see it being painful if you're trying to render websites server-side though. That's a bit outside of what it's made for

View on HN

On the topic of web frameworks, though, I firmly believe it is possible to write a delightful web framework with mass appeal (like Rails) in any language, you just need the right influences and conventions, but this seldom happens because the people who could write it are already busy enjoying their framework in the language that they enjoy most.

I talked with a few people who wrote Go servers and while they loved almost everything about the language and ecosystem, they hates the missing generics so much, they still switched to other languages later.

Writing code-generators for everything wasn't fun.

I don't miss generics in Go and I have used generics in C++ a good deal. I think the whole generics argument against Go is largely parroted by people who may not even know what generics even are. C doesn't have Generics either. It's doing OK.

that isn't true at all, function macros serve as the moral equivalent of generics.

Any language that doesn't have generics, including C and Go, have to work around that limitation. In C, people get around this by using void* (equivalent to using interface{} in Go) or code generation via macros.

I'd flip what you said and say that most of the people arguing against generics in Go don't have much or any experience with them. Which makes sense because a large number of users came from dynamically typed languages.

Personally, I find the concurrency support quite lacking. Compared to Java/Javascript/Python/etc, it's great, but nothing compared to languages like Ada or Elixir.

I wish we could use more than channels - for me, I often feel like I'm shoehorning them in because there's no support for protected objects (native queues, conditional variables etc).

Perhaps I'm just using them wrong. Sometimes I have to use locks, and I don't think we should be forced to use locks in 2019. We've had better solutions since the 80s.

I find waitgroups to be similar to condvars

> Sometimes I have to use locks, and I don't think we should be forced to use locks in 2019. We've had better solutions since the 80s.

Absolutely not. Locks/spinlocks are found in pretty much every significantly parallel software project. It is pretty arrogant to criticize almost all software architectures on earth.

> It is pretty arrogant to criticize almost all software architectures on earth.

Almost all software is programmed with modern languages, which all (imo) have extremely lackluster support for concurrency. It's not a symptom of the programmers, but the tools they work with. Who uses Ada these days?

Locks should only be used when other protection mechanisms are too slow.

Semantically, the critical region protected by a lock is not connected to the lock in any way. This can make debugging races super difficult, and you have to rely on everyone to lock everything at the right point.

Juggling multiple locks in complex concurrent processes is difficult, and prone to bugs.

I struggle to think of where a lock is required, barring the extremely hyperoptimised hot paths within operating systems, or similar applications.

Here's a good starting list: https://www.reddit.com/r/programming/comments/an33mo/aspnet_...

Go has GC and a runtime so you can argue it's not really close to C/C++/Rust at all and much closer to AOT Java.

Personally I found it too easy to accidentally forget to check an error, or to shadow a named error return, or to create a nil error that doesn't compare equal to nil. Also to write a method that appears to mutate the receiver but which in fact copies it.

> I found it too easy to accidentally forget to check an error

Use https://github.com/kisielk/errcheck for that.

Or prefer https://staticcheck.io/ for a larger set of checks.

    fmt.Println("foo")

I don't see errcheck complaining there

how about (taken from here: (https://www.reddit.com/r/programming/comments/ak305l/goodbye...):

    r1, err := fn1()
    r2, err = fn2()
    if err != nil {
      return err
    }

err check doesn't complain either

That second example is really surprising. This sort of thing happens all the time in production when lines get moved around. Does anyone know why errcheck misses it?

Not sure about that. But https://github.com/gordonklaus/ineffassign catches that.

use an IDE

What's a good IDE for Go? Something that's snappy and fast, no Java dinosaurs please

I mean GoLand is pretty good, but I do also like IntelliJ, so YMMV if you don't like the JetBrains products. And it isn't free.

VSCode is also really good for Go, I was surprised. There are plugins that massively help with testing, syntax checking, error handling, etc. I think it actually catches more issues than GoLand!

I've tried VSCode but it seems to require you to install Go... It can't even find the declaration of a variable or the definition of a function without Go, while Sublime can.

Visual Studio Code with the official go extension is really great and snappy

Emacs with go-guru.

In all honesty, indenting with more than 2 spaces (or, gasp, with tabs) is enough to kill a language for me these days. There are so many competing "new age systems languages" as I call them (crystal/rust/go/nim/d/julia/etc) that you really can pick the one that suits you the most. Crystal is more my speed. Yes go is way more mature, and has all the features I want, but it just isn't set up how I want things to be set up, whereas Crystal is. Is Crystal perfect? No, but it's the closest thing to what I want, and has all the appearances, trappings, etc., that I would expect of a language sent by the gods. The way go code looks just doesn't do that for me, but I'm sure it does for the people who created it.

Reply on news.ycombinator.com