Both, really. Go's so small you can be quite proficient with in months. While it's not as productive as, say, Python (wrt how quickly you can get your code up and running) it's much quicker than other languages (and nicer to use in the long run).
I can see that an experienced Go developer would be more productive than an experienced C developer. But, based on my experience of writing Go, i can't see how they could be more productive an experienced developer in any other current mainstream(ish) language - by which i suppose i mean Python, Ruby, Java, Scala, Kotlin, and (modern) C++. Go's great strength is how fast it is to get up to speed with, not how productive it is once you are.
Some languages have a lot of mental overhead (JavaScript being an easy example), which I don't think matters how seasoned you are - I think it's pretty much a constant in that language. So even if you're a seasoned developer, I think it's very possible that there are other languages which are objectively more productive for seasoned developers.
So, which languages Go is more productive than is not something I can say - but I think it's a quantifiable thing. There is a nice middle ground between rigid safety of something like Rust, and careless abandon of some extremely dynamic languages. Go has a nice middle ground, but whether it's the "perfect" spot I'm not sure. Hell, I'm not even willing to say it's objectively more productive than X languages.
I will say that for me, personally, it's far more productive than JavaScript (Node) or Python. I can whack out more code in Python, faster, but any moderately sized project starts to run into maintenance overhead, and then suddenly I wish I was in a more rigid language. Middleground is good here, I think.
Though, I will say that if a language like Python gets some nice typing tools like they're working on - especially behavior based typing like Go's interfaces, Rust's Traits, etc - I think that language could really shine for larger projects. Prototyping speed and maintainability is a big boon.
Style and maintainability still falls on the programmer, but Go code never "feels right" unless it's done neatly with as little magic as possible. I think that property is super beneficial in keeping a large and growing team/codebase effective and malleable enough.
Others mentioned overhead which is a big issue. Because Go is so simple the mental overhead of remembering how to do stuff, edge cases, etc. is much smaller than other languages. Sure, a Go dev and a Java dev can be just as productive in their respective languages. But as somebody who has to switch back and forth between Go, JS/TS, PHP, and Java Go is by far the easiest language to switch back to.
There is no shortcut where you can produce and distribute a binary so every damn user of your program will have to deal with Python versioning, installing dependencies etc.
So for the user, Python is not productive. It is time-consuming and bothersome.
Why is this such a huge benefit for code that typically works at the system level? Wouldn't you value reliability, consistency, etc when adapting system level functions over speed to deployment?
? Go is tiny. The tutorial takes an afternoon. A C programmer will be profecient within days.
This "hype" around go letting you be productive sooner is honestly just bullshit. I've been programming for 20 years, with C, C++, Ruby, Perl, Scheme, Haskell, Rust, Go, Java, and others I've surely forgot. Sure, I was able to start writing go within a day. But it was terrible go, and months later I was still dealing with the consequences of early bad decisions.
This isn't unique to go by any means. But if you go in thinking you're going to write a project that does some sort of non-trivial task and be able to rely on that later, you're going to have a bad time.
You refer to:
>best practices, idioms, and understanding the pitfalls around concurrency and channels, which are nowhere near as "batteries-included" as people would lead you to believe.
Could you summarize these?
You wrote:
>Sure, I was able to start writing go within a day
If you could send back in time a brief note to yourself to prevent
>months later I was still dealing with the consequences of early bad decisions.
then what would you write? You can include links that the "day 1" version of you should have followed, or simply warnings.
I would be highly interested in more information on the above, from you or anyone else here.
Thanks so much!
So it's 1 day of learning Go + 1 month of learning style vs 2 weeks of learning Rust + 1 month of learning style. [1]
[1] Note, I think that Rust has the best community when it comes to getting beginners up to par, whether in #rust-beginners or on /r/rust. It just is a hard and not forgiving language.
That is exactly my point, and I said as much in my post.
> So it's 1 day of learning Go + 1 month of learning style vs 2 weeks of learning Rust + 1 month of learning style.
More like 1 day vs. 1 week, with six months of ramp-up before you're writing anything approximating production-quality code. At which point, does it really matter that you were able to write garbage in one day rather than seven?
https://news.ycombinator.com/item?id=14934690
One way to get your correct answer is for me to propose a wrong or partial answer. How is this as a message to the past (i.e. I am guessing your answer to the above request):
WRONG/FAKE ANSWER:
"Note to past self: although you can write code that compiles on day 1 and day 2, before considering your code idiomatic and ready to build on top of (or even deploy to production), DO/LEARN THE FOLLOWING:
1) read and work through all of The Go Programming Language book. This teaches all idioms.
2) Practice and use Go's testing tools (built-in). Always use its reformat tool applied on every save from your IDE.
3) Begin using a better error and logging library than the built-in error passing idiom. Google this.
4) Use a debugger. Google this.
5) Security and versioning with go get is broken: Google this and learn vendoring with versions. Otherwise your code cannot go on production.
6) You control garbage collection frequency. Learn to set this. In emergencies disable it entirely to trade memory for latency to gain one or two milliseconds (approach hard realtime), for example when you are dropping requests. Then reenable when you can take the (very small) hit. Garbage collection is very efficient and low-latency.
7) Channels and concurrency (goroutines) do not work as described. Specifically:
- This link will solve your problems with channels: https://stackoverflow.com/questions/41200505/whats-the-best-...
Adopt it. Then they work as described.
For goroutines:
Follow this document - https://gist.github.com/pzurek/6642797
After incorporating the above specific changes, you are ready to commit to production and build on top of what you want to build.
"
is the above message completely wrong and bullshit? Then please correct it.
Your insight and experience are appreciated and I would love to read what you would write as a message to yourself in the past, to save those lost months. Thank you.
Sure, read books and blog posts. Test things. Learn debugging tools. But nothing really substitutes for actually working with a language. Having an experienced mentor helps, but only if they're advising you on why they chose a certain approach, or why a critiqued approach you chose was bad.
Remember: I didn't ask for a shortcut, I asked for specific sentences that you could have sent back in time to prevent this:
>months later I was still dealing with the consequences of early bad decisions.
Your sentences can be literally anything, specific to your specific situation, that could have prevented those bad decisions.
So, let's be clear. Your message to the past you reads:
"Hi - I am you from the future. I was asked to send back a message in time listing specific things you can do right now, having just learned Go, based on my having to deal with your code, that can prevent your bad decisions which you will be dealing with months later. It is impossible to put this into English words. So, I have no advice for you of any kind. Fuck you, past-me. And also fuck me - I'll just have to deal with your lack of understanding. I hope you have found this mentoring by me to be as helpful as I have. I don't believe in mentoring."
So, that's the new version of your message, based on your review of your own code and memory of your decisions and learning process at the time.
Well, okay. I guess I accept your viewpoint. (Note: if there's some other reason you don't want to answer publicly, such as not talking about your codebase, you can email me at the email in my profile.)
I am looking for specific architectural advice, using your experience as a case study.
Learning the keywords and basic Go syntax is simple, so in that sense days fits, but a C (or C++) programmer is probably also going to be writing unidiomatic Go code, falling back to unsafe too much, trying to recreate OOP with some kind of wonky self-rolled inheritance system, etc, for a few weeks before they really "get it".
Experience?
One does not get 'proficient' in a week in any given language. One can build up a program in a new language in a week, but that does not mean proficiency. It takes between many months and a few year to become proficient in a language: it is the outcome of a process of exploration, trials, mistakes, discoveries of better or more adapted ways, finding out the shortcomings an learning to work around them, picking a right balance between ease to write and ease to read, ease to write and performance...
So let's quantify what "proficient" means. How would you measure of someone is proficient in a programming language?
Hi! (I got a downvote but this is serious - I believe you!)
Thanks for this useful information. Could I ask you (or anyone else) to write maybe a checklist of links/resources or steps a programmer could go through?
Thank you again!
* tour.golang.org
* gobyexample.com
* The Go programming language book. (If you're a C programmer, one of the authors might be familiar to you)
Personally I got hooked when I saw a talk by Andrew Gerrand where he created a working chat server in about 30 lines of code. I'd recommend this after gobyexample just to get a taste of what's possible - https://talks.golang.org/2012/chat.slide
I hope you enjoy it :)