....in Go?
2,023 karma · joined September 12, 2012
[ my public key: https://keybase.io/natefinch; my proof: https://keybase.io/natefinch/sigs/4vluNroUMrNptUZ0-yf__o_BjbNO7CcrsudVWRG5Xc0 ]
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.
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.
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.
names = append(names, "Bob")
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.
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.
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.
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.
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.
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.
foo: 80:80
bar: 22:22
baz: 22.22
I rest my case about both readability and writability.
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.
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.