9 ms·

Moving from PHP to Go and Microservices

50 points by mbanzi 12y ago

coldcode 12y ago
Go was interesting me to up to the point that I found out there is no real debugger, and little interest in making one. I find it hard to get excited about being unable to properly debug my code.
- ecaron 12y ago
  "little interest in making one" is a bit of a bold statement... Sure a lot of the early Go users thought/preached "gdb is good enough", but I don't feel that's the case anymore. For example, mailgun's https://github.com/mailgun/godebug https://github.com/mailgun/godebug looks very promising.
  - twakefield 12y ago
    jschlatter just wrote a great blog post about this: http://blog.mailgun.com/introducing-a-new-cross-platform-debugger-for-go/ http://blog.mailgun.com/introducing-a-new-cross-platform-deb...
- melling 12y ago
  Now there's a good interview question to determine if you're the type of person who gets things done. Plenty of code has been written without "real debuggers". A debugger can make things easier, but can you effectively work without one if needed?
  - anewhnaccount 12y ago
    Sometimes stepping through is faster than adding in trace temporarily. I say that as someone who almost always uses trace. This is a terrible interview question if "yes I use a debugger" is the wrong answer. What matters is if the person can get the job done, not if they'd do it the same way as you.
    - melling 12y ago
      There's nothing wrong with using a debugger. If you tell me you can't or won't solve a problem without a debugger, well ...
      - anon1385 12y ago
        You are shifting the goalposts. The original commenter just stated that they didn't feel enthusiastic about using a language without a debugger. Not that they couldn't solve a problem without a debugger. The type of argument you are making has been used throughout the history of computing as a reason to avoid using computers to solve problems. For literally any problem that is solvable by computers, you can make an argument about how using a computer to do it means you lose the ability to solve it by hand. From accounting to engineering to programming to administration to physics to writing, in all these areas (and more) older practitioners have bemoaned the use of computers to quickly and accurately solve problems that they have spent a lifetime mastering how to solve by hand. The reason for their opposition is pretty clear. I don't know why this type of attitude is so prevalent among some sections of the programmer community. Programmers are the people who should most of all appreciate the ability of computers to automate tedious and error prone tasks. Yet for a certain class of easily automatable programming problems there is a group of programmers who resist very strongly the use of computers to automate. Maybe it's just the same old issue of not wanting to admit that something they spent a long time mastering isn't very useful anymore and that they are getting outcompeted in the marketplace. I think there is a bit of unpleasant machismo about it as well though; the idea that you aren't a 'real' programmer unless you eschew a certain level of automation (be that high level languages or compilers or version control or automated build systems or syntax highlighting or tools to refactor code etc).
        melling 12y ago
        No, I didn't shift the goal post. I added an extra sentence to fix the "parse error". I use a Xcode debugger when it works, for example. However, I'm also able to effectively debug my code when Apple breaks it. I've been dropped in to debug JavaScript in IE7, for instance, and told that I couldn't install Chrome to debug it because it "wasn't a corporate standard". Someone who wants a complete ecosystem before they can be effective strikes me as a problem.
  - breakingcups 12y ago
    Plenty of cars have been made without a three-point seat-belt. I write plenty of Go in my time off but professionally I write C# in Visual Studio and the debugger is amazing. It's saved me thousands of hours cumulatively over the years. I like Go a lot, but lack of a proper debugger can definitely be seen as an argument against it by someone considering the language.
    - coldtea 12y ago
      >Plenty of cars have been made without a three-point seat-belt And? Who said it's that better? How many died or didn't die anyway?
    - kochthesecond 12y ago
      I mostly write java, and only very rarely use the debugger. If I need to verify or poke behaviour, I generally write a test to find out. Stack races and tests are usually enough.
- kid0m4n 12y ago
  https://github.com/derekparker/delve https://github.com/derekparker/delve There is a talk scheduled on this at GopherCon 2016. Make sure you have a look at it.
- aikah 12y ago
  Strange as I was just debugging my go code. http://postimg.org/image/prgj1qjzn/ http://postimg.org/image/prgj1qjzn/ Care to explain me how I'm debugging some la,guage that has no debugger?
  - linkregister 12y ago
    LiteIDE, which uses gdb in the background, isn't reliable. golang.org/doc/gdb: "although GDB can be useful in some situations, it is not a reliable debugger for Go programs, particularly heavily concurrent ones"
    - deleted 12y ago
      [deleted]
