141–150 of 415 posts
Numerous irregularities plus a strong vested interest in the JVM make me doubt they have given adequate shrift to Go, here. Given the amount of interest in Haskell and Yesod around here, it is strange that it is missing.
I see more people making uninformed "haskell sucks" posts than expressing interest in it.
>and Yesod
Really? Yesod is the anti-haskell haskell framework.
What kind of server did you guys use for your rails test? Thin, Puma, Unicorn? Are you sure you ran it in production environment? Update: Looks like passenger in development mode. Good job you benchmarked a web server that no one uses wile reloading all code between requests. Update2: Ok it seems to run in production mode but still, passenger is not an idiomatic choice.
Numerous irregularities plus a strong vested interest in the JVM make me doubt they have given adequate shrift to Go, here. Given the amount of interest in Haskell and Yesod around here, it is strange that it is missing.
>Given the amount of interest in Haskell I see more people making uninformed "haskell sucks" posts than expressing interest in it. >and Yesod Really? Yesod is the anti-haskell haskell framework.
Can you please elaborate. Being interested in Haskel web development and trying to choose web framework makes me wish for more information.
What kind of server did you guys use for your rails test? Thin, Puma, Unicorn? Are you sure you ran it in production environment? Update: Looks like passenger in development mode. Good job you benchmarked a web server that no one uses wile reloading all code between requests. Update2: Ok it seems to run in production mode but still, passenger is not an idiomatic choice.
I'm not familiar with Rails. Could you explain what you mean in layman terms? Why is code being reloaded on every request by default?
Earlier quoted context omitted.
I'm curious about that - because there's so little to webgo I suspect the answer is something really trivial. I haven't really looked at it before, but the framework itself is just 500 lines or so unless I'm looking at the wrong one... Given that the json marshalling and server components would be exactly the same between go and webgo, I'm curious as to whether changing the url recognised to be just /json in the gowe…
Just had a look at the tests and the urls responded to differ: http://localhost:8080/json http://localhost:8080/ (.*) Shouldn't all these examples at least be trying to do the same sort of work? For such a trivial test differences like that could make a huge difference to the outcome. It's great to see replicable tests like this which show their working, but they do need to be testing the same thing. I also think the…
Seriously though, this isn't news to anyone that does this professionally. The further up the abstraction curve you climb, the less performant the code will be. Ease of development vs run-time performance.
I Will love to see dotNet (C#) incluid in this test. Asp.Net WebAPI (Synchronous and Asycnhrounous) Asp.Net MVC (Synchronous and Asycnhrounous) Asp.Net HTTP Handlers (Synchronous and Asycnhrounous)
Also ServiceStack vs ASP.NET MVC vs NancyFX vs Fubu, Mono vs IIS/windows, default serializer vs JSON.NET vs ServiceStack's, etc. There are tons of variations that could be done.
Numerous irregularities plus a strong vested interest in the JVM make me doubt they have given adequate shrift to Go, here. Given the amount of interest in Haskell and Yesod around here, it is strange that it is missing.
Could you elaborate? Their website seems to indicate that they are a very polyglot shop, not someone pushing a JVM agenda: "On the back-end, we use Java, Ruby, Python, .NET, PHP and others based on what makes sense balancing server performance, scalability, hosting costs, development efficiency, and your internal development team's capabilities."
Then you see results for some languages that are completely out of whack with most other such benchmarks (they themselves mention the weirdness of Sinatra vs. Rails, for example).
Then you see on a couple platforms that more performant mainstream options have been excluded, for no good reason.
Then if you look at the repo, there are deployment choices and code mistakes in some of the other languages which go well beyond elementary incompetence...