Go can’t do a fancy ORM because of its weak type system. Rust’s type system and compiler plugin support (still being polished, but entirely usable) allow for some really nifty things. An ORM like Django’s is absolutely possible in Rust—and with strong typing and serious error checking into the bargain.
We can also end up with things like HTML templates compiled into your binary and the HTML validated at compile time. Even things as precise as type checking on something like <time datetime="{{ time }}"> can be managed with Rust. And I intend to.
Strong and weakly typed don't mean what you think they do. Strong typing is not about the expressiveness of a type system, rather about it having type safety, being memory safe and having static type-checking, and not having unsafe type conversions (and to a lesser extent implicit type conversions) and unions. What you meant to say was Rust's type system is more expressive then that of Go's.
> We can also end up with things like HTML templates compiled into your binary and the HTML validated at compile time. Even things as precise as type checking on something like <time datetime="{{ time }}"> can be managed with Rust.
These things are already done in several of the Haskell frameworks. There's even Blaze, which is a Haskell DSL that allows you to write HTML entirely in Haskell. Personally, static verification of HTML doesn't seem that necessary, but I suppose it has its merits (possibly for security?).
I think what he means is static type system expressiveness, rather than type system "strength" (which is a term I don't like, since it's so overloaded as to be practically meaningless). Since it's dynamically typed, Ruby's static type system is maximally expressive. Go's type system (as with Rust's, or Java's, or any statically typed language) is less expressive by comparison.
I'm not ready to say that Rust's type system lends itself perfectly well to ORM's, as I haven't really seen an ORM as convenient as ActiveRecord in any statically typed language. (This is one of the reasons I like both statically and dynamically typed languages.) But I'm happy to see people try, of course, and I'd love to be surprised.
tl;dr ORM's with type safety and comprehensive error checking are possible with statically typed languages provided the type system is flexible/powerful enough
Couldn't an ORM for Golang be done with a code generator that generates filter functions and such based on the table layouts and relations? Then you'd get the best of both worlds: "dynamic" operation in the sense that the methods vary depending on the table layouts and relations, plus static validation of what you're doing at compile time.
Go’s type system is still not powerful enough to express such a thing; ORMs depend on blending things together from all over the place, e.g. with joins, method chaining and other things which really need genuine generics. There really is no solution without generics.
Since Go can do generics via code generation [1], I'm not convinced that it can't also do ORM via code generation.
OTOH, I'm not particular fond of ORM as a universally right solution for dealing with DBs (its a solution which makes sense for some DB-related issues in some OO languages, but isn't something that should be reflexive "deal with DB, need ORM"), and its probably not a solution I would reach for for any problem in Go even whether or not you could reasonable do it in Go.
It seems to me that the method chaining is really all about building an internal S-Expression or tree structure of some kind that describes the type of query and joins needed. When it comes to solving problems, it's shaky ground to insist there can only be one possible approach.
Extensive use of reflection (in Go, this takes the form of type assertions) proceed to make it fundamentally possible again, but they have lost a lot of conciseness, certainty of safety and correctness in the process.
It depends. At the very most dynamic end, you'd encounter some troubles writing a code generator that could accommodate arbitrary joins of arbitrary combinations of tables chosen at runtime that happen to be for some reason arbitrarily joinable. This is an odd case, though; I'm sure somebody reading this has seen it and I sure it's out there, but it's probably not a case an ORM should be optimizing for. In most of the conventional uses, code generation could fit the bill, but you'd start getting into some weird declarations or something since you're not going to pre-generate every possible combination.
Personally, though, I've been migrating to "SQL calls" and "some support code to manage the rows coming back" even when not using Go. ORMs are this enormous pile of complexity, and it's amazing how easy it is to recover the vast bulk of their utility just by writing a bit of SQL. Use a decent SQL generator (as opposed to bashing strings together) and you're even closer. By no means is it a "full replacement", but I'm increasingly of the opinion that the costs of ORMs tend towards the staggering and the benefits minimal, for any nontrivial project. Possible exception for the really good ones that have been developed for a long time, but most of the ones used in the open source world are pretty dubious, IMHO.
Since you are the main force behind HTTP in rust, when do you think it (and rust) would be ready ?
You just started on Teepee and it seems like there are lots of breaking changes on rust itself every week so that's not really inciting me to check it out for now.
That talk looks really nice too, a shame it's in several months.
There are a few factors at work here. I hope to be able to secure some form of backing to allow me to work on it more (as it is, I’ve been taking Thursdays off to work mostly on Teepee). If anyone is interested in sponsoring me to work on it, I’m all ears! If I get backing things will happen much faster, to the level where I would expect to be able to write “ARGUABLY.” (though still not “Yes!”) on arewewebyet.com by approximately the end of this year. If not, it will probably take at least six months longer.
I’m definitely in with Rust and HTTP for the long haul. Hang round, things will get better.
The biggest thing is the lack of generics. That alone is enough to absolutely destroy any plans for a fancy ORM. Any such thing will end up using interfaces with type assertions everywhere.
(unintentionally) Mutable state passing over a concurrency boundary is a compile-time error in Rust. Two threads cannot mutate the same data unless you explicitly mark it as such, and by doing so, you'd force it through a mutex. This basically means data races are impossible.
We can also end up with things like HTML templates compiled into your binary and the HTML validated at compile time. Even things as precise as type checking on something like <time datetime="{{ time }}"> can be managed with Rust. And I intend to.
I’ll be talking about how some of these sorts of things can work out at Strange Loop this year: https://thestrangeloop.com/sessions/fast-secure-safe-the-web....