- grogenaut 12y ago
  There are some okay debugging options but I also agree with parent that debuggers are useful. Especially when learning a language and trying to tease out WTF is going on. When you don't understand the meta of the print statement especially. And you don't yet grok the testing framework.
- PopsiclePete 12y ago
  What I'm going to say won't make much sense at first, but I find I don't really need a debugger when writing Go. A log statement here and there combined with unit tests and the race detector get me through every time. I absolutely refuse to touch Java/C#/C++ without a debugger, but that's because they're a lot more "magical" - lots of layers, lots of magic, 'heavy' types. Go is a lot more explicit about what's going. It is more verbose, yes, but you also know how things work by just looking at them. I'd love a debugger for Go, sure, but I just don't need one.
prattbhatt 12y ago
Not sure if going forward with Angular.js was the right choice, given Angular 2.0 had been announced, and will be different from Angular 1.0 (no backwards compatibility)
- iends 12y ago
  FUD. There will be a clear migration path, including, it seems, the ability to run both 1.x and 2.x modules side by side using the new router from 1.4. This means you won't have to rewrite your 1.x modules immediately. 1.x also has a commitment from the Angular team to remain maintained for the foreseeable future.
count 12y ago
I'd love to hear how folks are actually deploying Golang for web apis - using Gorilla, net/http, etc?
- themartorana 12y ago
  We're using either Gin[0] or pure net/http with Julian Schmidt's HttpRouter[1]. Even Gin lives on top of net/http, and most serious routers/frameworks do. [0] https://github.com/gin-gonic/gin https://github.com/gin-gonic/gin [1] https://github.com/julienschmidt/httprouter https://github.com/julienschmidt/httprouter
- namidark 12y ago
  Upstart + net/http
- jaegerpicker 12y ago
  First one I deployed I used martini but now I'd just use the net/http lib and pull in a few gorilla libs as needed.
- steakejjs 12y ago
  Nginx and net/http has worked wonderfully for me. Nothing fancy is necessary.
- stilldavid 12y ago
  Like the others, net/http with gorilla packages pulled in as needed. Nginx for static files and a reverse proxy for go. Upstart, and that's about it!
- neillyons 12y ago
  I have multiple Go apps on my Linode server. I use nginx as a reverse proxy. Each Go app listens on a different port. I use supervisor to start/stop my Go programs. I also use it for log rotate and to autostart my programs on a system reboot.
- buro9 12y ago
  I've created a simple solution for a few projects I'm working on, it's a kind of REST service wrapper. Basically, I have a "service" package that offers: * mux routing * Negroni for middleware (with stats and auth middlewares delivered out of the box) * a centralised logger * Rendering of things to JSON * An idea of controllers (a controller is a web handler for a given route, handling all verbs) * An idea of handlers on those controllers (per verb... you basically just load in your GET or POST handlers here) * HEAD and OPTIONS for free (including automatic Allow headers) * Error handling returns JSON throughout, including 404s, etc * Basic filling of structs with POST'd/PUT'd JSON The thing is fairly primitive, and it's Go idiomatic and so doesn't provide a context for the middleware and handlers, but it just allows one to rapidly say "this struct, to this controller, on this route" and the rest is for free. This is just a starting ground though, a test of an idea. If I can package this better and have it be a little less hacky in nature I'll look to open-sourcing it. Right now it's really just testing the idea of taking all of the cross-cutting concerns and common issues and solving them via this service package I've made, with the goal of just letting us get on with writing the business logic. I want to expand it... with better description of errors, standard schemas for arrays being returned, auto-documentation of the endpoints (perhaps Swagger, but it seems awfully monolithic in nature), etc.
