Moving from PHP to Go and Microservices | Hacker News Reader

Moving from PHP to Go and Microservices

blog.arduino.cc

50 pointsmbanzi61 comments

"[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?

They also talk about switching DBs. In my experience it is rarely the database choice but bad schema and/or poor SQL queries.

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.

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.

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.

> 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).

> If that's legitimately your opinion on that topic then I suggest you expand your knowledge.

So, If my knowledge were expanded I would think NoSQL is an equally valid option, and not a worse one? I hesitate to do any more expansion because of this panel held in 2014 [0] asking weather we are in a big data bubble, and probably answering "yes", but I wasn't there.

Simple query language is REALLY good too. It has a kind of general usefulness.

> Keep in mind that NoSQL doesn't mean schemaless. You can have a schema and be NoSQL

Can you also have SQL and be NoSQL?

[0] http://people.csail.mit.edu/tatbul/publications/sigmod14_pan...

> So, If my knowledge were expanded I would think NoSQL is an equally valid option, and not a worse one?

For some things NoSQL would be a better option. For most things SQL remains the better option.

> I hesitate to do any more expansion because of this panel held in 2014 [0] asking weather we are in a big data bubble, and probably answering "yes", but I wasn't there.

We were in a dot-com bubble around 97-2000, maybe the internet is a bad idea also?

> Can you also have SQL and be NoSQL?

By definition, no. But some NoSQL databases do support an alternative to SQL with some of SQL's properties (e.g. JSON-like syntax).

Wasn't this a thing, a few years ago.

http://talks.php.net/show/digg/7

They also list microservices as a goal instead of a solution to a problem.

This is all just tech hipsterism.

Did you learn tech by only applying optimal solutions to well analyzed problems ? I bet that a lost of your progress has rather been fuel by sheer joyful experiments with technologies you fancied, thus validating them for less adventurous users who had actual problems to solve. Those guys make Arduino - they pretty much embody that spirit !

> tech hipsterism

Thank you! I have been looking for the right words to describe this for ages. You nailed it.

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.

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.

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.

HDD (Hype Driven Development)

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?"

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.

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.

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.

If you used Java, C/C++, PHP, Python, or Ruby, nobody would bother to ask why, because "everybody uses it". Because they are mature and proven technologies. Just like Go is.

And I do love technical discussions around Go vs any of those or other languages, or indeed even discussions having nothing to do with Go, but I'm tired of all of the hateful comments Go developers get.

If I seem defensive it's because I am constantly put on the defensive.

My apps are service-oriented, and every service is in a different language. And for every one of them I and my team ask ourselves "why".

The only one framing the debate so negatively here is you. As a fan of "Go" you should be taking the opportunity to educate people about it.

Instead, I'm left with a bad taste in my mouth. Let's hope this mood is not representative of the Go community.

> The only one framing the debate so negatively here is you.

"hipsterism" - https://news.ycombinator.com/item?id=9394483

"pure tech fashionismo" - https://news.ycombinator.com/item?id=9394119

"Hype Driven Development" - https://news.ycombinator.com/item?id=9394371

These are the comments driving my responses which are negatively addressing the developer's choice of language, and those are only the ones on this thread. I'm sick of Hacker News trying to make developers feel guilty for using a technology.

I have not argued against anyone asking "why" in regards to what language they feel is best suited to the task at hand. Obviously that question needs asked for any project. I am arguing against everyone whose instant response to "we built X in Go" with "oh god why would you do that" types of "why". There is a distinction in those whys, and if you cannot or will not recognize that distinction then that is your own failing.

I am not involved with or representative of the Go community. I represent only myself.

If you're starting something new and decide to pick something for even no better reason than "I like it", great.

If you use something else and decided to switch to one of those languages, someone might well ask why. Rewriting is almost always a decision that needs some justification.

> If you used Java, C/C++, PHP, Python, or Ruby, nobody would bother to ask why

People ask "why?" about conversions to those languages all the time (if you converted a web project from PHP to C/C++, I'd expect you'd get more "why?" questions than doing the same thing from PHP to Go.)

> Go is sufficiently mature enough that those questions need not be asked any longer. Docker is built on it

So... just so I can get the chain of thought, here:

   * the language has growing for a while
   
   * people have used it to ship something

Therefore, no more need to ask questions -- just switch to it!

> I haven't seen any other language get as much hate as Go does on this site.

Given the amount of criticism PHP and JavaScript get on this site, this statement is simply indefensible.

And a lot of the criticism Go gets is concrete and a direct result of choices the language designers consciously made.

> Therefore, no more need to ask questions -- just switch to it!

Well, sure, if you want to twist my words then go ahead.

What I said rather clearly, but seems to have been lost on you, is that questions not asked in earnest but in flippant disregard for the developer's choices are not welcome.

And my statement on the hate Go gets is certainly defensible. I never questioned the criticisms, I'm not here to say Go is perfect, only to rail against the senseless vitriol that is guaranteed to fill the comments on every Go-related link posted to Hacker News.

> I haven't seen any other language get as much hate as Go does on this site.

While not from the same people or for the same reasons, JavaScript, Dart, and Java all get plenty of hate here. Conversely, Go also gets plenty of love as well as the hate (probably more than any of JS, Dart, or Java does.)

Its high visibility in the community here, so it get lots of attention, positive and negative.

That's a reasonable assessment and I agree.

I was called similar when I started learning Python a few years ago. I think the simplicity and elegance of Go will let it catch on very quickly.

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

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

[1] https://github.com/julienschmidt/httprouter

Upstart + net/http

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.

Nginx and net/http has worked wonderfully for me. Nothing fancy is necessary.

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!

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.

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.

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.

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

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.

"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 looks very promising.

jschlatter just wrote a great blog post about this:

http://blog.mailgun.com/introducing-a-new-cross-platform-deb...

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?

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.

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 ...

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).

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.

I'm fairly certain I would have zero desire to work someplace that considers 'Yes, i use a debugger' the wrong answer.

That wasn't the question.

>Sometimes stepping through is faster than adding in trace temporarily.

Using trace? ...

Real programmers use print statements...

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.

>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?

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.

https://github.com/derekparker/delve

There is a talk scheduled on this at GopherCon 2016. Make sure you have a look at it.

Strange as I was just debugging my go code. http://postimg.org/image/prgj1qjzn/

Care to explain me how I'm debugging some la,guage that has no debugger?

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"

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.

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.

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)

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.

Reply on news.ycombinator.com