Oh thank god. Go is bearable in most areas, but the template system makes me weep. Is there any particular reason the string concatenation doesn't work? Seems special enough to be specialcased ;)
You can use {{print .foo.bar "string"}} and {{printf "%sstring" .foo.bar}} to concat strings in golang template, or even simpler way: {{.foo.bar}}{{"string"}}.
Enlive and related libraries for Clojure, Lift for Scala, and heist for Haskell use node transformation. I know that there are a few others I'm forgetting. Basically given a fragment of an HTML 5 or XML document, your view functions transform it into a different fragment. E.g. in Lift, given
With this technique, your designers can create pure HTML and assets, with no logic in the templates. Basically they create static mock-ups and then the developers "enliven" them.
I prefer this but I don't imagine it will ever become mainstream.
React's JSX is also (as far as I can tell) node based, but with a lot less power (you can really only do insert operations, and the operations don't really compose well).
I recently did a project using this type of template system and it was ok, but not really better than string-based templating. You're really still doing String-based templating except you're embedding all your directives in data attributes and it gets super messy and unreadable.
You need to use something that represents the HTML tree using real data types. I do a lot of my work in Scheme, where we have SXML:
'(p "hello" (strong "jamespo"))
Before you say "ahhh the parens!", there are special readers such as Racket's Pollen that provide a less Lispy, but still powerful, language for writing documents.
For JavaScript, there's of course a bunch of options such as Mithril:
m("p", ["hello", m("strong", "jamespo")]);
I don't write Go so I don't know what the options are there. Just trying to raise awareness for safer programming.
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 :(
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:
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.
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.
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)
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.
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 :(
39 comments
[ 6.0 ms ] story [ 96.0 ms ] threadWith this technique, your designers can create pure HTML and assets, with no logic in the templates. Basically they create static mock-ups and then the developers "enliven" them.
I prefer this but I don't imagine it will ever become mainstream.
React's JSX is also (as far as I can tell) node based, but with a lot less power (you can really only do insert operations, and the operations don't really compose well).
For JavaScript, there's of course a bunch of options such as Mithril:
I don't write Go so I don't know what the options are there. Just trying to raise awareness for safer programming.For much more in-depth information about the problem, see: http://www.more-magic.net/posts/structurally-fixing-injectio...
https://revel.github.io/manual/database.html
this is golang's Django i believe ?
[0] https://github.com/jinzhu/gorm
"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."
[0] http://www.kalzumeus.com/2015/08/20/designing-and-building-s...
Go is still much newer than Python and Ruby. There's no getting around this fact.
Something like linq for example seems simply impossible to code in go.
Am I alone when I say that I still hand code SQL into my applications?
Regardless of what web framework I'm using (e.g. Pylons/Rails/Django/etc), I still hand code SQL statement in my applications.
I've had far to many times ORMs unexpectedly nuke performance and have other issues than what's it's worth gaining by using an ORM.
And golang has the same good crypto tools as Java.
> https://godoc.org/golang.org/x/crypto/pbkdf2
> https://golang.org/pkg/crypto/subtle/
And finally a Token Library: https://github.com/dgrijalva/jwt-go or https://github.com/dvsekhvalnov/jose2go
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.
We're currently using it in our own OAuth/OIDC identity provider.
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.
You know, I always feel ORM is a fix to SQL.