chrisdegroat 12y ago
"[Go] is impressively fast and soon we figured out that our bottleneck was not the language/framework neither the application, but our database" You re-wrote your entire REST API in a new language without first understanding where your performance issues were?
- therealwill 12y ago
  They also talk about switching DBs. In my experience it is rarely the database choice but bad schema and/or poor SQL queries.
  - BinaryIdiot 12y ago
    Yes these were my biggest problem with this post; they don't spend the time to try and find out bottlenecks and when they finally do instead of investigating the WHY they're thinking about simply switching to yet another which is going to have the same issues if they're not using an optimal data model, etc.
    - ceejayoz 12y ago
      This is unfortunately a very common problem-solving approach. I've seen devs upgrade jQuery because they're getting a 500 error from a PHP app. No relation to the problem - it's just flailing around in hopes something random works.
  - 0xdeadbeefbabe 12y ago
    NoSQL is a database choice now, a worse choice in my opinion. So, I'm not surprised they are considering Rethink and Mongo. What's funny is how much more exciting Arduino itself is, compared to all this.
    - Someone1234 12y ago
      > NoSQL is a database choice now, a worse choice in my opinion. If that's legitimately your opinion on that topic then I suggest you expand your knowledge. NoSQL databases aren't slot in replacement for SQL databases. However, for what they're good at they're REALLY good at it. Namely highly scalable, Document Storage (or "blobs"), and incredibly low latency reads. Keep in mind that NoSQL doesn't mean schemaless. You can have a schema and be NoSQL, and that is the direction most NoSQL databases are moving into (or have moved into).
PedroBatista 12y ago
Being 100% honest, the first thing it came to my mind after reading the title was "Why?". And now I still don't know why. Maybe I'm dead wrong but for me this is yet another case of pure tech fashionismo.
- Svip 12y ago
  My personal motivation for rewriting some of my old PHP projects (albeit hobby projects at best) to Go is A) willingness to maintain PHP (which is almost nil) and B) rewriting programs can help discover bugs and re-understanding your programs. But that's for small hobby projects, where the developer team is usually just me. For a large project, there should be some serious advantages to Go over PHP in their use cases. Don't get me wrong, I think Go is a better language to write websites in than PHP, but I am also a pragmatist.
  - EugeneOZ 12y ago
    There is a lot of reasons to choose Go over PHP for new project (static typing, better scaling because of smaller memory footprint of each request and so on). But for existing project all is not so simple. But after reading their post I understand it as they just got tired because of code mess, so rewrite was only way to clean things up. Only thing I don't understand is why they didn't remove PHP at all.
- ExpiredLink 12y ago
  HDD (Hype Driven Development)
butterfi 12y ago
As a developer, I appreciate having an interest in and using different technical combinations, but as a site maintainer I've been wrestling with how to accommodate different tech stacks with limited time and developer resources. It's lead me to start questioning the developers choice of tech vs. what the right tech choice for the organization. There's an assumption the developer will choose the right tech, but frequently the client has no idea how to access tech decisions and developers are left to pursue whatever they choose. There are use cases where a custom stack is appropriate and other cases where a an off-the-shelf solution (like WordPress, Django, Drupal, etc) has better options for long term support. I'm not saying this is the case at arduino.cc, but the blog post did trigger that reaction.
Zikes 12y ago
I love coding in Go, it's much more fun for me than PHP or node.js. According to half the comments here and on every other Go-related HN post that makes me a hipster, fashionista, hype-driven sheepdev. If this had been a post about Arduino.cc being unhappy about performance and refactoring their code in an attempt to improve that, nobody would be batting an eye. But since they decided to refactor with Go, suddenly everyone is asking "why?"
- BringTheTanks 12y ago
  Asking "why" is a sign of curiosity, a desire to gain insight from the experience of those who are, apparently, willing to share it with us. Using fashionable tech X is not bad on its own. But without the "why" we have no clue what the author's reasons for the given choices are, and how the end results align with the initial reasons. Lots of small businesses have driven themselves off a cliff basing their tech choices on what their employees would "enjoy" most. It's a good reason to code Go in your free time, but not to migrate a company's infrastructure to it. It's very strange to see that you wouldn't want to know "why". Maybe you're smarter than all of us.
  - Zikes 12y ago
    The "why" I'm seeing here is not the curious type, it's demanding justification. It's telling people they must explain themselves thoroughly, to defend their decision every single time they choose to use it. Go is sufficiently mature enough that those questions need not be asked any longer. Docker is built on it, Google's Vitess database sharding system (which powers YouTube, of all things) is built on it. Nobody is at risk of "driving themselves off a cliff" for choosing Go, provided they are proficient enough with it. I haven't seen any other language get as much hate as Go does on this site.
    - BringTheTanks 12y ago
      If I'm asked why I use the technologies I use in my projects, I'd gladly give specific engineering and business reasons, and not just say "YouTube uses it". We should be ready to have these technical discussions and encourage them, not be so strangely defensive about it as you seem to be.
