So much truth on that. That’s THE reason I always tell friends working for startups to stop the hype with graphql, react, go and stuff, and advocate for darn simple Laravel or Rails app.
The message in the end is KISS or just take the first boring tech that will give you enough time to prove your business to be successful!
Funny aside: I wanted to contribute to a Laravel app, and damn is it annoying to have to set up a full LAMP stack to do PHP development.
It’s pretty interesting how PHP is probably the easiest language to get production stuff running, but nowhere near as easy as Python/Ruby/Javascript’s “run the included watch script and you’re good to go” for local development.
that said if you know how to use the language, definitely worth just using that. Use what you know, and you can always change things later
Yeah I was trying that out. Still felt pretty uncomfortable with needing that much software to have a dev server working, but the process was a lot better than doing old LAMP stack stuff in Windows.
I’m glad that PHP has improved so much over the years, and hope it can keep on improving.
Well Go is also pretty simple, imo. In the “Go Programming Language” book, they already show you how to create a web server in the first introductory/overview chapter, since the ability is quite well integrated into the overall structure (and standard library) of the language. I, personally, would say, when one looks at all the real-life use-cases of Go, that it has passed it’s hype phase.
A web server is nice, but where’s the battle-tested ORM, routing engine, middleware system, view rendering engine, asset handling system, authentication layer, background job handler, countless other built-in parts, plus roughly a kajillion gems that can drop in to provide various functionality?
Go is interesting and has it’s place, but it’s got a long way to go before it’s competitive for getting a moderately complex site up and running fast.
I’m gonna preface this by saying that I thoroughly dislike go for many reasons, but criticizing it for it’s “web stuff” capabilities seems really weird, since that’s like the one thing it’s good at. Out of the things you mention:
Depends on what you need to do, but this is definitely covered by /x/crypto or /net/http.
background job handler
Goroutines are like the best part of go.
countless other built-in parts, plus roughly a kajillion gems that can drop in to provide various functionality?
Uh…I’m not totally clear on what else you think is missing for rendering a web app
Go is interesting and has it’s place
What do you think is go’s place? Cause I think go is awful for systems level programming, and really it’s only niche is “web stuff” and command line apps.
Honestly, this seems to me like comparing an auto parts shop to a car dealership.
ActiveRecord has its warts, but the Go SQL built-ins are super bare-bones, lets you execute hand-written SQL queries and that’s about it. No comparison IMHO.
I will admit that I was not aware of Go’s ServeMux, which is a bit better than I thought. I only skimmed the docs for it, but they’re like a page long. The manual for the Rails router is at least 20 times longer. I sure don’t see a standardized middleware system, or where you would even put one, given how close to bare metal the web APIs are.
And comparing /x/crypto to something like Devise… well, even the parts shop to car dealership analogy is woefully inadequate. There’s a huge number of ways to do web security wrong. Throwing Devise into a Rails app gets you automatic best practice implementations of almost everything. Pointing somebody at a pack of implementations of bare crypto algorithms and telling them to roll their own everything… that’s a security disaster waiting to happen.
And yeah, goroutines are nice. Until you want to implement a job worker on another computer, or have some records of what jobs are running when, automatic retries with exponential backoff, failure logging, etc.
I could start writing about some of the many other things, but honestly, just read through the Rails guide for an example of the kinds of things a good web framework should do. May the gods of code spare me from having to rewrite all of that stuff from scratch in another language to build a webapp, or from having to maintain a webapp where some other developer rolled all of that stuff from scratch and I have to figure it out.
I use rails and go for several things, and this is a grossly inaccurate comparison.
The sql packages are not even close to the query generation and object mapping in rails, and there’s nothing close to that level of functionality on GitHub.
The standard library routing has no support for parameter extraction, nor separation between http methods. You can put together something useful by combining third party stuff, but it’s not orthogonal to middleware, so you have to glue them or pick middlewares designed for your router.
For authentication, rails has straightforward ways to check auth before running an action; go has bits you can put together yourself and hope you got it right.
Goroutines are great but are not a background job handler. Failure handling, retries, logging job state etc are all solved easily in rails; build those yourself in go.
Maybe, I can’t say for sure. I am no webdev, and my interest for startups is nonexistent, maybe even negative. But what I understood you saying, and the author, was to reject the use of newer technologies, because they are new.
Take for example the most highlighted passage from the article:
Building a product is not about using the latest and greatest technology.
All I wanted to point out, in regards to what you said is that this doesn’t “automatically mean to reject any newer, maybe even better fit technology (and that Go isn’t necessarily a complicating factor). I’d agree that one shouldn’t go overboard, and use some one-week-old language for everything, but that’s the same extreme as insisting to use COBOL on the other side. And after all: From what I was told, businesses are all about “risk”, so isn’t this a good example for that?
React can be treated as proven library, I think. And it speeds up UI development considerably. Of course if you require JS UI at all, and just static forms are not enough.
“jQuery way” becomes painful really quick, even with very simple UIs. Server-side things like Rails or Django are usually good enough and not need to be replaced with something more “modern”, but js-side hype tech is born from pain and frustration, so I would not dismiss React, Webpack (Rails has integration for it now) and even fringe technologies like Purescript.
Go is not hype, BUT for making CRUD webapps and not something that requires an application server I’d agree. Go is a good choice when you start needing to proxy data, do long running connections, write a chat server etc.
Mine is at http://space.af, most people just talk about how clean it is.
“Most people “ are right! This is really clean. I honestly really like it.
I’ve been learning Arabic for the past 8 months or so, and I’m finally at the point where I can start transcribing songs and translating them!
Cool do you have any useful tips that you might share
So much truth on that. That’s THE reason I always tell friends working for startups to stop the hype with graphql, react, go and stuff, and advocate for darn simple Laravel or Rails app.
The message in the end is KISS or just take the first boring tech that will give you enough time to prove your business to be successful!
Funny aside: I wanted to contribute to a Laravel app, and damn is it annoying to have to set up a full LAMP stack to do PHP development.
It’s pretty interesting how PHP is probably the easiest language to get production stuff running, but nowhere near as easy as Python/Ruby/Javascript’s “run the included watch script and you’re good to go” for local development.
that said if you know how to use the language, definitely worth just using that. Use what you know, and you can always change things later
Laravel has made this process easier through homestead, if you want to set up LAMP on your native OS it takes a while longer.
It’s not particularly hard to setup a LAMP stack on your native OS using MAMP or XAMPP.
Laravel Valet is a Mac-specific option that is more lightweight than the Homestead VM. Both make local Laravel development simpler.
Yeah I was trying that out. Still felt pretty uncomfortable with needing that much software to have a dev server working, but the process was a lot better than doing old LAMP stack stuff in Windows.
I’m glad that PHP has improved so much over the years, and hope it can keep on improving.
Isn’t
php -Senough for development?Well Go is also pretty simple, imo. In the “Go Programming Language” book, they already show you how to create a web server in the first introductory/overview chapter, since the ability is quite well integrated into the overall structure (and standard library) of the language. I, personally, would say, when one looks at all the real-life use-cases of Go, that it has passed it’s hype phase.
A web server is nice, but where’s the battle-tested ORM, routing engine, middleware system, view rendering engine, asset handling system, authentication layer, background job handler, countless other built-in parts, plus roughly a kajillion gems that can drop in to provide various functionality?
Go is interesting and has it’s place, but it’s got a long way to go before it’s competitive for getting a moderately complex site up and running fast.
I’m gonna preface this by saying that I thoroughly dislike go for many reasons, but criticizing it for it’s “web stuff” capabilities seems really weird, since that’s like the one thing it’s good at. Out of the things you mention:
Not really an ORM but equivalent functionality: https://golang.org/pkg/database/sql/
Provided in the standard library. https://golang.org/pkg/net/http/
I’ll admit Go’s handling of this is pretty bad.
Depends on what you need to do, but this is definitely covered by /x/crypto or /net/http.
Goroutines are like the best part of go.
Uh…I’m not totally clear on what else you think is missing for rendering a web app
What do you think is go’s place? Cause I think go is awful for systems level programming, and really it’s only niche is “web stuff” and command line apps.
Honestly, this seems to me like comparing an auto parts shop to a car dealership.
ActiveRecord has its warts, but the Go SQL built-ins are super bare-bones, lets you execute hand-written SQL queries and that’s about it. No comparison IMHO.
I will admit that I was not aware of Go’s ServeMux, which is a bit better than I thought. I only skimmed the docs for it, but they’re like a page long. The manual for the Rails router is at least 20 times longer. I sure don’t see a standardized middleware system, or where you would even put one, given how close to bare metal the web APIs are.
And comparing /x/crypto to something like Devise… well, even the parts shop to car dealership analogy is woefully inadequate. There’s a huge number of ways to do web security wrong. Throwing Devise into a Rails app gets you automatic best practice implementations of almost everything. Pointing somebody at a pack of implementations of bare crypto algorithms and telling them to roll their own everything… that’s a security disaster waiting to happen.
And yeah, goroutines are nice. Until you want to implement a job worker on another computer, or have some records of what jobs are running when, automatic retries with exponential backoff, failure logging, etc.
I could start writing about some of the many other things, but honestly, just read through the Rails guide for an example of the kinds of things a good web framework should do. May the gods of code spare me from having to rewrite all of that stuff from scratch in another language to build a webapp, or from having to maintain a webapp where some other developer rolled all of that stuff from scratch and I have to figure it out.
I use rails and go for several things, and this is a grossly inaccurate comparison.
The sql packages are not even close to the query generation and object mapping in rails, and there’s nothing close to that level of functionality on GitHub.
The standard library routing has no support for parameter extraction, nor separation between http methods. You can put together something useful by combining third party stuff, but it’s not orthogonal to middleware, so you have to glue them or pick middlewares designed for your router.
For authentication, rails has straightforward ways to check auth before running an action; go has bits you can put together yourself and hope you got it right.
Goroutines are great but are not a background job handler. Failure handling, retries, logging job state etc are all solved easily in rails; build those yourself in go.
Okay, if you say so, but it’s far from providing you all those bricks the author is writing about.
I feel you’re totally missing the point of my comment and simply reacting on me categorizing go as potentially hype.
Maybe, I can’t say for sure. I am no webdev, and my interest for startups is nonexistent, maybe even negative. But what I understood you saying, and the author, was to reject the use of newer technologies, because they are new.
Take for example the most highlighted passage from the article:
All I wanted to point out, in regards to what you said is that this doesn’t “automatically mean to reject any newer, maybe even better fit technology (and that Go isn’t necessarily a complicating factor). I’d agree that one shouldn’t go overboard, and use some one-week-old language for everything, but that’s the same extreme as insisting to use COBOL on the other side. And after all: From what I was told, businesses are all about “risk”, so isn’t this a good example for that?
Not exactly because they are new but because they lack the bricks Rails for example took years to have.
A common bias too, Go is a language, not a framework (although it has nice primitives for web).
But I get your point and I tend to agree to some extent.
React can be treated as proven library, I think. And it speeds up UI development considerably. Of course if you require JS UI at all, and just static forms are not enough.
“jQuery way” becomes painful really quick, even with very simple UIs. Server-side things like Rails or Django are usually good enough and not need to be replaced with something more “modern”, but js-side hype tech is born from pain and frustration, so I would not dismiss React, Webpack (Rails has integration for it now) and even fringe technologies like Purescript.
Go is not hype, BUT for making CRUD webapps and not something that requires an application server I’d agree. Go is a good choice when you start needing to proxy data, do long running connections, write a chat server etc.