It doesn't matter if you are big or small, you're always wasting resources.. Just count how many servers you have using <50% cpu. By having thousands of users, amazon can organize servers in a way, no cpu is wasted.
If they kept CPUs 100% busy, how would they deal with a surge in demand or a failure situation? You HAVE to keep spare capacity or 1 failover crashes your entire fleet of 5 billion servers.
You could correctly argue that usage increases with scale.. so while you with 1 app can maybe only keep a server 20% busy, Amazon can afford to keep their servers 70% busy.. which is part of the story.
But the other part is you are paying for the convenience. You can get raw CPU way cheaper than what lambda gives it out at. Even if you only kept your CPU usage at 10-20% - for example Digital Ocean would still be cheaper than the Amazon Lambda app version. You are literally paying a surcharge to not have to set up your own servers, or deal with maintenance. I find it very unlikely you will save big money with lambda over your own servers.
Last 2 years I've been using Go (instead of Python), even for webpages & apis. I'm actually considering going back to Python(for webpages and apis) because dealing with database in Go is really ugly. Currently available orms are nowhere near as useful as sqlAlchemy or django orm :(
Glad to hear i'm not alone in that case. I actually think someone should blog about this, because i've got the suspicion that the "moving to go is fantastic" feeling we get from blog posts suffers from a survivorship bias.
I don't have direct experience, but quoting from this[0] seems to indicate that gorm may still have some issues compared to current standard options in the Ruby or Python ecosystems.
"The ORM we ended up using for e.g. our settlement service, Gorm, is not anywhere near the level of maturity of ActiveRecord, and to get its (valuable!) feature set you have to tolerate a) throwing out most of the benefits of using a type-safe language and b) programming bugs which can cause statements which certainly look like they should generate SQL queries to just silently not generate SQL queries. In general, working with the database has been so painful in Go that I have been instead either a) hitting a REST endpoint on an internal API to have Rails do the DB access then return formatted JSON (which Go can actually consume fairly decently) or b) throwing the data at NSQ."
I've come to think the limitations of Go orms are not due to the lack of maturity, but to inherent limitations of the language that are officialy not going to be removed anytime soon ( because they are seen as a feature by the authors).
Something like linq for example seems simply impossible to code in go.
By "hand code SQL" I hope you really mean using prepared statements of whatever language/framework you're using, not concatenating strings with input values. If not, say hello to SQLi.
Word! Flask and the flask-sqlalchemy extension are a dreamteam that i wouldn't want to miss anymore. Golang might perform 10x better, but i'd choose the faster development cycle and comfort of Flask at any given day.
It might be the problems I solve, or the way I think about them, but I think it's about 50/50 whether the ORM is helpful or in the way. Very often I just want the ORM to go away because I know what I'm doing and the ORM doesn't
I do like sqlx, it seems to hit a balance that works for me. I get to write the SQL and structs come out.
I think the likelihood of seeing an ActiveRecord-style ORM in Go is slim: ActiveRecord is a core part of Rails and can therefore make a lot of safe assumptions about its environment. Any ORM for Go can't do that to the same extent, and big Rails-style frameworks don't gain much of a following in Go.
i recently starting experimenting with moving from python to go and for fun (for web development) and was surprised at the current available options for ORMs. even established frameworks like Revel seem like they are suggesting using raw sql queries still:
same reason i gave up on the idea of using ocaml for crud apps, even though i love it for most other applications. it's really annoying to have to manually manipulate database rows via raw lists of strings :(
handling m2m is especially painful. I just hate writing same long code for fetching old members, checking if members are changed and then updating/inserting new members. Joins are also problematic (i like how beego orm is handling it, but it works only for single object and not multiple objects)
And that's all you need to write a Authentication / Authorization Library in 100-200 lines of code. And it will mostly be more secure than most of the things you see in the open world.
> Almost everyone i know is using something in the likes of AngularJS
I do wonder what you mean with that. I think that both React and Ember are different but if you mean a javascript framework for building single page applications you're probably right.
Everyone who is following a bit of technology and/or searching for extra developers ( Brussels/Belgium) are all using AngularJS. Haven't found any mention of EmberJS or React or anything ( doesn't mean they don't know it)
There was only one difference, someone used AngularJS with Typescript :) ==> c#
Agreed. Once you are fully up to speed with it (and not at one of the local optima as brilliantly shown on the famous Angular learning curve diagram), it's a pleasure to work with.