alexbilbie 12y ago
Which IDEs have good Go support (code complete + debugging)?

50 points by mbanzi 12y ago

Go was interesting me to up to the point that I found out there is no real debugger, and little interest in making one. I find it hard to get excited about being unable to properly debug my code.

ecaron 12y ago
"little interest in making one" is a bit of a bold statement... Sure a lot of the early Go users thought/preached "gdb is good enough", but I don't feel that's the case anymore. For example, mailgun's https://github.com/mailgun/godebug https://github.com/mailgun/godebug looks very promising.
- twakefield 12y ago
  jschlatter just wrote a great blog post about this: http://blog.mailgun.com/introducing-a-new-cross-platform-debugger-for-go/ http://blog.mailgun.com/introducing-a-new-cross-platform-deb...
melling 12y ago
Now there's a good interview question to determine if you're the type of person who gets things done. Plenty of code has been written without "real debuggers". A debugger can make things easier, but can you effectively work without one if needed?
- anewhnaccount 12y ago
  Sometimes stepping through is faster than adding in trace temporarily. I say that as someone who almost always uses trace. This is a terrible interview question if "yes I use a debugger" is the wrong answer. What matters is if the person can get the job done, not if they'd do it the same way as you.
  - melling 12y ago
    There's nothing wrong with using a debugger. If you tell me you can't or won't solve a problem without a debugger, well ...
    - anon1385 12y ago
      You are shifting the goalposts. The original commenter just stated that they didn't feel enthusiastic about using a language without a debugger. Not that they couldn't solve a problem without a debugger. The type of argument you are making has been used throughout the history of computing as a reason to avoid using computers to solve problems. For literally any problem that is solvable by computers, you can make an argument about how using a computer to do it means you lose the ability to solve it by hand. From accounting to engineering to programming to administration to physics to writing, in all these areas (and more) older practitioners have bemoaned the use of computers to quickly and accurately solve problems that they have spent a lifetime mastering how to solve by hand. The reason for their opposition is pretty clear. I don't know why this type of attitude is so prevalent among some sections of the programmer community. Programmers are the people who should most of all appreciate the ability of computers to automate tedious and error prone tasks. Yet for a certain class of easily automatable programming problems there is a group of programmers who resist very strongly the use of computers to automate. Maybe it's just the same old issue of not wanting to admit that something they spent a long time mastering isn't very useful anymore and that they are getting outcompeted in the marketplace. I think there is a bit of unpleasant machismo about it as well though; the idea that you aren't a 'real' programmer unless you eschew a certain level of automation (be that high level languages or compilers or version control or automated build systems or syntax highlighting or tools to refactor code etc).
      - melling 12y ago
        No, I didn't shift the goal post. I added an extra sentence to fix the "parse error". I use a Xcode debugger when it works, for example. However, I'm also able to effectively debug my code when Apple breaks it. I've been dropped in to debug JavaScript in IE7, for instance, and told that I couldn't install Chrome to debug it because it "wasn't a corporate standard". Someone who wants a complete ecosystem before they can be effective strikes me as a problem.
- breakingcups 12y ago
  Plenty of cars have been made without a three-point seat-belt. I write plenty of Go in my time off but professionally I write C# in Visual Studio and the debugger is amazing. It's saved me thousands of hours cumulatively over the years. I like Go a lot, but lack of a proper debugger can definitely be seen as an argument against it by someone considering the language.
  - coldtea 12y ago
    >Plenty of cars have been made without a three-point seat-belt And? Who said it's that better? How many died or didn't die anyway?
  - kochthesecond 12y ago
    I mostly write java, and only very rarely use the debugger. If I need to verify or poke behaviour, I generally write a test to find out. Stack races and tests are usually enough.
kid0m4n 12y ago
https://github.com/derekparker/delve https://github.com/derekparker/delve There is a talk scheduled on this at GopherCon 2016. Make sure you have a look at it.
aikah 12y ago
Strange as I was just debugging my go code. http://postimg.org/image/prgj1qjzn/ http://postimg.org/image/prgj1qjzn/ Care to explain me how I'm debugging some la,guage that has no debugger?
- linkregister 12y ago
  LiteIDE, which uses gdb in the background, isn't reliable. golang.org/doc/gdb: "although GDB can be useful in some situations, it is not a reliable debugger for Go programs, particularly heavily concurrent ones"
  - deleted 12y ago
    [deleted]
