Hacker News Reader

Comment by tptacek | Hacker News Reader

So far as I can tell, if you want a fancy ORM, you're using a mainstream web language like Ruby or Python. Golang is obviously more mature on the HTTP serverside than Rust, but it is nowhere close to Rails, and is particularly weak on persistence. My understanding is that the same is true of Clojure, too.

View on HN

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.

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....

I think you mean Go can't do a fancy ORM because of it's strong type system?

No, as compared to Rust's type system, Go's is pretty unsophisticated.

No, I don’t. While a strongly-typed language, Go’s type system is very weak compared with one like Rust’s.

While I'm naively familiar with Go's type system I'm not at all familiar with Rust's, so i'll defer to you on this...

That said, could you explain how Go's type system is weaker than Rust's?

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.

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.

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.

Are you seriously suggesting that a statically typed language without generics can't do ORM?

What most mean by and expect of an ORM—yes.

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.

You can do it with code generation, though, right?

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 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.

[1] https://github.com/droundy/gotgo

The most popular current ORM is written in Ruby. I find your argument hard to buy.

I look forward to trying to convince you! ☺

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

http://ocharles.org.uk/blog/posts/2013-12-06-24-days-of-hack...

More in-depth interactive tutorial:

https://www.fpcomplete.com/school/starting-with-haskell/libr...

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.

Continue the good work !

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.

> Go can’t do a fancy ORM because of its weak type system.

I don't understand what the type system has to do with building a fancy ORM. Do you mind elaborating?

Speaking of interesting things you can do with type systems for database interaction, have you looked at the sqltyped library for Scala?

https://github.com/jonifreeman/sqltyped

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.

IOW, he used strong in a colloquial manner rather than in a formal manner. Not wrong, but definitely confusing.

Any links to more info about Rust compiler plugins? That sounds really interesting.

http://blog.burntsushi.net/rust-regex-syntax-extensions

> 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?).

For Clojure, some pretty good web frameworks (with ORM and everything) are starting to pop up [1] [2] [3] [4], but they're still early revisions and thus are prone to bugs and security holes [5].

However, due to the JVM nature, one could use some of the well-tested and well-defined Java Web Framework from Clojure (with a lightweight wrapper, of course). I'm not really sure if people are actually doing that in production, though. [6] [7]

[1] http://caribou.github.io/caribou/docs/outline.html

[2] http://hoplon.io/

[3] http://www.luminusweb.net/

[4] https://github.com/pedestal/pedestal

[5] https://news.ycombinator.com/item?id=7472841

[6] https://github.com/apache/tapestry-5/tree/master/tapestry-cl...

[7] https://github.com/jblomo/heion

>My understanding is that the same is true of Clojure, too.

Clojure has Korma[0], Common Lisp has Crane[1] and Integral[2].

[0] https://github.com/korma/Korma

[1] https://github.com/eudoxia0/crane

[2] https://github.com/fukamachi/integral

C#. Seriously Microsoft is not completely without merit - there's a lot to like about Entity Framework and C#.

It's fast, expressive, and the modern Mono+ASP.Net web-stack is open-source (older stuff is still proprietary).

clojure can use all the jvm ecosystem as a fallback (if the native solutions are not up to the task).

Or you could use GWT and have an extremely mature server-side language/ORM/everything-else, and a rich web client, all written in the same language and sharing the same class model.

Reply on news.ycombinator.com