4 ms·

Being currently involved in a startup using Go, I go back and forth with this in my mind on a regular basis. On one hand, development is much more arduous than

Being currently involved in a startup using Go, I go back and forth with this in my mind on a regular basis. On one hand, development is much more arduous than I have experienced on other projects with more featureful languages. During development, I really find myself missing what those languages have to offer. But on the other hand, when the day is done and I look at what has been created, I'm really impressed with the quality of the project. A good team can write good software in any language, but I do believe this language has helped this team write better software than they might have in another language. I suppose that, like everything, there are tradeoffs. I'm not not yet sure which tradeoffs are most important to me.

inlined 9y ago
I typically summarize it as "go takes twice as long to write and half as long to debug. Since you spend a lot more time debugging code than writing new code, this is a good trade-off"
- flavio81 9y ago
  No.
ngrilly 9y ago
What are you missing when programming in Go?
- majewsky 9y ago
  .map() .filter() Not having to write useless type casting boilerplate like this: https://github.com/majewsky/sqlproxy/blob/f5b297e7dce14c045323881f272b97a3fdfb74c3/driver.go#L260-L266 https://github.com/majewsky/sqlproxy/blob/f5b297e7dce14c0453... Not having to write `if err != nil { return nil, err }` every second line. (Or, in other words, Rust's question-mark operator.)
- randomdata 9y ago
  For me, an implicit way to convert between similar, but not identical, types. A real-world open source example I am aware of having a similar issue is Upspin[1]. There are ways to mitigate this, but you (well, I) cannot always control all the types third-party dependencies rely on. There is a clear path to working around this case, but I find it to be a bit tedious. I miss languages where, through generics, duck-typing, or similar that I can simply pass the application's structure to the third-party library and it "just works". [1] https://github.com/upspin/upspin/blob/master/upspin/proto/proto.go https://github.com/upspin/upspin/blob/master/upspin/proto/pr...

inlined 9y ago

I typically summarize it as "go takes twice as long to write and half as long to debug. Since you spend a lot more time debugging code than writing new code, this is a good trade-off"

flavio81 9y ago
No.

ngrilly 9y ago

What are you missing when programming in Go?

majewsky 9y ago
.map() .filter() Not having to write useless type casting boilerplate like this: https://github.com/majewsky/sqlproxy/blob/f5b297e7dce14c045323881f272b97a3fdfb74c3/driver.go#L260-L266 https://github.com/majewsky/sqlproxy/blob/f5b297e7dce14c0453... Not having to write `if err != nil { return nil, err }` every second line. (Or, in other words, Rust's question-mark operator.)
randomdata 9y ago
For me, an implicit way to convert between similar, but not identical, types. A real-world open source example I am aware of having a similar issue is Upspin[1]. There are ways to mitigate this, but you (well, I) cannot always control all the types third-party dependencies rely on. There is a clear path to working around this case, but I find it to be a bit tedious. I miss languages where, through generics, duck-typing, or similar that I can simply pass the application's structure to the third-party library and it "just works". [1] https://github.com/upspin/upspin/blob/master/upspin/proto/proto.go https://github.com/upspin/upspin/blob/master/upspin/proto/pr...