Such as? We tried really hard to use lift, but it was terrible. It is just an ugly mix of rails and seaside with a lot of un-fullfilled promises being used to market it. Like the type safety they claim is so unique, but which is virtually non-existent and pales in comparison to all the SML, ocaml and haskell frameworks.
>i'd prefer scala community to push lift instead
The scala community abandoned lift because the lift community is incredibly hostile and constantly attacks both lift users and scala developers. Since lift ostracized themselves long ago, the scala developers have focused on play instead.
That chart is just plain bizarre. He appears to have placed languages randomly without even bothering to google the languages first to get even a vague idea of roughly where they might belong. I don't think he actually managed to get any of the language listed in approximately the correct area on the chart.
NetBSD and debian both customize 3rd party software to fit with the project's desired software policies. That is quite different from arch which just packages everything up as-is.
That's a great example, as it shows anti-virus scammers are just as bad as the airport security scammers. Someone being named Osama Bin Laden has no bearing on their likelihood of hijacking a plane.
As saalweachter points out, it is also drawing a completely nonsense conclusion. Python is not orders of magnitude faster, he is running it on hardware that is orders of magnitude faster. It is actually about the same speed.
This is exactly what we need. Except that the pricing on S3 storage is just too high. It is way more expensive than just buying our own replicating storage and hosting one off site. 25TB in s3 is is $43,000/year. It cost us $90,000 to get 4 falconstore ga700s and (3x40TB) of storage. This gives us 2 devices on site in a HA setup with 40TB of storage, and 2 offsite devices in different datacenters with 40TB of storage each. We end up with way more features than amazon's offering, better performance, and the 40TB of storage we have costs less than 3 years of having 25TB of storage at amazon, where we'd still need to be paying for the local storage as well.
There is no extra time. You just moved time at night to time in the morning. You can take advantage of that time regardless of whether it is in the morning or the evening.
>Most languages can help you avoid using the wrong one through the use of variable names.
That doesn't help at all, are you serious? Cause you genuinely sound like you are trolling. Especially when you say things like "if a language can't prevent every possible bug then there's no poing having it prevent any bugs".
No it isn't, it is compiled to bytecode and executed on a virtual machine, just like most scripting languages are.
>Since this is not about a simple CGI application a benchmark in which you compare the running time of a compiled executable with the interpretation and running time a another program it doesn't make a lot of sense.
Read the site, this concern is explicitly addressed. The tests are long running, not short tests repeated a million times. So the byte code compilation step ends up too small to notice. That is why using a PHP bytecode caching plugin doesn't increase PHP's performance on the shootout, and why java isn't dead last from the massive startup time of the JVM.
>Also this performance usually isn't the best way to argument about languages for web applications
This is a myth. Very few web applications actually have one CPU intensive portion that can be moved out into a C module. Most web apps have pretty flat profiles, where overall language speedups make the biggest difference. When 90% of your time is spent in 10% of the code, a C module is a reasonable option. When 90% of your time is spent in 90% of your code, your only option is a faster language.
I can try. Basically it is a PHP framework written in ruby. It has a really poor API that makes for very error prone coding. It completely fucked up the entire MVC architecture, creating a big fat controller layer that contains logic that belongs in the model. This makes it impossible to re-use code as much as it should, and makes unit testing much harder as there's too many inter-dependencies. And monkey-patching is the norm with rails, which causes all sorts of bugs. Monkey-patching is basically changing the API of existing classes, so then other libraries you might use break because the API they are expecting from the ruby library has changed on them.
The model side of things is certainly my biggest complaint. The other things are minor in comparison, but still annoying. I like the architecture of lift, just not some of the details of the implementation.
I don't like the way templates are forced to use snippets to load data, in particular as it results in snippets being dependent on the database, and thus not suitable for unit testing. The framework should be pulling the data into the view, which then passes it as an argument to the snippet to do whatever transformation on it. That way snippets are entirely self-contained and easy to unit-test. This is the sort of thing that I think would have ended up the way I want had it been written in haskell instead of scala just because writing small, self-contained functions is the typical haskell way of doing things.
I hate the very opinionated nature of the form handling, and the even more opinionated responses from the developers to questions like "how can I make a form that works normally and doesn't require a session". People are not bad for wanting forms to behave normally, and the "security" show the lift devs put on to justify the form handling in lift is insulting.
While I find templates acceptable, they are seriously missing out on type safety. I should get a compiler error if I create a template with invalid html. Ocsigen got this part very right (an ocaml framework/appserver). Not only do I not get this benefit for my markup, but lift itself generates invalid html on me when using virtually any of the included form generation methods. Very annoying.
Ideally what I want is a framework that gives me the type safety of yesod, but with the structure of lift. I hate faux-mvc web frameworks and find they make things more difficult rather than making things easier, and unfortunately yesod copies the typical rails clone structure. Lift doesn't make the mistake of trying to hide http from me, and gives me the simple and correct mapping of template to url, leaves the domain model in the model instead of cramming it into "controllers" that shouldn't be involved.
Yes. Scala lets you bypass the compile time type safety pretty easily, and as a result tons of libraries do precisely that. Take squeryl for example, it advertises itself as a type safe DSL for querying databases, but virtually anything you throw at it will compile, and then results in run-time exceptions.
>For complex template rendering/delivery, Erlang will probably beat anything out there because of Erlang's intelligent use of immutable data and I/O lists.
What templating engine are you talking about? I'd assume ErlyDTL for obvious reasons, but it is certainly not beating "anything out there". Are you just comparing it to scripting languages or what?
I'm not a huge fan of lift, but the portion of it I am ok with (the templates/snippets side of things) is fairly similar to how you use snap. It may be worth it to work on helping to finish snap (or forking it if need be) rather than starting from scratch. Snap currently provides nothing for database access, so you have a blank slate there to copy mapper or record from lift (but those both suck horribly!).
Ah, yes we weren't looking for functional languages specifically, just languages with expressive type systems. As far as I know, the only languages with expressive type systems are also functional so we end up with a functional language as a consequence of that requirement, not due to actively seeking a functional language.
We use scala in a pretty functional way, but most of the gains there come in the processing/displaying side rather than the model. Just because that portion lends itself to a functional style of applying chains of functions on data to transform it.
Such as? We tried really hard to use lift, but it was terrible. It is just an ugly mix of rails and seaside with a lot of un-fullfilled promises being used to market it. Like the type safety they claim is so unique, but which is virtually non-existent and pales in comparison to all the SML, ocaml and haskell frameworks.
>i'd prefer scala community to push lift instead
The scala community abandoned lift because the lift community is incredibly hostile and constantly attacks both lift users and scala developers. Since lift ostracized themselves long ago, the scala developers have focused on play instead.