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... :)

Generics have their use cases, but in general they are overrated. Especially in (but not limited to) the DevOps area, I bet that 99% of the code needs no generics at all.

Having said that, I would not complain if the concept of Ply (https://github.com/lukechampine/ply) becomes part of standard Go.

> 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.

Go is a pragmatic language, designed for programmer productivity. I think Go was never meant to be used as a language for reasoning about models and concepts at various abstraction levels and for arbitrary problem domains. There are certainly other languages available that are better suited for this.

Argh! Forgot to include the "golang" keyword :)

Swift and Go aren't competitors. Different realms, different audiences.

This Reddit thread reveals why the algorithm works: https://www.reddit.com/r/golang/comments/5xrjh0/got_lucky_im...

You are absolutely right to ask about possible downsides of a language before deciding to make the switch.

However, there is a problem with your question: Define "not great".

Every programming language has - and lacks - specific features, and this can be either great or not great, depending on who you ask.

For example, Go has no OOP type hierarchies and hence no inheritance and no polymorphism in the OOP sense.

Ask two persons about their opinions on this, and one will answer, "What, no inheritence? Total crap!", and the other one says, "Wow, that's great! No more projects that have gone unreadable and unmaintainable due to blown type hierarchy trees." Both of them may be right - from their perspective.

It also depends greatly on what you plan to use the language for. Take generics as an example. If you work in the data sciences realm, you would want generic programming for your numeric libraries, or for generic data containers. So Go would not be the language for you. On the other hand, many would never need generics at all in the area they work, and many even love the absence of generics and other complicated language constructs because it's precisely this what keeps the language definition small and the compiler blazingly fast.

Bottom line - take a closer look at the language features - both the ones that exist and the ones that were left out - and decide for yourself if this this is what you need for your project.

I chose Go in 2011 as my favourite "personal" programming language, and I don't regret it. Finally, I have a language that is clear and easy to read, that has no "magic" features that you never really can completely explain how they work, that compiles insanely fast, that cross-compiles to other architectures, that needs no pre-installed VM (ever struggled with Java VM version incompatibilities?), that has first-class language support for concurrency, and so on and so forth. I know about the downsides but they never have been an issue for me.

IMHO the term "idiomatic" is overused. Every programming language has its idioms, and I am sure you'll learn them when working through Go tutorials, books, or courses.

Important here: Empty your teacup if you want to fill in new (different) tea. Try to understand the Go language without falling back to the idioms of other languages. Drop inheritance, generics, exceptions, dot-chaining of statements, and embrace interfaces, explicit error handling, and clear, readable, and maintainable code.

As one of the go proverbs says, "Clear is better than clever."

(All probverbs here: https://go-proverbs.github.io/)

If you want to contribute to the Go project itself, this article is a good start: https://blog.gopheracademy.com/advent-2016/contributing-to-t...

For all other Go projects, check the project documentation or ask the maintainer(s) if and how you can contribute. This should not be different from any other (i.e., non-Go) open source project.

Depends on the situation.

You could use a Go "project" that is in fact the $GOPATH, like so:

    |-- projects
          |-- project_0
          |-- project_1
          |-- project_2
          |-- go
               |-- src 
               |-- pkg 
               |-- bin
          |-- project_4
          |-- project_5

Your other projects would then not be affected at all.

Or consider using a tool like `gb` (https://github.com/constabulary/gb) that does not depend on $GOPATH. (But ensure to understand the caveats of this tool before switching to it.)