Show HN: We wrote a book about building business applications in Go

Re:Show HN: We wrote a book about building business applicat... by konart on Thursday May 13, 2021 @12:34PM (#27144175)

>It puts a lot of pressure on the IDE to search the entire code base, and you end up with types you don't even care about. It clearly shows that the golang authors did not have IDEs in mind when writing the language, which is just absurd as it's supposedly a language designed for "programming in the large". Anyone who used "goland" knows what I'm talking about. Try refactoring a type, and have the IDE scan the entire code base to look for comment strings, which it has to because golang has no notion of doc strings like Java or C#.

Even if this was the case years ago - it is not now with an LSP.

[ Parent | on HN ]

Re:Show HN: We wrote a book about building business applicat... by gher-shyu3i on Thursday May 13, 2021 @03:15PM (#27146124)

It still is, it's inherent to the way interfaces are designed. Did you use golang on a monorepo for example?

[ Parent | on HN ]

Re:Show HN: We wrote a book about building business applicat... by konart on Thursday May 13, 2021 @04:55PM (#27147330)

>Did you use golang on a monorepo for example?

No. I have met monorepo on my path only once (not a golang one, it was mix of java and jruby) and I hope I will never see one again.

[ Parent | on HN ]

Re:Show HN: We wrote a book about building business applicat... by gher-shyu3i on Thursday May 13, 2021 @06:08PM (#27148100)

golang fails miserably in a monorepo setting, which is ironic because it was designed at Google, and Google are known for their monorepo.

[ Parent | on HN ]

Re:Show HN: We wrote a book about building business applicat... by konart on Friday May 14, 2021 @01:09AM (#27150929)

>which is ironic because it was designed at Google, and Google are known for their monorepo.

Google is huge. I'm fairly sure they use different approaches to code organisation in different teams\departments.

Anyhow - I'd rather thank them for that. Now chances I'll have to deal with monorepo are lower. I'm going to think of this as a feature, not a bug, lol.

[ Parent | on HN ]

Re:Show HN: We wrote a book about building business applicat... by eaa on Friday May 14, 2021 @05:58AM (#27152577)

May I ask, what do you mean and why do you say so? What is wrong with golang in monorepos?

[ Parent | on HN ]

Re:Show HN: We wrote a book about building business applicat... by gher-shyu3i on Friday May 14, 2021 @07:40AM (#27153142)

Because interfaces are nominally typed, it's very simple to accidentally implement interfaces that are defined in other parts of the code base, even though they are not related to your project. This makes searching for implementors of a given interface in a project show implementors you don't care about, which makes navigation and discoverability very tedious.

Furthermore, golang does not have a proper format for docstrings like Java or C#. When refactoring, the IDE tries to be smart and parse all comment strings as they are doc strings, and when you want to rename a struct, you're going to get a huge dialog with so many entries which can be false positives, and you have to go through them manually to check whether or not they apply. Same as with the interface issue, similar struct names may appear all across the code base which makes this refactoring very tedious.

There are other issues of course, like the fact that golang has no constructors, and structs are defined adhoc, meaning adding a new field to it needs more hunting across the code base to make sure you don't miss defining and break something.

[ Parent | on HN ]