Some Observations While Learning Golang

buphmin on February 03, 2019

So I have been doing a bit of coding in golang recently and I figured I would share some of my observations. The Standard Library is Ve... [Read Full]
markdown guide
 

Some points I'd like to add, as a personal opinion since I re-started Golang recently.

  • Standard lib docs are pretty horrendous if you're not precisely on the given use case for examples
  • The template language is pretty confusing at first, you need to learn how to use its internals
  • While the STDLib's pretty complete, some critical and must-be-secure parts are missing (I'm mainly thinking of sessions)
 

While the STDLib's pretty complete, some critical and must-be-secure parts are missing (I'm mainly thinking of sessions)

I think sessions are missing in the stdlib because Go is mostly geared towards servers and API servers than "web apps".

To be even fairer, a lot of languages do not have "sessions" builtin in the standard library, you can build that on top of cookies, which Go supports.

 

That's true. The problem is that sessions are often carrying sensitive data, and having to reinvent the wheel on this precise topic can generate some problems.

Another problem for that is that there's no common interface, and most session libraries are either not audited, not maintained or very complex for almost nothing.

Another problem for that is that there's no common interface, and most session libraries are either not audited, not maintained or very complex for almost nothing.

That goes back to my initial point. I rarely see people writing about having used Go for a traditional web app (I for one wouldn't as a first choice, it's way faster to build a web app using other platforms), which might be the reason why there are not enough eyes around session management and user authentication libraries. Just a hunch

 

That is fair about the docs. Yeah they are not great, I have had to use some outside resources to clarify some things.

I haven't yet worked with Go in a web context yet, except as a quick performance test with a single endpoint that called a raw sql statement with no auth. So maybe I will run into the templating and sessions at that point.

 

Coming from doing a lot of Python, the strict typing was fabulous to use. That and "go vet" caught so many errors. I found I could write quite complex "script" programs without any unit tests and they would work! (mostly)

Another thing from Python is that the concurrency is much more a part of the core language than in Python. In Python, to do several things at once I'd have to set up a queue for interprocess communications and import more libraries for threading. In Go, all that stuff just happens!

The dependency thing is currently "in progress" to be fixed, I've just converted a project over to having a "go.mod" file which is now working nicely for go 1.11 and this does seem slightly better.

 

Have you tried the golang dep tool for dependency management?

golang.github.io/dep/

Give it a try, it's a nice tool.

 

I have heard of it but I have not used it. Since go modules seems to be the official direction of the language I went with that for my project.

 

The dep tool is an official golang tool as well.

 

Great observations and I definitely feel like the dependency management is something pretty common to the criticisms so I'm glad the maintainers are at least starting to focus on improving that.

 

Yeah, go modules seems like the right direction, I think once it really catches on go will be pretty good in this category. It did seem a bit odd when I first started playing with go that you needed environment variables as a language requirement prior to go modules.

 

Go's true power comes when you need concurrency.
If you haven't tried it yet, try play around with Go channels. It greatly simplifies things.

 

I've done a bit and they are quite simple. As I'm sure I will use them more soon :)

code of conduct - report abuse