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.
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.
- Pointers. These take a while to understand and use effectively. 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.
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.
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.
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.
Passing context around is an interesting one too
No, go doesn't have exceptions. :D
To answer the sibling comment (I don't have enough karma to go deeper), Java NIO channels are barely usable. Using them is the quickest way to inject bugs into your code I've seen in Java.
Go channels are closer to blocking queues or a selection of concurrent queues depending on whether it's bounded or unbounded, or whether you use select, etc.
* returning an error code from functions in C and all the time writing "err = f(); if (err != 0) .."
* returning a potentially null reference from a method in Java and all the time writing "var ref = f(); if (ref != null) .."
Exceptions were supposed to save us from this drudgery in late 90s. They did if you ask me. Options are a nice alternative if FP is your cup of tea.
Can you help me understand what this style of dependency injection solves for in java?
I use packages to encourage separation of concerns
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).
Unless you are trying to add tests to legacy code, where you also wouldn't have much say in the use of fx, wouldn't the stated testing difficultly already force you away from that dependency mess?
struct Foo {
}
func (f *Foo) doSomething() {
client := pkg.NewClient()
client.doHttpRequest()
}
struct Foo {
client Client
}
func (f *Foo) doSomething() {
f.client.doHttpRequest()
}
func NewFoo(client Client) *Foo {
return &Foo{ client: client }
}
var FooModule = fx.Provide(NewFoo)
struct Bar {
foo *Foo
}
func NewBar(foo *Foo) *Bar {
return &Bar{foo: foo}
}
var BarModule = fx.Provide(NewBar)
fx kind of highly encourages the second approach for all of your code. It is a bit more boilerplate, but by default, I'm always going to be thinking about passing my dependencies around instead of just being lazy and doing NewClient in the function.
I also get to take advantage of the fact that Client is just magically passed into my constructor. If there is some error doing so (like I forget to Provide), then fx will give me errors at start up. My dependency chain is clear. It just feels nicer to me.
Once again, of course I can write it the second way without fx... but it is kind of nice that every time I want to use Foo, I don't have to type NewFoo() in a constructor... I just reference *Foo.
By the way, mockery [1] generates super easy to use mocks for exactly this workflow.
Absolutely. This is true in most, if not all, languages. But when you're in the driver's seat, able to make choices like whether or not to use fx, why would you bolt on testing after the fact?
Not much you can do about legacy code, if that's what you have to deal with, but when dealing with legacy code it is unlikely the authors used fx, so...
I think it took me a day to realize this when my code wasn't compiling.
That, and goroutines + channels (especially blocking behavior).
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.