loading...

How can I learn to like Golang? (and use it a lot)

patarapolw profile image Pacharapol Withayasakpunt ・1 min read

I don't Golang because,

  • I cannot set nil a variable (unless it is a pointer, but not sure if it is recommended to do so?)
  • GoDoc is restricted to // and isn't Markdown friendly. gofmt doesn't recognize /** */.
    • Actually, VSCode formatter can give colors to JavaDoc/JSDoc styled /** */ as well.
  • Centralized ~/go/pkg/packages/github.com/<NAME>/<PROJECT> structure, instead of my custom ~/projects/<PROJECT> structure
    • Actually, sometimes it is a monorepo, so ~/projects/<PROJECT>/packages/backend
  • Golang maker don't like vendorizing, like what node_modules do.

Rust's Cargo seems to be more happy with me, but it is a different language.

Discussion

markdown guide
 

No need to like something you just don't like. I've tried Go dozens of times and gave up. I feel too limited writing it and prefer Rust and C++ for system programming.

 

from your story bit interesting , could your gave more description about feel too limited when writing it? I just curious.

 

There is no way to go back to a incomplete, unsound, and generally haphazard type system like that of C++, Golang, Python, JavaScript once I have had a taste of the type system of an ML, i.e. that of Rust, OCaml, F#, or Haskell.

 

Hi Pacharapol!

I cannot set nil a variable (unless it is a pointer, but not sure if it is recommended to do so?)

Though by default variables are "zeroed", you can still do it, by using the empty interface:

var i interface{}
// the variable is empty
i = 10
// now its value is 10

Centralized ~/go/pkg/packages/github.com//

not really true anymore if you use go modules, packages will be in your project's directory. See blog.golang.org/using-go-modules

Golang maker don't like vendorizing, like what node_modules do.

go mod vendor. See github.com/golang/go/wiki/Modules#... and go help mod

Hope this helps :)

 

Thanks. I might try Golang again. There seems to be a lot of packages in Golang as well, actually, just like Python.

There is still an issue with GoDoc, as I mentioned above. And it mostly correlate with Swagger Codegen, as well as comment highlighting. But it is not that some languages like Python doesn't have this problem as well.

Nowadays, I rely a lot on Fastify's Request + Response validation --> and it seems that someone have ported in to Golang for me -- github.com/danielgtaylor/huma/

Again, yeah, Golang has so many packages that it might be worth it.

TBH, if I want strictness, I still have to compare Golang to Kotlin.

 

There is still an issue with GoDoc, as I mentioned above. And it mostly correlate with Swagger Codegen, as well as comment highlighting. But it is not that some languages like Python doesn't have this problem as well.

If there's one suggestion I can leave you with is not to try to bend Go to be similar to other languages :D Just "go with the flow" (no pun intended)

You won't find Go code with /* syntax anyway. You can find more info on Godoc here: blog.golang.org/godoc

Nowadays, I rely a lot on Fastify's Request + Response validation --> and it seems that someone have ported in to Golang for me -- github.com/danielgtaylor/huma/

I'm not familiar with Fastify or Huma but Go is pretty awesome at JSON validation having those inline tags:

type Data struct {
  Something string `json:something`
}

which tell the JSON serializer to map the field automatically :D

I think Go is worth a try, at least! Start with gobyexample.com/ :-)

 

I like working with Go lang, for most of the stuff you have mentioned.

  • Use of nil
    Coming from a background in PHP, I have dealt with code where null is misused immensely. So with go, I know that usage is limited. And I always have to depend on the default values for each type.

  • GoDoc has a simplified structure.
    And it's not overly bloated. I only have to document stuff that is public from a package.

  • Centralized
    This is no longer the case since we are moving away from GOPATH

  • Dependency management
    node_modules is one of the worst things I have worked with, I still work with node / Typescript for work. I still don't like it. With go, I used to use dep but since deprecating GOPATH, I have moved all my projects to use go mod

It's a given that some of these things might not appeal to everyone. I guess it's going to be a common thing, based on the experience we have with different programming language ecosystems. One major thing I prefer Go is due to the standard library.

 

If these are the only things to not like about Go, that is pretty good for a programming language.
Go is standardised by design. Its “limitations” is more a fact of simpler design. Working on multiple projects with many developers, Go code always looks the same. There are not many ways to be super clever and fancy which leads to easier collaboration and improved readability.

 

Totally agree with you. The only real problem I see with Go is the lack of generic types. That one is a harsh.

At least they are planning to add it in the future.

 

I haven't tried Golang much, but I still have to compare Golang to Kotlin, if I want it strict.

For non-strict, I would still use TypeScript.

Perhaps Generics mean some convenient inheritance???

Here is the TypeScript documentation about genetics:
typescriptlang.org/docs/handbook/g...

I’ve never used Kotlin, but I believe that it has generic-like features, like Java.

 

+1 for this. The lack of generics make writing more code which is why I prefer how TypeScript and Rust has handled the type system.

 

Agree; those what makes Go Go and what makes Go so good.

 

That sounds like a fancy way to say "Go lacks many important features"

 

Generics I agree. What else are those important features that you miss?

I was mostly talking about generics, but it also lacks proper exceptions, enums, and two ways to assign a variable (var and :=) among other things

 

I do not think Golang is a language worth learning if it is not for work. It does not add anything new to your knowledge. This is on purpose. It has avoided many modern programming language features in exchange for fast compile times, faster new developer on boarding and simpler cross-compiling support. For expanding your horizon on how to express ideas, Haskell really is THE eye-opener.

On the other hand, if you can see past your preferences and stop worrying, Golang generally takes well care of you. Decide on a domain problem and code away. You may find lack of distracting language features actually helpful.

 

"go mod vendor" vendors packages.

Since go 1.11 you don't need to use the gopath.

Why would you want to nil a variable? Use the zero value... That's what it's for.

You gripes come from some misunderstandings.

 

Why would you want to nil a variable? Use the zero value... That's what it's for.

Of course, so that's how it is designed, right?

I still dislike GoDoc style and integration with VSCode is not as powerful and color as JSDoc or JavaDoc. Even RustDoc's /// feels better.

GoDoc hates multiline commented markdown, to be exact.

If you view this in VSCode, it will be broken -- towardsdatascience.com/setting-up-...

 

I mean, yeah Godoc doesn't support markdown, but I argue that's a good thing. Comments should be brief and to the point, not formatted novels

+1. If your code needs multi-paragraph comments, I think your code probably needs to be clarified.