7 ms·
It's always important to ask yourself what concepts you knew before you learned a new technology X. For someone who knows C++ and Java there are no new concepts
by kubb 4y ago
It's always important to ask yourself what concepts you knew before you learned a new technology X. For someone who knows C++ and Java there are no new concepts in Go, so the tour of Go should suffice.
For someone who doesn't know what a function, a pointer, and a string is, there's more work to be done.
One of the reasons Go is praised for simplicity is that it only requires us to know basic concepts. You already know how to call a function and store some integers in a struct. All you need is to get used to the new syntax.
For those who like to flex their brains and learn to think in new ways, this could be a disadvantage, but for someone overwhelmed with information it's a godsend.
On the other hand, if you always limit yourself to Go then it will be harder to pick up other technologies that take advantage of concepts not featured there.
- thejammahimself 4y agoI feel like a significant part of learning a new language is also learning the standard library alongside the new syntax. Especially because these can be quite different between different languages.
- kubb 4y agoWhat do you think about rosetta code, et al? For me they reduce the standard library issue quite a bit, combined with googling "how to do x in y".
- mxuribe 4y ago> I feel like a significant part of learning a new language is also learning the standard library alongside the new syntax... OMG, you are so right! I feel the same. Knowing what the standard libraries bring (or don't bring) for each language that one learsn is immensely helpful. Sometimes this helps me decide which language to use for particular use-case/project, or sometimes it helps me better understand what the level of effort will be for a project if i use langugae X vs language Y, and on and on, etc. I feel like a tour of each language's standard libraries is a must when learning a new language; or at least a cusrosry review of the most important and/.or most often used functions, etc. of said standard libs.
- nerdponx 4y agoNot just the standard library, but also its idioms and the tools that people commonly use to work with the language (compiler, build tool, etc).
- Groxx 4y agoYeah. Particularly after having learned 2 or 3 languages, learning the N+1th language is often the work of like an hour or three. Learning the standard library, and the patterns it has encouraged in the community, takes years and is a moving target. Even a basic (accurate) "feel" for things generally takes weeks, regardless of how "simple" the language is. You might be able to produce code prior to that, but being able to predict where something should be, or how to find it, takes time.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- Xeoncross 4y agoWhile I agree there aren't really any new concepts, I can think of two areas in Go that C++ and Java don't really prepare you for: error handling / nesting and classes. Go doesn't use exceptions or classes for anything really. Instead it's all DI/object embedding + interfaces and nested error values + context which can be more of a mind hurdle than expected since inheritance and try/catch are so common these days.
- latchkey 4y agoAs an old Java head, I found FX [1] to fill a missing DI gap for me. Some can argue that it isn't really needed in go, and I tend to agree, but after using it in a few large projects, I find that it encourages a good separation of concerns that enables things to be easier tested as well as prevents cyclical imports. [1] https://github.com/uber-go/fx https://github.com/uber-go/fx
- arwineap 4y agoI've found that fx is very popular with java devs Can you help me understand what this style of dependency injection solves for in java? I use packages to encourage separation of concerns
- latchkey 4y agoIf you start to write pkg.NewFoo() inside of functions, you get into a whole object dependency mess that makes testing really really difficult. Having something that encourages you to pass in constructed objects (ala: DI), in the constructor, it ends up being much easier because you can more easily mock objects as necessary. Obviously, you can use that same pattern on your own without fx, but going all in on fx really kind of forces you to do it. Bonus fx points for being able to start/stop services as well. However, this tends to factor more into single binary apps (which is what I've built), more than say restful web endpoints (also built, but don't use this feature of fx as much).
- randomdata 4y ago
- pram 4y agoThe hard part about learning new languages for me is purging all the old information I have. For example, Perl sigils messed me up for a long time because other languages don't prefix variables and stuff with a symbol. It felt so wrong!
- rad_gruchalski 4y agoPHP does. Not the the extent of Perl, but it does.
- Keyframe 4y agoMEL does as well. Tcl too (sometimes).
- ryanschneider 4y agoThe first time I returned the address of a local variable from a function and it _wasn’t_ a footgun was eye opening. Then digging into why that actually worked and understanding how go does escape analysis gave me more respect for the language and it’s compiler.
- eikenberry 4y ago> [..] there are no new concepts in Go [..] Except for native support for CSP and that programs should be written in a CSP style. Learning Go and skipping CSP is not learning Go.
- morelisp 4y ago> Learning Go and skipping CSP is not learning Go. Learning Go seems to be inevitably "learning CSP", using way too much "CSP", then eventually coming to your senses and going back to atomic types and locks for probably 70% of cases.
- eikenberry 4y agoThinking CSP is something you can replace with atomic types and locks is a common misconception. Goroutines and channels are the primitives used by CSP, but just using them is not CSP. CSP is a whole program design system that can use all the concurrency primitives. There is no conflict between the using CSP and locks/atomic types. They work well together as they have different uses. The misconception is pretty widespread and cancerous to the community. Ignoring CSP is ignoring Go's best feature for writing better code. It takes some time to learn to do well (I'm still working on it) as it is a different paradigm than most people are used to, but it is well worth the effort IMO.
- eweise 4y agoTrying to find something I agree with in this post. I programmed in Java for decades and found that there were plenty of new concepts to learn in Go. Not sure asking myself what concepts I knew would help me in learning Go, especially since I know the concepts, I don't need to ask myself whether I know them. Some concepts not in Java - Pointers. These take a while to understand and use effectively. https://www.timr.co/go-interfaces-the-tricky-parts https://www.timr.co/go-interfaces-the-tricky-parts - Error handling. Very different than exceptions - Interfaces. Not quite the same as Java's and used differently in some cases - Channels. Java doesn't have these - Context. passing these around everywhere instead of just sticking on a threadlocal. Go will flex your brain plenty since you have to unlearn what you thought were good programming practices such as only one return statement per method.
- icemanx 4y agoSo a Java and C++ Developer will know what a TEE channel is?
- tylerhou 4y agoA big new concept in Go is that methods can have value receivers or pointer receivers. In C++ and Java, there is no distinction. Plus, method calls automatically deref pointers. I think it took me a day to realize this when my code wasn't compiling. That, and goroutines + channels (especially blocking behavior).