Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We saved $50k/year with a Go microservice coded in a hackathon

movio.co

Post reply on HN
Print view View original

261–264 of 264 posts

Re: We saved $50k/year with a Go microservice coded in a hackathon

#261

Post by wlll »

cleong wrote: post #220
wlll wrote: post #196

Earlier quoted context omitted.

Because MySQL is the PHP of databases. Much like PHP is designed to just carry on truckin' whatever problem it encounters ( https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ ), MySQL was too. It's easy to slam some data into it and get it back without having to think too hard about what you're actually storing ( https://grimoire.ca/mysql/choose-something-else ). It's ease of use made it pervasive, much like…

PHP was built for the web and has been successful at that job. It is easy to use because the core developers have made some good design choices for the task at hand. For example no threads, stateless requests, core functionality focused on outputting HTML, etc. MySql and PHP are good. They do the job they were designed for in a cost effective way and of course that means there will be trade offs.

PHP is crap. It's actively hard to write good code in it. Not good code like SOLID or pretty code that's self documenting, it's hard to write code that's not going to break in unique and interesting ways.

Sure, you can knock up a contact form in it really quickly, but that ease of use hides significant dangers.

I've programmed it, it's a terrible language.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#262

Post by cleong »

wlll wrote: post #261
cleong wrote: post #220

Earlier quoted context omitted.

PHP was built for the web and has been successful at that job. It is easy to use because the core developers have made some good design choices for the task at hand. For example no threads, stateless requests, core functionality focused on outputting HTML, etc. MySql and PHP are good. They do the job they were designed for in a cost effective way and of course that means there will be trade offs.

PHP is crap. It's actively hard to write good code in it. Not good code like SOLID or pretty code that's self documenting, it's hard to write code that's not going to break in unique and interesting ways. Sure, you can knock up a contact form in it really quickly, but that ease of use hides significant dangers. I've programmed it, it's a terrible language.

This might have been true 10 years ago with versions like PHP 4. But remember many companies have invested a lot into PHP including Facebook. In the newest version of PHP what you said cannot apply with a type system, OOP features like traits, class inheritance etc.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#263

Post by 83457 »

TimJYoung wrote: post #256
83457 wrote: post #204

Earlier quoted context omitted.

But how would you do exclusions with your approach?

I'm not sure what you're asking - could you give me an example of what you're envisioning that couldn't be satisfied with a combination of Boolean expressions in the WHERE clause ?

With this query approach how do you find people that have a prop1 but do not a prop2?

If you get records back with prop1 then you have to remove those records from results based on another record.

There are multiple ways to accomplish this but it can't be done with a single join and simple where clause.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#264

Post by TimJYoung »

83457 wrote: post #263
TimJYoung wrote: post #256

Earlier quoted context omitted.

I'm not sure what you're asking - could you give me an example of what you're envisioning that couldn't be satisfied with a combination of Boolean expressions in the WHERE clause ?

With this query approach how do you find people that have a prop1 but do not a prop2? If you get records back with prop1 then you have to remove those records from results based on another record. There are multiple ways to accomplish this but it can't be done with a single join and simple where clause.

Sorry, I missed your reply. Yes, you are correct, in that case you would need to use a except, sub-query, derived table, etc.
Post reply on HN