4 ms·
The appeal of go is that it is easy to learn, you can put any young person just out of college and have it produces a lot of line of code that resemble somethin
by siscia 4y ago
The appeal of go is that it is easy to learn, you can put any young person just out of college and have it produces a lot of line of code that resemble something working.
The reality is that go is a very hard language to master and to avoid footgun. But it is an hard truth that few people are willing to accept.
- ainar-g 4y agoCan you provide examples of the things that are hard to master and the footguns?
- siscia 4y agoGoroutine, pointers vs value, cancelling work in goroutines, avoid dead locks. What makes go powerful also make it weak. In general the complexity need to live somewhere and in go it can only be the code itself as the language is too simple.
- ainar-g 4y agoThe difference between pointers/references and values is there in most languages in the same ilk as Go, maybe with the exception of Java. (C# has structs, which are value types.) It's a concept pretty much any developer in that area must know. As for concurrency, that topic is hard in pretty much any mainstream language. Maybe with the exception of Rust, but Rust isn't exactly a langauge that is not “hard to master”, and even Rust doesn't protect you from all forms of concurrency issues. Merely most of them, heh.
- BreakfastB0b 4y agoConcurrency is a major stumbling block https://eng.uber.com/data-race-patterns-in-go/ https://eng.uber.com/data-race-patterns-in-go/. Mutexs, conditional variable subtleties, wait groups, null pointer propagation, partial struct initialisations, channel lifetime coordination. tl;dr shared memory concurrency is hard. The introduction of generics should make it easier to wrap these lower level concurrency primitives into higher level safe constructs without needing code generation or runtime type casting via interface{}. Most devs also struggle to structure go programs in a way that makes them easily testable, but that’s true in a lot of languages.
- ainar-g 4y agoConcurrency is hard generally, so I agree with that. > The introduction of generics should make it easier to wrap these lower level concurrency primitives into higher level safe constructs without needing code generation or runtime type casting via interface{}. That process has actually already begun with Go 1.19's sync/atomic.Pointer[T]. See https://pkg.go.dev/sync/atomic@master#Pointer https://pkg.go.dev/sync/atomic@master#Pointer. Things like easier non-blocking send and receive or easier fan-in and fan-out channels should probably follow suit.
- morelisp 4y ago> Most devs also struggle to structure go programs in a way that makes them easily testable, but that’s true in a lot of languages. My experience especially relative to Java is the opposite - between httptest and sqlmock and the ease of setting up listeners in a separate goroutine, it's easy even for new Go developers to create new, realistic request-to-response functional (behavioral / Detroit-style / whatever they're called today) tests. On the other hand, getting our long-time Java devs to hook up a reasonable wiremock test is like pulling teeth. They much prefer piles of redundant unit tests with a few Spring-injected "integration tests" against H2 and an in-process gRPC "endpoint" or whatever, that of course therefore aren't testing much integration at all.
- kaba0 4y agoThis recent thread: https://news.ycombinator.com/item?id=31698503 https://news.ycombinator.com/item?id=31698503