5 ms·
Not to mention that he assumes all the faster langs take more effort. What if you could have a lang that is a best performance and be highly productive- he assu
by voidlogic 13y ago
Not to mention that he assumes all the faster langs take more effort. What if you could have a lang that is a best performance and be highly productive- he assume this is not possible.
The Go code size is pretty small, in fact it might be smaller than the Rails code... I'm still trying to find all the Ruby files, Go is in one file...
- kbenson 13y agoI don't consider the Go size pretty small. Mojolicious[1], Dancer[2] and Kelp[3] have set the bar for small code size for me. Not sure yet if there are smaller ones (note that there are no other files required for those apps, period) In the same vein, Lua's OpenResty[4] looks good, as do Tornado[5], Flask[6] and Bottle[7] (although you need to tease the raw/ORM methods apart to get an idea for the last two). And of course, Sinatra[8]. There probably a lot more, especially for PHP, but I didn't feel like going through that list. [1]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/mojolicious/app.pl https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [2]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/dancer/app.pl https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [3]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/kelp/app.pl https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [4]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/openresty/app.lua https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [5]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/tornado/server.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [6]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/flask/app.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [7]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/bottle/app.py https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [8]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/sinatra/hello_world.rb https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
- voidlogic 13y ago>>I don't consider the Go size pretty small. You realize that Go implements the new template test right? Your linked ones do not (at least the ones I spot checked). Also, Go is statically typed = win
- laumars 13y ago> Also, Go is statically typed = win Actually I find Perl's type system to make the most sense for web work: 1) Any zero length string or 0 valued int is classed as false, which is handy when checking the returns from query strings et al. 2) You can use eq for string comparison or == for numeric checking, which means which is handy has you can read values from a query string and then compare it against an int without having to do type conversion. Don't get me wrong, I don't have anything against statically typed languages - in fact I normally prefer them. But the way Perl does type checking I find reduces the number of type problems when dealing with web development. That all said, I much prefer working with structured types in Go than in Perl.
- kbenson 13y ago> You realize that Go implements the new template test right? Your linked ones do not (at least the ones I spot checked). hello.go uses more lines defining variables and types than the entirely of many of the alternatives I posted. Obviously they will be a little longer if they implement the fortune handler, but I doubt that will really make much of a difference. > Also, Go is statically typed = win I'm not sure what that has to do with implementation size (which is the only thing I was addressing), but feel free to make a case.
- laumars 13y ago> I don't consider the Go size pretty small. Mojolicious[1], Dancer[2] and Kelp[3] have set the bar for small code size for me. You've basically just listed Perl 3 times though. Particularly when the guts of the code in all 3 of those examples was Perl's standard database interface (the same DBI you'd use for CGI Perl or even standalone .pl scripts). I do love Perl for the flexibility of it's syntax and how concise the code can be. But for me the performance of Go won out. And while mod_perl* does make great gains in performance, it also makes the code a lot less portable (unlike Go). So I found myself porting my performance critical webapps over to Go * I've not tried Mojolicious, Dancer nor Kelp so I couldn't comment on how they compare for performance.
- kbenson 13y ago> Yeah, the post started slightly different than it ended, and that's an artifact of that change. My next paragraph listed many more, and I tried to do multiple from each language that I looked at which had simple implementation.s > Particularly when the guts of the code in all 3 of those examples was Perl's standard database interface (the same DBI you'd use for CGI Perl or even standalone .pl scripts). The benchmark page clearly tags which implementations use raw SQL access and which use an ORM. These all happen to be using raw SQL. To my knowledge, none of them have a pre-bundled ORM, and I'm not sure whether the ORM tested implementations are only supposed to indicate the pre-shipped ORM. > But for me the performance of Go won out I wasn't trying to imply they competed on that metric, I just wanted to give some examples of much simpler implementations. What one considers small is obviously relative. > I've not tried Mojolicious, Dancer nor Kelp so I couldn't comment on how they compare for performance. They all look to be bottom-half of the full set of results, performance wise. Mojolicious quite a bit slower (relatively, they are all slow compared to Go) than the others, most likely because it uses it's own internal, pure Perl JSON module. There's was to fall back to the optimized C-based JSON::XS module, but I'm not sure whether that would keep with the spirit of the benchmarks.
- laumars 13y ago> The benchmark page clearly tags which implementations use raw SQL access and which use an ORM. These all happen to be using raw SQL. To my knowledge, none of them have a pre-bundled ORM, and I'm not sure whether the ORM tested implementations are only supposed to indicate the pre-shipped ORM. You miss my point. All of those examples you gave used the same core database framework and as the test was primarily a database performance test, all those 3 examples were essentially the same core Perl code. Whether it's ORM or raw SQL is completely besides the point (though since we're on the topic, Perl's DBI basically works the same as Go's - or rather that should be the other way around given their age). >I wasn't trying to imply they competed on that metric Again, you missed my point. I wasn't suggestion that you were comparing the performance of the two. I was commenting on why I switched away from Perl to Go. > I just wanted to give some examples of much simpler implementations. Except you didn't You gave AN example (singular). It was one language; Perl. > They all look to be bottom-half of the full set of results, performance wise. I wouldn't trust that kind of benchmark for comparisons of Perl frameworks as setting up a Perl environment isn't as simple as compiling a Go program. With Perl, you have a number of different ways you can hook the runtimes into the web server (CGI, Apache libs, etc), pure Perl and C libraries (which you also mentioned) that significantly affect both memory usage and runtime performance and a whole boatload of config ($ENVS in mod_perl, bespoke handlers, etc) that also affect performance. The ironic thing with Perl is despite scripts in the language being some of the most portable code on the POSIX community, running performance critical Perl webapps leads to very unportable set ups. (which was the other reason I migrated my sites to Go). This might sound critical, but I genuinely do love Perl. I'd say it was up there as one of my favourite languages (and over the years I've learn to develop in a great number of different languages). But sadly nothing in life is perfect.