grogenaut 12y ago
There are some okay debugging options but I also agree with parent that debuggers are useful. Especially when learning a language and trying to tease out WTF is going on. When you don't understand the meta of the print statement especially. And you don't yet grok the testing framework.
PopsiclePete 12y ago
What I'm going to say won't make much sense at first, but I find I don't really need a debugger when writing Go. A log statement here and there combined with unit tests and the race detector get me through every time. I absolutely refuse to touch Java/C#/C++ without a debugger, but that's because they're a lot more "magical" - lots of layers, lots of magic, 'heavy' types. Go is a lot more explicit about what's going. It is more verbose, yes, but you also know how things work by just looking at them. I'd love a debugger for Go, sure, but I just don't need one.

prattbhatt 12y ago

Not sure if going forward with Angular.js was the right choice, given Angular 2.0 had been announced, and will be different from Angular 1.0 (no backwards compatibility)

iends 12y ago
FUD. There will be a clear migration path, including, it seems, the ability to run both 1.x and 2.x modules side by side using the new router from 1.4. This means you won't have to rewrite your 1.x modules immediately. 1.x also has a commitment from the Angular team to remain maintained for the foreseeable future.

count 12y ago

I'd love to hear how folks are actually deploying Golang for web apis - using Gorilla, net/http, etc?

themartorana 12y ago
We're using either Gin[0] or pure net/http with Julian Schmidt's HttpRouter[1]. Even Gin lives on top of net/http, and most serious routers/frameworks do. [0] https://github.com/gin-gonic/gin https://github.com/gin-gonic/gin [1] https://github.com/julienschmidt/httprouter https://github.com/julienschmidt/httprouter
namidark 12y ago
Upstart + net/http
jaegerpicker 12y ago
First one I deployed I used martini but now I'd just use the net/http lib and pull in a few gorilla libs as needed.
steakejjs 12y ago
Nginx and net/http has worked wonderfully for me. Nothing fancy is necessary.
stilldavid 12y ago
Like the others, net/http with gorilla packages pulled in as needed. Nginx for static files and a reverse proxy for go. Upstart, and that's about it!
neillyons 12y ago
I have multiple Go apps on my Linode server. I use nginx as a reverse proxy. Each Go app listens on a different port. I use supervisor to start/stop my Go programs. I also use it for log rotate and to autostart my programs on a system reboot.
buro9 12y ago
I've created a simple solution for a few projects I'm working on, it's a kind of REST service wrapper. Basically, I have a "service" package that offers: * mux routing * Negroni for middleware (with stats and auth middlewares delivered out of the box) * a centralised logger * Rendering of things to JSON * An idea of controllers (a controller is a web handler for a given route, handling all verbs) * An idea of handlers on those controllers (per verb... you basically just load in your GET or POST handlers here) * HEAD and OPTIONS for free (including automatic Allow headers) * Error handling returns JSON throughout, including 404s, etc * Basic filling of structs with POST'd/PUT'd JSON The thing is fairly primitive, and it's Go idiomatic and so doesn't provide a context for the middleware and handlers, but it just allows one to rapidly say "this struct, to this controller, on this route" and the rest is for free. This is just a starting ground though, a test of an idea. If I can package this better and have it be a little less hacky in nature I'll look to open-sourcing it. Right now it's really just testing the idea of taking all of the cross-cutting concerns and common issues and solving them via this service package I've made, with the goal of just letting us get on with writing the business logic. I want to expand it... with better description of errors, standard schemas for arrays being returned, auto-documentation of the endpoints (perhaps Swagger, but it seems awfully monolithic in nature), etc.

chrisdegroat 12y ago

"[Go] is impressively fast and soon we figured out that our bottleneck was not the language/framework neither the application, but our database" You re-wrote your entire REST API in a new language without first understanding where your performance issues were?

therealwill 12y ago
They also talk about switching DBs. In my experience it is rarely the database choice but bad schema and/or poor SQL queries.
- BinaryIdiot 12y ago
  Yes these were my biggest problem with this post; they don't spend the time to try and find out bottlenecks and when they finally do instead of investigating the WHY they're thinking about simply switching to yet another which is going to have the same issues if they're not using an optimal data model, etc.
  - ceejayoz 12y ago
    This is unfortunately a very common problem-solving approach. I've seen devs upgrade jQuery because they're getting a 500 error from a PHP app. No relation to the problem - it's just flailing around in hopes something random works.
