On Mon, Dec 3, 2018 at 4:25 PM Robert Engels <reng...@ix.netcom.com> wrote: > > Btw, I am working on some issues/proposals/tools that I think will help the > situation - not just complaining.
I'd like to hear more about what you're planning to do. > > > On Dec 3, 2018, at 5:19 PM, Robert Engels <reng...@ix.netcom.com> wrote: > > > > 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 We just released a set of customer-facing web services, implemented in go. It was much faster to get to X compared to other such projects I was involved with before when I did the same thing in Java. And we did this with a team of developers with backgrounds in Java and Ruby. I believe Go is a very good replacement for other enterprise-y languages with much lower overhead. That doesn't mean it can't be improved, but I think it is already a significant improvement. . > > > > 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. That is difficult regardless of the language. > > > > 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. > -- 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.
