4 ms·
Just don't use the features you haven't yet learn. In a few years of experience you will reach a plateau of productivity in go that you'll only be able to beat
by The_rationalist 6y ago
Just don't use the features you haven't yet learn.
In a few years of experience you will reach a plateau of productivity in go that you'll only be able to beat by migrating toward a more featureful/better thought language
- throwaway894345 6y agoLike I said, I came to Go from C#, and my experience has been such that I’m generally more productive in Go. Further, I already addressed the fallacy that you can just avoid certain features.
- cmckn 6y agoVast majority of my experience is Java, but I'm in a C# role right now. I have to agree with you, having only used Go tangentially -- the tooling is more approachable and bootstrapping a project is more straightforward. I can go ;) from zero to _something_ in a much shorter time
- throwaway894345 6y agoThis is what drew me to Go circa 2012, and I’ve been pleased to find that Go’s value proposition doesn’t end after a short period of time but continues to pay dividends for individual developers and for the project as a whole over the long term.
- The_rationalist 6y agoIt would be interesting to say how much years of experience actively programming in C# you have.
- throwaway894345 6y ago5 years.
- The_rationalist 6y agoWow OK you're then an interesting data point that make me accept to begin doubting about the supremacy of C#/Kotlin over Go.
- throwaway894345 6y agoProductivity isn’t the only factor. C# and Kotlin are great languages in their own right. Notably for very dynamic workloads, the respective JIT compilers can do some impressive optimizations.
- zeroc8 6y agoEvery developer on the project then uses his favorite subset. Which may or may not be the same one you prefer and know. Unless of course you know everything ;)