christophberger

The first rule of writing safety-critical systems in C: Don't write safety-critical systems in C.

You don't need to measure your impact. It's enough to describe it. "Helped a large client improving their web presence for achieving increased conversion rates." Of course, you were part of a team and of course, you can't show precise statistics. But if they existed, would those stats be worth anything to a recruiter? Your next job will be different in many aspects. No recruiter will read some stats and say, "oh, that person's work increased the company's revenue by 1.5%, so we expect the same result at our company."

In a CV, the impact you made is a story to tell, not a number to calculate.

A must-read (or rather: must-see) for anyone who thinks exponential backoff is overrated.

The number of lines needed is not a good measure for gnarliness.

(To be fair, I don't know if gnarliness is measurable at all.)

I am afraid I cannot give you a direct answer, but here are two thoughts:

1. There seem to be a consent among Gophers to avoid frameworks where possible and use libraries instead. Frameworks are good for a quick start but when you hit their limits it is very difficult to break out of these limits. Libraries allow to compose an application out of independent building blocks. Your main package is always the one in control.

2. "backend/server" can have different meanings. If you can get more specific about the kind of backend or server you want to build, it will be easier for you to find the appropriate libraries (or maybe even one or another framework). Two good places to start are (a) a GitHub search with the search terms "language:go sort:stars <your search term>", and (b) if you prefer curated lists, awesomego.com. You might even try searching GitHub for "language:go sort:stars django" to see some Go projects based on Django's patterns and ideas.

I wonder how the current Go 1.9.x compares to v1.7.3 that was used in the article (which BTW will become one year old tomorrow - happy Birthday!)

Author here. I am excited to announce my Go course for devs who have little or no knowledge of Go and want to learn the complete language from scratch.

Happy to answer any questions. (But expect delays, it is end of day over here)

This may be an interesting article; however, I stopped reading when I discovered that it is about math/rand and not crypt/rand. Any PRNG that is not cryptographically secure must be flawed by definition (otherwise it would qualify as a crypto PRNG, right?) and should only be used for tasks where the quality of the randomness is only secondary.

> is that a valid hypothesis ?

No, unless you have some solid studies at hand that would clearly support your „hypothesis“, it is nothing more than a highly biased imputation.

Here is my antithesis: Elixir/Erlang doesn‘t sustain for a small mid-sized org in terms of building maintainable software. Elixir/Erlang requires more maintenance (higher learning curve -> much less clear code -> more bugs -> more developers needed).

Now does this sound like a valid hypothesis to you? Probably not, until I would be able to back my claim by solid numbers.

The readme might deserve some love. A one-liner is not that helpful... :)

> which makes it possible to change the path of project without worrying about GOPATH

Trying to ignore GOPATH, or trying to work around the requirements of GOPATH, often calls for trouble.