5 ms·

I do a little hobby work in Go. I looked at micro several times. For some reason I felt it is bit too heavy or unnecessary complexity. It does not feel fit in g

by mrath 6y ago

I do a little hobby work in Go. I looked at micro several times. For some reason I felt it is bit too heavy or unnecessary complexity. It does not feel fit in go ecosystem. But may be a lot of people are liking it. I could be wrong because I have not done much real work in Go. Does anyone use it for production apps?

asim 6y ago
I think the Go community in its early years advocated for libraries over frameworks. 1. Because of the very powerful standard library which dictated the development model and culture of the community. 2. Because Go was still such a young project. I think its only natural over time that frameworks and tools emerge to simplify the development experience in every language. We realistically cannot ask people to piece together complex systems in that way. If you imagine the thing you will end up writing in 200-300 lines of code in your main function, we're just encapsulating in a single function for you. The thing most companies end up building, a common shared library is by any other name a framework and so we're just piecing together that common experience for everyone else. Now the key thing to note is you can use any of these packages independently. In fact you can think of Go Micro as a standard library for distributed systems development. Its just that at the top level we import the common features and create the construct of a "Service" and give you one way to initialise it with `micro.NewService`. But the great thing is you have the freedom of choice to use things like go-kit, go-cloud, or any of the other thousands of tools in the ecosystem :)
- atmosx 6y ago
  The “powerful standard library” to my experience is a myth that holds no water. Even trivial projects use external packages to handle trivial things like an HTTP server or logging. No project I saw, however small, uses just the standard library.
  - frou_dh 6y ago
    Well objective data on this is out there if anyone can be bothered trawling through it: https://github.com/search?o=asc&p=4&q=language%3Ago&s=stars&type=Repositories https://github.com/search?o=asc&p=4&q=language%3Ago&s=stars&...
    - atmosx 6y ago
      I don't see any useful info there, do you mind translating that for me as it would be interesting to know what % of golang projects uses only the stdlib.
  - lowmagnet 6y ago
    I've written several services in my line of work where I was able to stick completely within the standard libraries. Half of my personal go projects likewise use the stdlib only. One of the projects that doesn't conform could do with a little coaxing, I only use afero for test convenience of creating a virtual fs. I'm likely to remove it in a future update.
  - bad_op3rator 6y ago
    It's always a good idea to end up with fewer dependencies
  - jen20 6y ago
    I've written dozens of Go programs which use only the standard library - including very large ones. However, there are two primary areas where it is deficient (necessitating pulling additional packages) to my mind: - Logging - a lack of ability to do structured logging is the main downside here. - The `syscall` replacements - almost inevitably for larger projects it's necessary to pull in the x/sys/unix or x/sys/windows since package `syscall` was frozen. The lack of "wrapped" errors also used to be an issue, but this has mostly been resolved with the new "%w" formatting directive to `fmt.Errorf`.
    - atmosx 6y ago
      I'm not saying that it is not possible I'm saying that it's not happening to the extend that would make that argument true. If 10% of the golang projects were based on stdlib, then I'd buy that argument, but I expect that number for be a lot smaller.
- bad_op3rator 6y ago
  Go is already an intentionally simple language with an excellent standard library, and dictates how to do things in the right way. Do we really need something on top of it? Not to mention, it's quite common that engineers like to reinvent the wheel, at least a little bit. It's just part of the fun, no one can blame them for that)
  - asim 6y ago
    With all due respect I think thats a bit of a short sighted statement. To say a language offers enough is to negate all of the tools built on top which others have leveraged to build other pieces of software. If you imagine all the things you import are they purely the standard library? Very unlikely. In the same way, Go Micro is built on not just Go but many other libraries. I think if you find value in using the pure standard library, good for you and I commend you on the effort of the not invented here syndrome. But for the rest of us it is much easier when someone else helps us out by laying the foundations for the next thing.
    - bad_op3rator 6y ago
      Jeez... with all due respect, not sure it's a great idea to cover yourself with "the rest of us"... but back to the idea of frameworks that make life easier. One of the problems with frameworks is that sooner or later, you start hacking them, breaking the ideas behind them, and make your life complicated. So it's better to think twice before start using any framework. BTW Why do you call it a framework?
