NateDad

....in Go?

Man you Go haters LOOOVE to trot out that quote from 2014.

But you know what, go is easy to learn, and that's been awesome in my experience. I can (and have) hired people who have never written go, and they're productive in a week or two.

Oh, oops, yeah, I misread "some" as "same". Denoting what contract they obey is just the name, isn't it? T1 and T2 are names of contracts.

I guess what you can't do by just using the contract name is say that two arguments must be of the same type. Nevermind.

They'd both be T1 in that case. T1 T2 means they're different contracts.

not if each one can fail. What if call #1 and call #3 can return the same error.. how does the caller know which one failed? This is the same as wrapping a bunch of calls with a catch (Exception) ... you lose context of what failed and can't behave differently for different failures. All you can do is perform a generic "something went wrong" behavior.

A simple text search will find it every time. Since Go code should always be formatted, it's pretty trivial to search for `type HTTPServer` or `func NewServer(` ... even over fairly large codebases this will give few enough hits that you can just search everything most of the time.

This is just not true. 2.5 years ago when I was looking for a remote-only go job, I had so many positions to look at, I had to put them in a spreadsheet. None of them were in silicon valley .

Many many places are using go here and there. From start ups to big enterprises.

It's rarely all they do, but it's pretty common to have some backend in go.

I worked on a million line go codebase for 3.5 years. It was readable and consistent and actually quite nice.

    names = append(names, "Bob")

C# has the feature-bloat of C++, except with a garbage collector. (I wrote C# for 9 years and even when writing it 40 hours a week, I still had trouble keeping up with all the features that continually came out)

I wrote a generic version of cog that can use any language as the generator code. It's called gocog, because it's written in go, but once compiled, it's a static binary, and you don't need go on the host machine.

https://github.com/natefinch/gocog

It's directly built off of cog's ideas and mimics much of cog's interface. (I worked with Ned, cog's author back in the day, and really enjoyed having cog to write boilerplate for me).

gocog is some of the first code I wrote in Go, so it's not super pretty code, but it's a very useful little tool for generating boilerplate.

I think the author understands exactly what they're talking about, and they're not talking about being employee #1-3.

Most people, when they hear "work at a startup", they're talking about being employee #10-30. Not 1-3. There are, clearly, 1/10th as many of the latter, and they're almost all looking for much more skilled people than employees #10-30. I figure this advice is for people who are newer in their careers. People with 10+ years experience probably already know what the article says, and they're likely the only ones who might get hired as employee #1-3.

If you care, you can't realistically forget. There are linters that will find your missed error checks.

Gah, my eyes! Why is the font so huge? And why doesn't zoom change it? I have to like step 5' back from my screen to read it....

Otherwise...

I have been writing Go for about 6 years... errors make so much sense to me. Why have some external codepath for "file not found"? Why is that different than "name == bob"? They're just data that is in one state or another. You check for them the same way, with an if statement. There's nothing magical.

Getting the wrong password in your password manager happens occasionally. Usually from password resets that somehow don't make it into your password manager. The fact that HN allows accounts without email addresses is the real problem. Also, maybe he just doesn't value his HN account all that much.

It's like your own personal google drive / dropbox / git repo

It's a content addressable storage system. There's plugins to import or export from various major services like foursquare, twitter, etc. and plugins let you store stuff in S3 or mongo or google cloud storage, etc.

Not sure if you're talking to me. I was saying that NullReferenceExceptions happen a lot more in C# than nil pointer panics in Go.

Yes, which is not error handling. Exceptions automatically handle error propagation, which is not the hard part of dealing with errors.

Your compiler can't handle errors for you. Error propagation is not error handling.

It's common in parsers. JSON parsing can panic (IIRC), as does the go template parsing code. Would they still write it that way today? I don't know.

Sure, and then you have no idea what was executed and what failed. Did you run 9 functions or 1? What do you need to roll back? How do you handle the error?

This is the problem with exceptions. They make it too easy to be lazy with your error handling.... Most of the time it's just catch and log, because the code itself has no way of knowing what failed and what succeeded. This is how you get your program in a bad state.... Because maybe you uploaded the file but didn't set the metadata in the API, because the connection broke between those steps.

With go's error handling it forces you to think about "what happens if the code fails here". Its always obvious what code had been executed and what has not.

To get that behavior in exception oriented languages, you'd have to wrap every call in try/catch, which ends up just as verbose as go, if not worse.

Yes, if you use panics for control flow in your package, you need to recover from them and hide that fact from your API. That is not the same as saying that you should recover from any panics that happen inside your library. Unexpected panics basically always indicate a programmer error.

My 7 years of C++ and 7 yesterday of C# and 5 years of go agree with you. Many more nil pointer exceptions in the former and almost none in the later in similar size (large) codebases.

Mage was born of my frustration with people using Makefiles to build Go projects. Makefiles are not cross platform compatible (good luck running them on Windows without jumping through some hoops), they have significant whitespace, they are generally written in bash, with added idiosyncratic syntax on top of an already idiosyncratic syntax...

So I made Mage. Mage tries to take the best parts of Makefiles (dependency trees, ease of execution, partially self-documenting code) and rework it to run with a better programming language (go).

It's still a work in progress, but I think it's in a very good initial state. It lets you declare targets and dependencies and it'll resolve the dependnecies into a tree that'll run them from leaf to root in parallel, all executing exactly once.

It doesn't have file targets yet, but that is on the docket, along with helpers to make writing code that executes commands in go less ugly.

Let me know what you think.

Toml is far superior for hand editing. This is why yaml is terrible (aside from significant white space):

    foo: 80:80
    bar: 22:22
    baz: 22.22

I rest my case about both readability and writability.

Yaml is terrible. The fact that there are so many optional and different ways to format things and the fact that it has significant white space means it's horrible to hand edit. I'd much rather hand edit json. At least it won't care if I accidentally use a tab instead of two spaces.

But of course toml is superior to both because it has comments and no significant white space and the comma at the end of lists is optional.

Meaningful whitespace is horrid. I speak from 3.5 years of working on s project that exclusively used yaml as configuration. Yaml is horrid.

Toml is way better. Yes, multilayered objects in toml are ugly. Don't make your users created multilayered objects for their configuration. That's just a bad UX regardless of the language.

We use gin. It's mostly fine. If I were starting a new application, I'd probably use stdlib by itself.

we use https://github.com/jackc/tern for migrations. It's pretty nice.

Generics don't solve immutability.