- 0xdeadbeefbabe 12y ago
  NoSQL is a database choice now, a worse choice in my opinion. So, I'm not surprised they are considering Rethink and Mongo. What's funny is how much more exciting Arduino itself is, compared to all this.
  - Someone1234 12y ago
    > NoSQL is a database choice now, a worse choice in my opinion. If that's legitimately your opinion on that topic then I suggest you expand your knowledge. NoSQL databases aren't slot in replacement for SQL databases. However, for what they're good at they're REALLY good at it. Namely highly scalable, Document Storage (or "blobs"), and incredibly low latency reads. Keep in mind that NoSQL doesn't mean schemaless. You can have a schema and be NoSQL, and that is the direction most NoSQL databases are moving into (or have moved into).

PedroBatista 12y ago

Being 100% honest, the first thing it came to my mind after reading the title was "Why?". And now I still don't know why. Maybe I'm dead wrong but for me this is yet another case of pure tech fashionismo.

Svip 12y ago
My personal motivation for rewriting some of my old PHP projects (albeit hobby projects at best) to Go is A) willingness to maintain PHP (which is almost nil) and B) rewriting programs can help discover bugs and re-understanding your programs. But that's for small hobby projects, where the developer team is usually just me. For a large project, there should be some serious advantages to Go over PHP in their use cases. Don't get me wrong, I think Go is a better language to write websites in than PHP, but I am also a pragmatist.
- EugeneOZ 12y ago
  There is a lot of reasons to choose Go over PHP for new project (static typing, better scaling because of smaller memory footprint of each request and so on). But for existing project all is not so simple. But after reading their post I understand it as they just got tired because of code mess, so rewrite was only way to clean things up. Only thing I don't understand is why they didn't remove PHP at all.
ExpiredLink 12y ago
HDD (Hype Driven Development)

butterfi 12y ago

As a developer, I appreciate having an interest in and using different technical combinations, but as a site maintainer I've been wrestling with how to accommodate different tech stacks with limited time and developer resources. It's lead me to start questioning the developers choice of tech vs. what the right tech choice for the organization. There's an assumption the developer will choose the right tech, but frequently the client has no idea how to access tech decisions and developers are left to pursue whatever they choose. There are use cases where a custom stack is appropriate and other cases where a an off-the-shelf solution (like WordPress, Django, Drupal, etc) has better options for long term support. I'm not saying this is the case at arduino.cc, but the blog post did trigger that reaction.

Zikes 12y ago

I love coding in Go, it's much more fun for me than PHP or node.js. According to half the comments here and on every other Go-related HN post that makes me a hipster, fashionista, hype-driven sheepdev. If this had been a post about Arduino.cc being unhappy about performance and refactoring their code in an attempt to improve that, nobody would be batting an eye. But since they decided to refactor with Go, suddenly everyone is asking "why?"

BringTheTanks 12y ago
Asking "why" is a sign of curiosity, a desire to gain insight from the experience of those who are, apparently, willing to share it with us. Using fashionable tech X is not bad on its own. But without the "why" we have no clue what the author's reasons for the given choices are, and how the end results align with the initial reasons. Lots of small businesses have driven themselves off a cliff basing their tech choices on what their employees would "enjoy" most. It's a good reason to code Go in your free time, but not to migrate a company's infrastructure to it. It's very strange to see that you wouldn't want to know "why". Maybe you're smarter than all of us.
- Zikes 12y ago
  The "why" I'm seeing here is not the curious type, it's demanding justification. It's telling people they must explain themselves thoroughly, to defend their decision every single time they choose to use it. Go is sufficiently mature enough that those questions need not be asked any longer. Docker is built on it, Google's Vitess database sharding system (which powers YouTube, of all things) is built on it. Nobody is at risk of "driving themselves off a cliff" for choosing Go, provided they are proficient enough with it. I haven't seen any other language get as much hate as Go does on this site.
  - BringTheTanks 12y ago
    If I'm asked why I use the technologies I use in my projects, I'd gladly give specific engineering and business reasons, and not just say "YouTube uses it". We should be ready to have these technical discussions and encourage them, not be so strangely defensive about it as you seem to be.

alexbilbie 12y ago

Which IDEs have good Go support (code complete + debugging)?