4 ms·
I personally prefer whatever language/framework gets value out the door quickest on the side of handling HTTP requests (e.g. rails or laravel for the front-faci
by fideloper 10y ago
I personally prefer whatever language/framework gets value out the door quickest on the side of handling HTTP requests (e.g. rails or laravel for the front-facing items) and something like Golang for plumbing or work that requires speed/CPU optimization - queue workers, file manipulation, data streaming, whatever.
Golang (and NodeJS) both feel really kludgy to me when getting into things like handling form submissions (validating input, redirecting with error/success messages, and all those tedious things that the popular frameworks abstract away the best they can).
- ksubedi 10y agoThis. After using Go, Nodejs (Express, Koa), PHP (Laravel), Java (Spring) and C# (Asp.Net Core), I realized that nothing beats me in productivity when I am using Spring or Asp.Net core when building a web app. Little things like form validation, route management, templating and a ton of little under the hood stuff are much much easier with older frameworks that have been around for a while.
- cutler 10y agoCan you expand on how Spring or Asp.Net are better than Laravel with respect to form validation, route management and templating which are generally regarded as PHP's fote?
- ksubedi 10y agoLaravel actually was great at form validation, route management and templating, probably one of the best, however performance is what made me move away from Laravel. With Spring and Asp.net Core, I got the best overall development experience compared to the other ones I mentioned.
- out_of_protocol 10y agoTry Elixir + Phoenix ;) All the little things you've mentioned plus more (like good asset management out of box, super easy to use channels, migrations, clustering, deep system inspection etc)
- GoodbyeEarl 10y agoI've been doing Node for a while and wasn't sure if I should take some time to learn Rails, you've just helped me to decide to do so. Thanks.
- jgimenez 10y agoI think you have to use each tool for what it's for. Golang is useful for high performance stuff, yet it's easy enough to handle an HTTP request and parse JSON, for example. Of course if you compare it with other options, you will find solutions that provide better expressiveness with less code (development speed), at expense of execution speed, type safety,...
- stock_toaster 10y agoI would say that while it is easy to parse json, it only remains easy if your json is straightforward and/or "well formed". If your json is... less well formed, you're going to have a much harder time parsing it with Go (and parsing it with good performance).
- inimino 10y agoWhat do you mean by "well formed"?
- stock_toaster 10y agoI mean one which doesn't have many similar, but variable, content structures, and/or which depending on the attributes of one of the elements. I had to deal with large volumes of json (think log streams) that while they shared many top level attributes, also had had accreted many "optional" components with "types" that depended on the values of certain attributes (each with different nested elements too). While awkward to deal with in python (lots of `if x in y['thing']` checks), this was very cumbersome to deal with in Go. It required lots of reflection and ended up being comparatively slow (python json parsing is actually pretty zippy). It just isn't one of Go's stronger suits in my opinion.
- inimino 10y agoOK. Interesting. One of the benefits of JSON is that it is ad-hoc extensible. Otherwise why not use an efficient binary format? When more strongly typed environments add JSON support they often screw this up, which is unfortunate. Maybe an opportunity for someone to write another library to better support more idiomatic usage of JSON.