atmosx 6y ago
Yes. Many open source application fairly complex & large are written in Golang: kubernetes, terraform, istio, etc. All these run in countless production systems.
- mrath 6y ago
  Sorry I intend to say, does anyone use micro in production?
  - asim 6y ago
    Production users of Micro! https://dev.micro.mu/users https://dev.micro.mu/users
    - literallycancer 6y ago
      You probably want to present this list somewhere on the landing page.

by mrath 6y ago

asim 6y ago

I think the Go community in its early years advocated for libraries over frameworks. 1. Because of the very powerful standard library which dictated the development model and culture of the community. 2. Because Go was still such a young project. I think its only natural over time that frameworks and tools emerge to simplify the development experience in every language. We realistically cannot ask people to piece together complex systems in that way. If you imagine the thing you will end up writing in 200-300 lines of code in your main function, we're just encapsulating in a single function for you. The thing most companies end up building, a common shared library is by any other name a framework and so we're just piecing together that common experience for everyone else. Now the key thing to note is you can use any of these packages independently. In fact you can think of Go Micro as a standard library for distributed systems development. Its just that at the top level we import the common features and create the construct of a "Service" and give you one way to initialise it with `micro.NewService`. But the great thing is you have the freedom of choice to use things like go-kit, go-cloud, or any of the other thousands of tools in the ecosystem :)

atmosx 6y ago
The “powerful standard library” to my experience is a myth that holds no water. Even trivial projects use external packages to handle trivial things like an HTTP server or logging. No project I saw, however small, uses just the standard library.
- frou_dh 6y ago
  Well objective data on this is out there if anyone can be bothered trawling through it: https://github.com/search?o=asc&p=4&q=language%3Ago&s=stars&type=Repositories https://github.com/search?o=asc&p=4&q=language%3Ago&s=stars&...
  - atmosx 6y ago
    I don't see any useful info there, do you mind translating that for me as it would be interesting to know what % of golang projects uses only the stdlib.
- lowmagnet 6y ago
  I've written several services in my line of work where I was able to stick completely within the standard libraries. Half of my personal go projects likewise use the stdlib only. One of the projects that doesn't conform could do with a little coaxing, I only use afero for test convenience of creating a virtual fs. I'm likely to remove it in a future update.
- bad_op3rator 6y ago
  It's always a good idea to end up with fewer dependencies
- jen20 6y ago
  I've written dozens of Go programs which use only the standard library - including very large ones. However, there are two primary areas where it is deficient (necessitating pulling additional packages) to my mind: - Logging - a lack of ability to do structured logging is the main downside here. - The `syscall` replacements - almost inevitably for larger projects it's necessary to pull in the x/sys/unix or x/sys/windows since package `syscall` was frozen. The lack of "wrapped" errors also used to be an issue, but this has mostly been resolved with the new "%w" formatting directive to `fmt.Errorf`.
  - atmosx 6y ago
    I'm not saying that it is not possible I'm saying that it's not happening to the extend that would make that argument true. If 10% of the golang projects were based on stdlib, then I'd buy that argument, but I expect that number for be a lot smaller.
bad_op3rator 6y ago
Go is already an intentionally simple language with an excellent standard library, and dictates how to do things in the right way. Do we really need something on top of it? Not to mention, it's quite common that engineers like to reinvent the wheel, at least a little bit. It's just part of the fun, no one can blame them for that)
- asim 6y ago
  With all due respect I think thats a bit of a short sighted statement. To say a language offers enough is to negate all of the tools built on top which others have leveraged to build other pieces of software. If you imagine all the things you import are they purely the standard library? Very unlikely. In the same way, Go Micro is built on not just Go but many other libraries. I think if you find value in using the pure standard library, good for you and I commend you on the effort of the not invented here syndrome. But for the rest of us it is much easier when someone else helps us out by laying the foundations for the next thing.
  - bad_op3rator 6y ago
    Jeez... with all due respect, not sure it's a great idea to cover yourself with "the rest of us"... but back to the idea of frameworks that make life easier. One of the problems with frameworks is that sooner or later, you start hacking them, breaking the ideas behind them, and make your life complicated. So it's better to think twice before start using any framework. BTW Why do you call it a framework?

atmosx 6y ago

Yes. Many open source application fairly complex & large are written in Golang: kubernetes, terraform, istio, etc. All these run in countless production systems.

mrath 6y ago
Sorry I intend to say, does anyone use micro in production?
- asim 6y ago
  Production users of Micro! https://dev.micro.mu/users https://dev.micro.mu/users
  - literallycancer 6y ago
    You probably want to present this list somewhere on the landing page.