Probably another thread unto itself, and some of the issues have already been corrected like the addition of modules.
One of the biggest is dynamic code changes at runtime, while debugging, a lot of web apis, etc. Often there’s a lot of steps to get to X in an enterprise app. It’s a much slower cycle. Another is probably the debugging itself. Even the smallest app that uses gRPC as an example creates dozens of Go routines, and these routines are “named” only by their top level stack method, it’s a nightmare debugging a highly concurrent app. There’s a lot more, but I really don’t want to stir the hornets nest at this point, the community has exhausted me a bit... > On Dec 3, 2018, at 3:46 PM, Burak Serdar <bser...@ieee.org> wrote: > >> On Sun, Dec 2, 2018 at 11:09 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> I agree that is an important consideration, but it seems less important if >> the packages are small and focused. >> >> I think an important point to consider is that there are systems apps, and >> enterprise apps. These rules seem well suited to systems apps, but maybe not >> so well suited to business enterprise apps. >> >> As I become more familiar with Go I become more convinced that is great for >> systems apps, and not very workable for business apps. I’m trying to work on >> some things that might change the latter, but to get there I’m trying to >> fully understand the thinking behind these design decisions. > > Can you elaborate on this a bit? Why do you think the two are different? > > I've been using Go to write "enterprise" apps for a while, and the > process has been much easier than it used to be with Java. This was > something we accepted from the get-go without much questioning, it is > mildly irritating to some, but not a big deal. What mattered was the > amount of boilerplate code, readability, learning curve, clarity of > code, etc. > >> >>>> On Dec 2, 2018, at 10:56 PM, Ian Lance Taylor <i...@golang.org> wrote: >>>> >>>> On Sat, Dec 1, 2018 at 7:25 PM Robert Engels <reng...@ix.netcom.com> wrote: >>>> >>>> The way to fix it though it just to use dot imports, and encourage it! The >>>> only time dot imports don’t work is when there isn’t package stutter. >>>> Seems like a no brainer and you get the best of both worlds. >>> >>> Go programs that do not use dot imports have the convenient feature >>> that any unqualified name must be defined somewhere in the same >>> package. The first component of any qualified name must be either >>> defined in the same package or be the name of a package imported in >>> the same file. These convenient facts make it easier to read Go code >>> and quickly understand where each name is coming from. >>> >>> Ian >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
