Hasura raises $9.9M to simplify GraphQL - <AUTHOR> https://techcrunch.com/2020/02/26/hasura-raises-9-9m-series-a-to-simplify-graphql-for-developers/ <comment><USER3> This is fantastic to see. First time I tried out Hasura back in late 2018 I was AMAZED.

After going through multiple different stacks such as MeteorJS, Firebase, building my own REST/GraphQL API etc. Nothing really felt right.

That was until I found out about Hasura.

I actually had to assemble a quick meetup at the co-working space I was on (true story) to show everybody this software. Hasura Tweet: [https://twitter.com/HasuraHQ/status/1068145251267895300?s=20](https://twitter.com/HasuraHQ/status/1068145251267895300?s=20)

They were all amazed and many use Hasura in production today in their apps.

For myself, I was so enthusiastic about Hasura and I always had Google Firebase in the back of my mind. Google Firebases DX is really good. I really liked it. But I did not like their tech (noSQ / REST / vendor lock-in).

So, I decided to start [https://nhost.io](https://nhost.io).

Nhost is like Google Firebase but with PostgreSQL and Hasura (GraphQL). Right now providing database, API, auth and storage. Here is a short demo: [https://www.youtube.com/watch?v=MWB5RXzlJM8](https://www.youtube.com/watch?v=MWB5RXzlJM8)

I feel very fortunate to be able to work with such awesome open source software and the success of Hasura makes me so happy, because they are, as mentioned in the comments field before me, a game-changer!

<comment><USER4> Just tried hasura, it is amazing to get all crud graphql apis out of box.

How do we add business logic ?

Folks @hasura, where do we learn about haskell ? any helpful pointers much appreciated.

<comment><USER5> I'm running a full production algorithmic trading platform, and our frontend interactions are handled by Hasura. For me, the appeal was in writing all the business logic as Postgresql triggers, which (provided they're written as true SQL and not plpgsql), scale beautifully with load. Hasura has a real appeal when you're keen to do your important logic in SQL.

Check out the result here: [http://www.hedgecheap.com](http://www.hedgecheap.com)

</comment></comment></comment><comment><USER6> Some major players in the "GraphQL in a box" space:

[https://www.graphile.org/postgraphile/](https://www.graphile.org/postgraphile/)

[https://hasura.io/](https://hasura.io/)

[https://www.prisma.io/](https://www.prisma.io/)

There are plenty of "REST API in a box" solutions as well:

[https://github.com/PostgREST/postgrest](https://github.com/PostgREST/postgrest)

[https://github.com/prest/prest](https://github.com/prest/prest)

[https://resthapi.com/](https://resthapi.com/)

<comment><USER7> I ultimately chose Postgraphile over Hasura. Mostly because the Postgraphile codebase seemed way hackable, written in TS/JS with a plugin architecture. I've tried some Haskell and that's just a whole nother world I don't have time to learn. So far it's working great for me.

<comment><USER8> FWIW, I went the other way, mostly because I found the GraphQL queries that I wrote in Hasura to be much nicer to read than the equivalents that I got with Postgraphile.

<comment><USER9> Interesting; can you provide an example? Sounds like a nice way to compare various approaches to GQL queries, and general best-practices...

</comment></comment></comment></comment><comment><USER10> Hasura is a game-changer. I'm never writing CRUD backend apps again by hand.

Combine Hasura (automatic GraphQL on top of PostgreSQL) with React Admin (low code CRUD apps) and you can build an entire back office admin suite or form app (API endpoints and admin front end) in a matter of hours.

This adaptor connects react-admin with Hasura: [https://github.com/Steams/ra- data-hasura-graphql](https://github.com/Steams/ra-data-hasura-graphql)

Here's a reference application I put together: [https://github.com/cpursley/react-admin-low- code](https://github.com/cpursley/react-admin-low-code)

<comment><USER11> Django has had an automatic admin site since 2006 or earlier, this isn't a game changer for me.

<comment><USER12> These aren't the same things. Hasura is not an admin interface, although it provides something like one. It's an application API.

The django admin interface is not usable by a frontend as an application API.

Django requires you to "meta-model" you have to write Python classes that map to your tables, this is usually duplicate work.

Django's ORM must support many databases, so it produces "least common denominator" SQL and is (stock) oblivious to Postgres' many enhanced data features, you are forced to use various community sourced extensions to get access to features that have been in postgres now for many years.

Django's security system is django only. You are forced to go through django for access control across your business. Eventually this abstraction leaks, and someone starts logging into the db from some other framework and now you have two problems.

This is my opinion and I'm sure I'll get downvoted for it, but Django, Rails, Node, all the Java frameworks, all the meta-modeling and NIH syndroming, are all utterly obsolete. Everything they do can be done in 99% SQL by a data scientist with the help of a competent DBA. "Web application programming" is going to go the way of the dodo bird and devs who don't start learning higher level skills like complex SQL, statistical modeling, linear algebra, and to either be a competent DBA or learn how to treat them fairly with be the first batch of programmers "automated out of a job" by tools like Hasura.

<comment><USER13> > Django requires you to "meta-model" you have to write Python classes that > map to your tables, this is usually duplicate work.

You don't have to duplicate any work because you don't actually have to write any raw SQL, since it all gets translated by Django. So yes, there's an extra layer of abstraction there, but no duplication on the developer's part.

> Django's ORM must support many databases, so it produces "least common > denominator" SQL and is (stock) oblivious to Postgres' many enhanced data > features, you are forced to use various community sourced extensions to get > access to features that have been in postgres now for many years.

Practically every Django release adds support for more and more database- specific features out of the box, to the point where I don't remember the last time I had to use a third-party library to take advantage of a PostgreSQL feature. But even if you do, so what? It's no different than using a Postgres extension.

The HUGE advantage that ORMs like Django, Rails, etc have over writing raw SQL is their composability. Django provides lots of tools that make it VERY easy to reuse code relating to models and querysets, whereas SQL is notoriously difficult to keep DRY. And this issue gets significantly worse when you start to pull in data that lives outside of the DB.

On top of that, there is the more obvious issue that good DBAs are rare and expensive compared to Python/Ruby/whatever engineers.

> Django's security system is django only. You are forced to go through django > for access control across your business. Eventually this abstraction leaks, > and someone starts logging into the db from some other framework and now you > have two problems.

I do completely agree with this, and I think it's Django's weakest point by far. But you can always forego the ORM's integrity/trigger features and add those at the database level in your migrations.

> This is my opinion and I'm sure I'll get downvoted for it, but Django, > Rails, Node, all the Java frameworks, all the meta-modeling and NIH > syndroming, are all utterly obsolete.

Hasura and related projects are really great, don't get me wrong, but this is outright FUD. There are pros and cons to both approaches, and to claim that one is "utterly obsolete" is nonsense. There are lots of situations in which turning the database into your API just doesn't make sense.

<comment><USER12> > You don't have to duplicate any work because you don't actually have to > write any raw SQL, since it all gets translated by Django. So yes, there's > an extra layer of abstraction there, but no duplication on the developer's > part.

There is still some duplication of effort, for example when you change the model, yes django will create the migration script for you, but you always have to verify it and often change it especially when you're merging branches. And since the migrator only supports a subset of postgres' DDL abilities, even simple things like renaming objects, or applying advanced indexing techniques you often have to write hand sql migrations anyway, which require you knowing sql, so why not just do all in sql?

> Hasura and related projects are really great, don't get me wrong, but this > is outright FUD. There are pros and cons to both approaches, and to claim > that one is "utterly obsolete" is nonsense. There are lots of situations in > which turning the database into your API just doesn't make sense.

It was a strong statement of an unpopular opinion, but FUD is a fundamentally dishonest statement, and I did clearly prefix my statement with "This is my opinion and I'm sure I'll get downvoted for it". As someone who knows my opinions well you know I honestly believe it. But that's ok I appreciate you keeping me on my toes when the coffee gets me in an agitated state!

That being said, I still do believe it. I do pick on Django pretty hard, but I feel the same way about many of the Python frameworks to a certain degree and the "web application framework" pattern in general. Django is just the one I have seen the most bloviated circumlocution of code to do simple tasks with, and often when I have run into problems with Django, it was usually Django's fault (ahem, autocommit) not the developers. It's a classic foot gun.

A recent example I have had to boggle at, a half dozen AppEngine microservices, cross calling each other with http RPC all autocommiting to 3 different postgres databases with less than 100k rows of data total. The microservices were entirely responsible for maintaining referential integrity entirely defeating the point of using postgres in the first place.

The whole thing could have been a set of simple functions, much of the heavy lifting could have been done with some simple triggers. But instead "microservices". That worked ok when there was only one instance of each service, but then when app engine scaled up it became a knot of race conditions.

<comment><USER13> For the record, I do agree with your general sentiment that many of these abstraction layers are unnecessary, and in many ways harmful. Especially when it comes to data integrity, trying to enforce constraints and triggers at the application level is always going to be clunky and error prone, and monolithic frameworks like Django and Rails actively encourage you to do everything at their level and give you many ways to shoot yourself in the foot. But I also don't think Hasura and Postgraphile and related projects are the silver bullet. Why can't we have something in the middle? How about a web framework that leaves data integrity up to the DB and just gives you an easy way to "glue" together bits of logic and queries, and do migrations, etc? Or even just use Django/Rails/whatever but don't use the footgun features? At least then, if/when you _do_ need to scale (in any sense of the word) past what a relational DB can offer you, you can easily do that instead of trying to shoehorn everything into the DB.

Aside: I'm working on a GraphQL library for Python that I hope will fulfill these goals, but development on it has stalled due to lack of time. Hopefully I can pick it up again soon.

FUD may have been strong, but in general I detest when people decry entire categories of technology as being "wrong" or unfit in an absolute sense (or, conversely, tout a technology as a silver bullet), when in fact everything has its tradeoffs and there are good reasons to use almost anything. Understanding those tradeoffs is vastly more important than searching for the universal answer to everything.

PS: Hope you're doing well! :) Your contact info isn't on HN, but email me if you want to get coffee/lunch sometime!

</comment></comment></comment></comment></comment></comment><comment><USER14> I looked at Hasura a while back, and to be honest I thought it was the antithesis of all the things I loved about GraphQL so I moved on. Perhaps someone can convince me differently?

The thing I love most about GraphQL is that serves as the perfect _contract_ layer between the front end and the backend. A very productive development method I've used is to have the front end and back end teams agree on the GraphQL types (often times having the front end folks actually write the types), quickly mock things out, then have the front end folks go implement the front end and the back end folks provide the real resolver implementations.

The things I love about this is that it really simplifies and hides the backend details from the front ends. With things like Hasura, you are _directly_ exposing your DB schemas to the front end, essentially tightly coupling them together. That has always been a recipe for disaster whenever a project gets sufficient scale or complexity in my opinion.

Again, it was a long time ago when I dug into Hasura, but this whole concept of "Directly expose my DB schema as GraphQL" is the exact opposite of what I love about GraphQL in the first place.

<comment><USER15> Do you really need to decouple frontend and backend in the first place?

Why not separating concerns instead of separating technologies? Tight coupling of UI with database but decoupling of e.g. admin UI/backend from end-user UI/backend.

I'm the author of a Node.js RPC implementation ([https://github.com/reframejs/wildcard- api](https://github.com/reframejs/wildcard-api)) and the idea is the exact opposite of what you are prescribing: highly coupled frontend business logic with database schema/queries. Makes things so much simpler, in my experience.

</comment></comment><comment><USER16> After trying Hasura, Prisma, and PostGraphile, my conclusion is that PostGraphile is way ahead of all this. Please all have a look at PostGraphile, it is amazing, even more than Hasura!

<comment><USER17> Can you elaborate?

<comment><USER16> There are so many good reasons to use it that I think I don't make it justice. But here a few pros of graphile:

\- it is made in typescript and can be integrated as a library directly in a JS project

\- it is very easy to extend with plugins

\- it is very easy to customize and run on an existing database

\- it is « database first » in the sense that the schema is created based on the DB schema and some additional annotations

\- it is really free open source software with a non-VC backed business model

\- it is extremely performant

<comment><USER17> I don't have any horse in the race but other than the "it is made in Node" everything else applies to Hasura (except the VC thing obviously).

Do you have any other point to sustain this comment of yours?

> _my conclusion is that PostGraphile is way ahead of all this_

<comment><USER16> I mean:

\- Like Hasura, has ALL the features of Hasura

\- BUT really FOSS with no VC funding, supported through Patreon by a super nice team.

\- AND I have all the source, in the same language than the rest of my stack, the language that my developers know

\- AND it does not require to run yet-another-microservice but is just part of my graphQL server

\- AND it is extensible through plugins that blend seamlessly in the server (unlike Hasura where I see no sign of plugins, and I don't want to write plugins in Haskell)

\- AND it supports native, super-fast Postgres Row-Level-Security instead of rolling their own!

That is very clearly compelling enough to support my conclusion, from my point of view.

Let me also mention that I have been burnt by another VC-funded GraphQL server company, namely Prisma, which left us stuck with an old, non-maintained buggy version which is near impossible to patch and build ourselves, while they work on their pie-in-the sky Prisma v2 which is totally the wrong direction in my opinion.

We jumped ship from prisma, considered hasura, but went for graphile and love it!

<comment><USER17> Don't get me wrong, I agree with most of your points as I'd prefer to work with Node than Haskell, but I still don't see how it is "way ahead" of the other options outside of personal preference.

Unless I'm missing something, Hasura is FOSS too.

[https://github.com/hasura/graphql-engine](https://github.com/hasura/graphql- engine)

True, Hasura does not have plugins (AFAIK) but you can extend it's funcitonality via webhooks and PG views.

As for authorization it may give them more flexibility to roll their own.

Anyway, thanks for bringing up PostGraphile. I'll check it out!

</comment></comment></comment></comment></comment></comment><comment><USER18> While I like and enjoy many aspects of code generation such as this or Prisma, In real world scenario it just doesn't feel right.

Imagine a very simple scenario, you want to add some validation based on business requirements, in order to do that you have to have a server with custom endpoints or a custom graphql server (thus copy most of what hasura generates) to implement your own validation

The only situation in which I consider this a really good solution is in a CQRS system where the database attached to hasura is read only via graphql and the data is inserted by other services making it a typesafe single source of truth to read from

<comment><USER19> Often times that's not needed if you actually use the full power of PG. CHECK constraints go a long way, and where they don't go, PG/PSQL goes pretty much a long way.

For internal or prototypical use cases, that can be totally sufficient, however you're right that you'll eventually want good error messages, observability and much more other custom logic.

What I'm still searching for is something that works like Hasura or PostgREST and then offers "upgrades", first via configuration, later via custom code hooks.

That would be pretty awesome from a migration path perspective.

<comment><USER20> Check out Postgraphile, it allows you to start off with introspection, then customise it with comments, then add custom bits in node.

Both Hasura and Postgraphile also support schema stitching from what I know, so you should be able to extend it that way also (more complicated obviously)

</comment></comment></comment><comment><USER12> A huge benefit that tools like Hasura, Postgraphile and PostgREST provide is using the native in-database row level security model.

Consider Django. Your django app logs into the database typically as a user with elevated permission that is a superset of all permissions required by your users. Postgres has no idea that django is acting on behalf of many users, all it sees is this django super-like user. If an attacker roots your Django instance, they have the same privileges. If your PHB decides to "help" and log in with creds found in the source code, the damage could be catastrophic.

Products like Hasura, Postgraphile and PostgREST switch databse roles on the fly per-request. The user that these tools logs in as typically has almost no privileges. You must be the bearer of a valid JWT token to elevate privileges, and then you only get to the level of the user you stole the token from. There is NO super-like user.

<comment><USER21> > A huge benefit that tools like Hasura, Postgraphile and PostgREST provide is > using the native in-database row level security model.

I agree with your overall comment. Note that Hasura doesn't use the native row level security in Postgres. They implement the layer themselves. There are two reasons: 1) Hasura is older than the first release of Postgres that included the row level security feature. 2) Their implementation scales better when there are a lot of users subscribed to the same GQL Subscription. When using row level security, every user's query result looks different, so they need to create a database subscription / polling for each user GQL Subscription. Their implementation allows them to have a single PG subscription (well they mostly do polling), get all the data back, then strip down on the way out to the GQL subscribers.

</comment></comment><comment><USER22> I tend to prefer PostgREST's[1] syntax over GraphQL for when I need flexible client-side queries. It's way more intuitive for me.

[1][http://postgrest.org/](http://postgrest.org/)

<comment><USER23> How do you make subscriptions work with PostgRest?

<comment><USER22> Probably by returning an endpoint and a token to a service that will handle the perpetual session.

The scope is smaller than GraphQL, but some of the interesting benefits - <USER2> smarter and more optimized requests - are available with PostgREST.

</comment></comment></comment><comment><USER24> I tried Hasura in the past and unfortunately found it unsuitable for our auth requirements. There is no way currently to hook into their authorization system, you get extremely basic RBAC and if that isn't good enough for you too bad.

For example we currently are required to talk to some external auth services (depends on the customer) and fetch the users permissions based on that, (e.g. user can READ notes, and WRITE notes but not delete NOTES). At the time we had an extremely simple express middleware that handled this.

Also the entire idea that i need another GraphQL or rest server to do any sort of custom validation/custom actions made me do a double take and more or less killed any interest to me.

We ended up using NestJS with their GraphQL tooling and objection.js and never looked back. Ironically the adoption of the GraphQL version of our API compared to Rest is almost 0.

<comment><USER25> Hasura's authz is whatever authz you can derive from the data within your database or from the claims embedded in the authn token. If you have a table that contains the claims for each user, then you can reference that in the authz rule for any other table/view/function. READ notes if user.is_note_reader = true.

We're working on making it easy to integrate resource claims and rule engines that are external as well (make an IO call instead of embedding the rule in the SQL query itself). The good news is that it is possible to do at the Hasura layer because Hasura owns the RBAC so we'll get to it soon enough :)

Over the last few months, we've seen users flip from their custom GraphQL servers to using Hasura because of the reduction in code/maintenance that Hasura brings for their use-cases. Especially when you have a large number of tables. Being able to manage authorization rules at a "type" level instead of a "resolver" level also makes things convenient.

We've also started work on making it easy to integrate REST APIs for custom logic (esp writes) which also helps skip a bunch of GraphQL/authz boilerplate: [https://blog.hasura.io/introducing- actions/](https://blog.hasura.io/introducing-actions/)

<comment><USER24> Unfortunately we do not have these claims defined in our auth token or the datasource hasura is attached to. We have an external session cache service in Redis. If the user isn't cached we need to hit an internal API to attempt to fetch this information for us and return it to us. No user information is stored in our auth token/database.

Actions look painful, i don't want to write and maintain microservices just to do simple actions. I just want to be able to write code and handle the hook around the function. Also from the link it only seems like actions occur AFTER something happens, i need the ability to run before changes are persisted.

</comment></comment></comment><comment><USER26> It's definitely cool to see Haskell projects getting used in industry. I am a big fan of Hasura and the value it gives in the GraphQL space.

</comment><comment><USER27> I settled for Hasura in a prod app after trying Postgrest, Postgraphile and Strapi. I believe its a permanent addition to my stack.

The main reason for me was RBAC. Converting db-to-api is not that hard but providing access control almost always requires some form of middlewares. Hasura does RBAC very well.

Another feature that I haven't deployed but find useful is webhooks. You can trigger webhooks as your data changes.

I do need a server to handle object storage, email and cron so it's not a 100% there, but I can see the appeal of rapid APIs at low cost.

Also subscriptions are <3.

All the best to the Hasura team.

<comment><USER7> What made you choose Hasura over Postgraphile? RBAC is a postgres feature, not sure if that would affect the decision?

<comment><USER28> Not the parent but we went with Hasura over postgraphile because they do RLS outside of the dB. It allows them to load the data for all clients subscribed in a single query. Also the subscription story is better (from memory).

</comment></comment></comment><comment><USER29> One thing that bothers me about systems like this is the underlying assumption that database architecture always reflects the presentation. But what if ti doesn't? I am looking at the Hasura docs and all it really says is "we will generate everything for you based on your database schema and here is the way we do it". But what if I don't want some tables to be exposed? What if I want to expose custom queries instead of tables?

I feel that products like Hasura and postgrest would be a lot more useful if there was a way for me to specify a list of data sources on one side and get a fully formed GraphQL or REST service on the other side rather than going "I know what you need better than you" route.

<comment><USER30> Data-driven architectures are very relevant, in particular in a corporate / business environment.

I found all the answers in the docs.

A SQL Schema can carry a custom query, it's called a view.

A SQL Schema can carry a custom algorithm, it's called a function or a generated column.

You can always deactivate permissions on a table to not expose it, my bet is that your backoffice will need to though.

On top of that, Hasura supports custom resolvers (code driven endpoints).

Finally you can stitch 2 GraphQL schemas together. It doesn't have to be one size fits all. So even if only 50% of your app can fit in the model of Hasura, you can always mix and match. It's still 50% that will be up and running in minutes.

<comment><USER29> > A SQL Schema can carry a custom query, it's called a view.

This is not feasible. I might not have enough access to create views. I might not have access to create functions. I cannot deactivate permissions if I only have a single access account and other systems use it already. You cannot assume that I have full control of the database or that I can easily make changes to the schema.

But this is not all. I am working on a web backend project on daily basis. I would love to offload some basic CRUD operations to something like postgrest or implement GraphQL with something like Hasura, but I need a way to a) define table and field name mappings b) define what tables are accessible b) define what columns are visible c) define what nested relationships are allowed d) define actions that need to happen on update/insert/delete operations (i.e. push a message into a queue every time a record is deleted from table T) If I could do all of this, I could implement about 50% of my web service and it would be useful.

<comment><USER30> Please read the docs. All your fears are addressed in the doc. The permissions are managed on the Hasura side.

Concerning the lack of sufficient privileges to create a view, you can always either ask for permissions, or create a second databse with FDW. Apparently reading your second paragraph you are allowed to create tables, so it sounds like you'll also have enough privileges to create views.

I don't understand your point on your second paragraph. You can do all of that in Hasura, it's in the first tutorial, but also the doc. Please note we are talking GraphQL so there is no CRUD. It is a query + mutation model. More flexible and powerful than CRUD.

</comment></comment></comment></comment><comment><USER31> Is it a good idea to base your GraphQL schema on your database schema?

Isn't the point of GraphQL to decouple your interface (who should not break) from your backend implementation details?

<comment><USER12> > Is it a good idea to base your GraphQL schema on your database schema?

You don't. Hasura (and Postgraphile and PostgREST) employ in-database modeling tools called views. Views provide the same modeling abstractions that ORMs provide.

[https://www.postgresql.org/docs/12/sql- createview.html](https://www.postgresql.org/docs/12/sql-createview.html)

A view is a canned query with a name, and when you get down to it, all an ORM is doing is producing, usually poorly, a query from a named abstraction. Same thing. So why have two pieces in two languages when you can have one?

> Isn't the point of GraphQL to decouple your interface (who should not break) > from your backend implementation details?

Views provide the same or better decoupling. They database is aware of them, they are type checked, you can't even make a view that references an unknown column, for example.

</comment></comment><comment><USER32> Congrats to the Hasura team!

Hasura is truly a marvelous piece of software when it comes to rapidly prototyping and getting things out into production. We discovered Hasura a couple years back at my previous company when it was still in beta and we were amazed with how easily we could automate most of our CRUD logic. I will definitely be using Hasura again when the time comes around.

On a more recent note, I currently have a client who's prototype was built with Hasura but one of their requirements was to migrate to AWS and use as many of the PaaS offerings as possible. We ended up using AppSync[1] and it is fairly impressive. I highly recommend anyone who is stuck in the AWS ecosystem to check it out. AppSync integrates with a lot of other AWS services (Cognito, S3) very easily and allows you to use Dynamo/Aurora/RDS/Elastic as data sources. On top of this, you can also use Lambda to implement resolvers that need more intense business logic, making the service incredibly powerful.

[1] [https://aws.amazon.com/appsync/](https://aws.amazon.com/appsync/)

<comment><USER33> We used appsync at my company and switched to a more classical approach of handwritten crud, a REST Api, a RDS (not entirely sure how well you can use them with appsync) away from dynamodb. Appsync was just not mature enough, had bugs and severe limitations. Without someone in the team who really knows Appsync, I would recommend against it and towards the tech you know.

<comment><USER32> What was the biggest hurdle you ended up facing that ended up being the dealbreaker for your team?

I think for us, the biggest issue so far has been figuring out some of the more involved Velocity templates as the documentation is fairly sparse and testing them can be a pain. Thankfully this project isn't too business logic heavy but due to time constraints, we ended up writing Lambdas for templates we could not figure out quickly.

</comment></comment></comment><comment><USER34> I'm curious if anyone here has compared Postgraphile to Hasura? My personal difficulty in implementing these is that there aren't good source control and code organization tools for SQL and managing rollbacks and rollforwards in a sane way.

(And a way that doesn't require writing rollbacks, which sometimes aren't even possible anyway).

<comment><USER35> I've done exactly that with a sample food delivery project. Same frontend, but two different backends (one with Hasura, one with Postgraphile).

Feel free to check it out: [https://github.com/sastraxi/great- bear](https://github.com/sastraxi/great-bear)

<comment><USER34> This is very cool, as is your git-like tool for PG! Thanks for sharing.

</comment></comment></comment><comment><USER36> I want to bet there were zero Greek VCs in the round :D (in Greek, "hasura" means huge loss, especially in investing context)

<comment><USER37> Odd. Google Translate says it's "encountered"

[https://translate.google.com/#view=home&op=translate&sl=el&t...](https://translate.google.com/#view=home&op=translate&sl=el&tl=en&text=hasura)

<comment><USER36> You're looking something more like [https://translate.google.com/#view=home&op=translate&sl=auto...](https://translate.google.com/#view=home&op=translate&sl=auto&tl=en&text=%CF%87%CE%B1%CF%83%CE%BF%CF%8D%CF%81%CE%B1)

The spelling "hasura" is in what we call "Greeklish", i.e. Greek in English (ASCII, really) characters. This was common in early 2000s, where utf-8 support was not everywhere (web, SMS, etc) and writing in Greek characters had a high chance that the recipient would receive mumbo-jumbo.

</comment></comment></comment><comment><USER38> I often miss graphql features when working with rest APIs. But switching over seems very much not worth it when no one in the organisation knows graphql.

I feel like graphql would be much easier to adopt of it just sticked to rest conventions as much as possible. Like have the query language be pure JSON.

It should even be possible to design it so that you could make drop in replacements for most of existing rest APIs.

<comment><USER18> GraphQL is much easier to pickup and get productive than most people think, most of the times all you have to do is writing resolvers (functions) instead of http handlers (functions)

On the client side is the same, following any getting started guide can explain 90% of what you need to know in a single day

<comment><USER39> Client side GraphQL is harder than REST, though I wouldn't define it hard in general. Whereas with REST one only needs to update the data model for the response, GraphQL also requires that the request itself is also updated. It gets more complex if the client wants to take advantage of hashed queries and now there's all this work needed to upload the queries to some backend service. This is from my own experience — I haven't worked with Apollo to know how much of this process is simplified for you.

<comment><USER18> The situation you are referring to is actually a great plus, If you change the data model in you backend, you client consume it and thus depend on it, so you still have to change the frontend code anyway, knowing exactly what you can ask and how it will come back makes it a very powerful developer experience with a lot of test that don't need to be write thanks to tooling around a type system and a faster feedback loop.

<comment><USER39> Oh, I'm not suggesting that it's a worse way to do web requests at all. I genuinely enjoyed working with GraphQL despite all the build/CI headaches it can potentially cause. I was really addressing the sole point of difficulty of working with REST vs GraphQL and I'd unquestionably say REST is easier. It's not a statement of which one is better or worse.

</comment></comment></comment></comment></comment><comment><USER40> I'm excited anytime a technology comes along that makes for great user experience AND developer experience. I can demonstrate the value that Hasura provides to either side in minutes.

The subscriptions are particularly interesting to me, I've never seen anything else that makes web sockets so easy to implement. I'm very optimistic for their future.

</comment><comment><USER41> Not a startup but still a very feature rich GraphQL to SQL compiler service works with Postgres and YugabyteDB. Written in GO. [https://github.com/dosco/super-graph](https://github.com/dosco/super-graph)

</comment><comment><USER42> I've been using postgraphile over hasura for while, initially because of some JWT business. That thing rocks. RBAC and JWTs are a killer feature for public facing stuff.

Congrats to the folks at hasura for the raise, long live postgres and graphql.

</comment><comment><USER43> Can someone explain to me how this differs from Apollo? Is it that it has a tighter integration with the DB layer?

</comment><comment><USER44> Firebase, React and Hasura let me set up new app ideas in like negative time. Hasura is especially amazing because of it's authentication handling and migration management.

<comment><USER3> That's super fast!

</comment></comment><comment><USER45> Tooling around Hasura is starting to mature. People have already mentioned nhost, I'd also like to point out a terraform module [0] to put Hasura on AWS

[0]: [https://registry.terraform.io/modules/Rayraegah/hasura/aws](https://registry.terraform.io/modules/Rayraegah/hasura/aws)

</comment><comment><USER15> Instead of Hasura and GraphQL, you can use RPC and directly write SQL queries to retrieve and mutate data.

One way to think about this is that with RPC you remove the whole API layer and directly write SQL queries instead, while permissions are defined programmatically on a case-by-case basis. This is much simpler than Hasura!

For Node.js there is [https://github.com/reframejs/wildcard- api](https://github.com/reframejs/wildcard-api).

For other backends you can implement JSON endpoints ([https://github.com/reframejs/wildcard- api/blob/master/docs/b...](https://github.com/reframejs/wildcard- api/blob/master/docs/blog/rest-rpc.md#json-endpoints))

While scaling to a large company, you progressively migrate from RPC to GraphQL (with or without Hasura).

<comment> miles-po I appreciate your zeal in marketing this product, but you're comparing apples and oranges. You are speaking of the ease of how you can write SQL queries. With Hasura, Postgraphile, Prisma, and their generated REST counterparts, you aren't writing any SQL queries. You are creating your database schema and then launching the respective apps. Obviously some customization will be necessary since almost no app are 100% CRUD.

But I took a look at your RPC tool, and it adds a lot of boilerplate work. This RPC boilerplate is exactly why alternatives like Hasura, Prisma, and Postgraphile exist.

Also you can't add an RPC layer and magically call it simpler. If you add Postgraphile, Prisma, Hasura in front of the database, it is just as simple, just as much a layer on top of the database. Only in this case you're writing to a published open spec (GraphQL) so the client doesn't have to know if it's talking to a relational database, a Redis cache, a REST data server, an in- memory data model, or whatever.

Your tool on the other hand is just another vendor-specific ORM or manual query engine. If that works for you, great. It is not a good alternative or answer to what is being discussed here.

<comment><USER15> > you're comparing apples and oranges

I agree, Hasura and Wildcard have different goals. Still, the merits of each tool can be talked and discussed about.

> you aren't writing any SQL queries. You are creating your database schema > and then launching the respective apps. Obviously some customization will be > necessary since almost no app are 100% CRUD.

I'm not against ORMs. On the contrary, I've always been (and still am) looking for an ORM that takes care of 90% of queries (basic CRUD queries) while preserving the full power of SQL for the 10% of queries that require more powerful queries. Most ORMs do that part wrong and make writing custom SQL queries complex. I really want such ORM and I even tinkered and implemented one for a hobby project.

Also I believe that an ORM to be a wonderful combo with Wildcard, such as Prisma. (Prisma is pretty much an ORM and can be used without GraphQL.) I would argue that Prisma + Wildcard to be superior to Prisma + GraphQL. (With the exception of when you need need third-party devS to access your data -- you then need a generic API with either REST or GraphQL.)

> But I took a look at your RPC tool, and it adds a lot of boilerplate work.

I couldn't disagree more; Wildcard is deliberately designed to abstract away as much boilerplate as possible. I'd be more than happy to see a concrete example that proves me wrong. My guess is that you won't prove such example because there virtually isn't such.

> This RPC boilerplate is exactly why alternatives like Hasura, Prisma, and > Postgraphile exist.

That's a vague sentence and doesn't make any sense to me.

> it is just as simple, just as much a layer on top of the database.

Wildcard is only a couple of KLOCs while Hasura & co large and complex tools developed by teams and backend by big VC money.

You can read Wildcard's whole documentation in 10 minutes. Reading Hasura's entire documentation is _much_ larger than Wildcard's.

It speaks volumes about how much simpler Wildcard is in comparison to Hasura.

It's weird to say that Hasura is as simple as Wildcard.

> the client doesn't have to know if it's talking to a relational database, a > Redis cache, a REST data server, an in-memory data model, or whatever.

Such decoupling is mostly useful for very large projects. The vast majority of apps out there don't need such decoupling. Separation of concern is important, but based on _concern_ not on technology.

> Your tool on the other hand is just another vendor-specific ORM or manual > query engine.

It's weird to call an RPC implementation an "ORM" or "query engine". I'm not sure how an Software Engineer is able to mix up "RPC" with "ORM".

Honestly, your whole post is weird to me, I'm not sure what your motive is. You seem to try to put down an open source project that is being developed by someone in his free time and without any remuneration. That's disgusting and without taste. If you only have a lack of tact then I apologize for my words.

Just to be clear I do like many aspects of Hasura. The problem is that, 95% of the time, GraphQL is not being used in the right situations. GraphQL when used correctly is a lovely tool. (Basically GraphQL = generic API for third parties. If you don't need third parties to access your data then you don't need GraphQL.)

<comment> miles-po Okay, let's spell it out. Your tool requires that you specify endpoints. Then call the ORM or make manual SQL queries. In the example, you have a Todo object.

Do you see the code right here? ``` endpoints.createTodoItem = async function(text) { ... } ``` You've already missed the point of tools like Postgraphile et al when you propose tools like that in a discussion like this. You don't have to write endpoints or even GraphQL schemas _at all_. You literally just start the tool, passing in the database connection info, and start using it. That's it. That's all. That's what I meant by simple, not how many lines of code they required (which is not much of a benchmark). That's what I meant by apples and oranges. I'm sorry you saw that as an attack, but it's true. It is not just a matter of replacing GraphQL for RPC as you suggest. Or REST for RPC. Simplicity from the point of view of the user, not the server parsing code. Your server is effectively writing a data schema to be consumed by a client. These GraphQL tools write the schema for you.

No code at all (other than database setup) is required to get this working. Zero. [https://www.graphile.org/postgraphile/usage- cli/](https://www.graphile.org/postgraphile/usage-cli/)

I hear you on the comment "Is your API meant to be used by yourself? Use Wildcard." However at that level, ANYTHING works. If you start with REST or GraphQL, you may not need it now, but if your project grows, you'll have to rewrite everything. Another minor nit: GraphQL does not require HTTP or even a network layer. GraphQL in and of itself is 100% transport-agnostic.

Sure you could auto-generate RPC endpoints from your database schema, but that requires a tool that does not yet exist, does it? And at that point, what advantage does it afford over GraphQL? It's not markedly more efficient. For that matter, if you wanted the most efficiency regarding RPC, why not use something like gRPC that uses protocol buffers for serialization? If that level of efficiency isn't necessary, then how can you criticize minimal protocol efficiency differences between RPC and GraphQL?

Then there's the issue of vendor lock-in. GraphQL is a spec, and a relatively simple on at that. Nothing more. Nothing less. For the most part different GraphQL backend implementations can be replaced with another vendor/implementation. REST is the same. Can the same be said of your RPC implementation? Could someone seamlessly replace it with another tool without changing _any_ client code? Who are your competitors? (Not necessarily looking to outdo you, just occupying the same spec-level niche.)

As for VC funding, Hasura just got some. Prisma has some. Postgraphile is a one-couple shop with a simple Patreon. The REST libraries don't have VC funding to my knowledge, so that comment from you was largely unwarranted and frankly rude. But more to the point, lack of funding or a development team is not an effective point. What happens to the organization using your software if you get hit by a bus? Why should they take on that risk? Sure they can take over your code since it's open source, but if they wanted to go down that road, why wouldn't they just write their own code anyway? I'm not saying you have to be a major multinational corporation, but single points of failure are not selling points to most folks whether those single points of failure be technical or social.

Lack of redundancy is a hazard. Lack of choice is a hazard. I for one am glad so many healthy competitors exist in the auto-conversion of relational databases to GraphQL.

All the best of luck to you in your RPC endeavors. I'm sorry for being harsh, but you jumped into multiple threads promoting Wildcard without in my opinion understanding what you were comparing against. I hope you find an appropriate audience and user base for it. I fear however that this isn't it for the reasons I enumerated.

<comment><USER15> I appreciate your elaborate answer. Thank you.

I'm a minimalist and as such I have a problem with complex solutions to simple problems. That's my whole point.

My dream ORM is a an ORM that is designed with a) an obsession on simplicty, b) simple ORM CRUD queries that cover 95% of the data mutation/retrival needs, c) allows you to write "native" (no)SQL queries directly for the 5% cases when you need more complex queries, and d) automatically takes care of migration for 90% of the cases.

The ORM should be trivial to understand, the documentation super small, and the ORM should get _entirely_ out of your way if you want to use your database directly without the ORM. Most ORMs out there (if not all) get these things wrong.

Hasura, Prisma & other auto-generated GraphQL tools are essentially ORMs. Unfortunately, they also get the above listed things wrong. I like that they auto-generate a GraphQL schema, that's neat. That's not my problem. My problem is that they are tightly coupled with GraphQL. That's nonsense. Because (and Wildcard is a living proof of this) _you don 't need_ GraphQL for the vast majority of apps out there. People need to understand that GaphQL = generic API = third-party devS. You don't need to expose your data to third parties? You don't need GraphQL. Period. (I hear people arguing about decoupling frontend and backend by using a generic API but that's an old and out-dated idiom, which is another topic I'd be happy to elaborate if you want.)

A simple ORM with a plugin that auto-generates a GraphQL schema? Hell yeah that's awesome. You'd then use the GraphQL plugin _only_ when you need to expose your data to third parties. That's cool.

You don't need to expose your data to third parties? Use an ORM with RPC.

RPC is _fundamentally_ simpler than GraphQL. Why on earth should I use something inherently more complex if I can use something so much simpler?

For example, have a look at how permissions work with Hasura and compare this to Wildcard. The difference is worlds appart in simplicty.

With Wildcard, permissions are written in code:

        // Node.js server

        endpoints.deletePost = async function(){
          // Only admins are allowed to remove a post
          if( !user.isAdmin ) return;

          // ...
        };

This means that you don't have to understand anything to do permissions -- simply write if statements, just like you are used to while programming other sutff.

With Hasura, you have to use Hasura's custom system of role-based permissions. What I find most annoying about these is that they are not defined in code. With Wildcard all permissions are written in the code - I can simply read them while reading queries.

I hear your arguments saying that Wildcard is new and I understand that you don't want to adopt something that is the "bleeding-edge". (From my perspective; from your perspective, experimental ;-).)

I agree that my way of promoting Wildcard on the whole Hasura thread was less than ideal, I'll improve.

<comment> miles-po In code, as long as that code is JavaScript. Looking at endpoints.getPost, assuming you pass in an id, what does that result look like? "It can look like whatever query you're making" is not a good answer. Even if you're the only developer on a project, code you wrote six months ago might as well have been written by someone else.

Let's look at a GraphQL call in terms of simplicity.

      await fetch({
        method: 'POST',
        url: 'http://server/',
        body: `mutation {
                 deletePost(id: '542543') {
                   id
                 }
               }`
      });

That's it for a client call, and I know from the query that it'll return the id of the post (if any) that was deleted.

Using Postgraphile as an example, nothing to do on the GraphQL server side beyond starting it up. In your database:

      CREATE TABLE post (
        ...
      );
      REVOKE ALL ON post FROM public;
      GRANT SELECT INSERT UPDATE ON post TO public;
      GRANT DELETE ON post TO app_admin;

Done. The issue with your approach is that different sections of code may invoke SQL that deletes data. Once a data model lives long enough, edge cases show up. By having the security model live with the data itself, you never have to worry about these edge cases. Set theory for the win! Security bubbles up from the data layer, through the app layer, to the client layer. Also means that if you have two apps talking to the same database, you are no longer required to keep those security restrictions in sync. Got one app in PHP with another in Ruby? No problem. Data security is still intact. Forgot to restrict deletes? Fix the data layer, and the security fix bubbles up. No worrying about all of the possible places that might be affected by this.

Data security at the app level is arguably the wrong level to be implementing it.

Now you may decry the complexity of a fully-formed solution, but honestly Postgraphile meets your requirements quite well. GraphQL really isn't complex on its basic level.

      query {
        post(id: 13245) {
          id
          subject
          body
          author {
            id
            name
            email
          }
        }
      }

Boom. That's the JSON that comes back—follows the structure of the query. Self-documenting. The generated CRUD endpoints cover 95% of needs. Native queries written with the database itself and exposed as functions. Migrations should be handled as either idempotent SQL DDL or repeatable sequence of files at the database level, not the app layer.

Performance-wise, I strongly doubt you'll be faster/more scalable that Postgraphile out of the box. And just because the browser isn't calling the endpoint doesn't mean that GraphQL or REST are useless. Far from it. It's absolutely not just for publicly accessible APIs. That is a false assumption on your part.

GraphQL really isn't as heavyweight as you seem to presume it is. It's just a spec. How someone implements that spec is what makes the difference. As far as request/response sequence, GraphQL is quite cheap computationally. Well documented. Only as complex as the queries you want to make. Hierarchy-aware.

You might as well argue that HTTP is too complex and inefficient; that raw socket calls are better. Why not set up an exokernel?

The reason most of us don't is that it violates the 80/20 rule. Premature optimization and all that. If 99% of the time is spent in the database doing queries and only 1% in your app, fixating on the "efficiency" or perceived "simplicity" of that 1% is a fool's errand.

</comment></comment></comment></comment></comment></comment><comment><USER46> Very excited to see this. Hasura has transformed how I build apps.

</comment><comment><USER47> Awesome to see the GraphQL community growing, there's a GraphQL Landscape of tools out there, if something is missing please contribute, the GraphQL Foundation is tracking everything now: [https://landscape.graphql.org/](https://landscape.graphql.org/)

<comment> miles-po Not clear how to add or notify anyone to add. Missing Prisma ([https://www.prisma.io/](https://www.prisma.io/)) and Postgraphile ([https://www.graphile.org/postgraphile/](https://www.graphile.org/postgraphile/)) in the Databases section.

</comment></comment><comment><USER48> Disclaimer: I work on MongoDB Stitch

This looks really cool and an improvement on Prisma! I particularly like the much less bloated schema experience (and the builder) along with the easy addition of actions. We've been working on something similar but it's great to see improvements in the UX of the space.

<comment><USER49> Do you have anything to add about Hasura? Or is this just a straight plug for stitch?

<comment><USER48> Yep, I modified my comment. I meant to put it as a sub-comment where it contextually made more sense.

</comment></comment></comment><comment><USER50> If GraphQL needs $9.9M to be simple enough for developers to actually use it, why was it invented?

<comment><USER51> GraphQL is mediocre. It's luke-warm mashed potatoes from a chain diner.

Having used it for a number of years now, I still don't know why people recommend it beyond other people recommending it. Out of the box, it comes with no batteries included. Which explains the cottage industry that popped up to support it (Apollo, Hasura, etc.). Simply making GraphQL as efficient as bog-standard REST without involving the use of half a dozen 3rd party libraries is a fool's errand.

Silicon Valley suffers great amnesia and NIH. We've had RPC forever now. XML RPC, SOAP, thousands of others that don't deserve mention. There is a reason people moved from SOAP to REST: you didn't need that complexity. (On a side note, it makes me incredibly depressed to be in this industry knowing how much time and effort died trying to make XML a thing. When was the last time you heard "XML" on Hacker News? Probably been awhile. Maybe 5-10 years now. As a piece of news that is, and not some random comment from an asshole like me.)

Requesting arbitrary pieces of data on the client side (GraphQL's seemingly raison d'etre) is quite easy with REST. So easy that it makes me curious how much brain damage the industry has to think otherwise. Creating new endpoints even? Not a big deal. Not nearly as big of a deal as writing the mountains of boilerplate to get a new GraphQL query up and running. And considering we're talking about GraphQL, it's most likely going to be the same team members working on both sides. Why would that not be the case for REST as well? The mind boggles. All the arguments against REST that GraphQL camp makes are disingenuous at best.

<comment><USER7> After using GraphQL with code-generated Typescript types on the response, I can't imagine going back to REST and it's "hope and pray" the JSON looks how you expect it to look

<comment><USER52> I think part of the actual, non-hyped benefit is that it adds type definitions to incoming and outgoing fields on the client side. Working directly with JSON is kind of fucking awful. Attempts to fix it are often of an even more unpleasant "now you have two problems" sort (JSON-Schema, for example). Any well-supported standard for typing interfaces for data sent to the browser & other REST-consuming clients, even if the underlying transport remains JSON or whatever, is welcome.

</comment></comment></comment></comment><comment><USER53> Myt pet peeve with GraphQL is, why not just use JS objects, and use JSON for serialization!? query = {user: {id, name}}

<comment><USER25> There are quite a few ongoing attempts at creating a JS fluent client for GraphQL.

We covered a bunch of them here:

[https://hasura.io/blog/fluent-graphql-clients-how-to- write-q...](https://hasura.io/blog/fluent-graphql-clients-how-to-write- queries-like-a-boss/)

</comment></comment><comment><USER54> A small comparison:

[https://www.moesif.com/blog/graphql/technical/Ways-To-Add- Gr...](https://www.moesif.com/blog/graphql/technical/Ways-To-Add-GraphQL-To- Your-Postgres-Database-Comparing-Hasura-Prisma-and-Others/)

</comment><comment><USER55> Does something like this exist for SQLite?</comment>


What type of DSL do you prefer? - <AUTHOR>

I am working on an OLAP database for .net (pure managed code). Write once, slice and dice data many times.
For the record, I do know of many products that do the same thing, but they are inadequate for different reasons. Pure managed code is one thing, price is a huge problem with a lot of them, lack of easy managed programmability, or just plain slow. A b-tree index cannot compete with bitmap index when we talk about intersection and aggregations on millions of records. And yes, I do know about SQL Server Analysis Services, PowerPivot, SPSS, and all the big ones.
But the MDX is not very intuitive, and SQL does not gives me the fine granularity to intermediate results that I need (I mean, yes it can be done, but a price is paid in performance). So I am into creating a more granular DSL.
From .net I am looking into 2 options:
* A .net API. probably some type of fluent interface * A text DSL that the developer executes against the engine. Maybe a graphic front end on top of it.
If you had to write an application that queries this kind of engine, what would you prefer? To interact with classes and objects, or to write strings that the engine will execute (ala SQL)?
:^) <comment><USER2> Strings?

Not familiar with your specific needs, but generally prefer DSLs fine tuned to the task. Strings sound like they'll allow more flexibility for you, less hassle for developers to type and read. Objects and classes sounds like boilerplate galore.

Hard to say though, depends on API or string DSL design. Do you have example code?

<comment><AUTHOR> Engine.Create("dbfile", CSV, "sourcefile", new Config[] { Field1, Field2 });

vs

Engine.Exec("Create dbfile CSV 'sourcefile' using Field1, Field2");

or...

Engine.Context("contextname", "var1>10").Save()

vs

Engine.Exec("Save (var1>10) as contextname");

<comment><USER2> Well the string DSL is easier to read. Doesn't seem like there would be a lot of useful autocompletion with objects/classes either.</comment></comment></comment>


From MIT, a cure for all viruses? - <AUTHOR> http://www.process.org/discept/2011/11/17/draco-death-to-the-virus/ <comment><USER2> Sounds promising. It'll be interesting to watch and see how this evolves.

Here's an off-topic comment issued in the spirit of constructive criticism for the site (please don't downvote based on this):

If any HN reader has an account with process.org could you --if you agree, of course-- suggest that a small gray font against a gray background is simply not a good idea? On an iPad without zooming it is really straining to read. On a desktop with a 24 inch 1920 x 1200 monitor it is not comfortable. Bad idea. A larger black font would be best.

<comment><USER3> Yeah, I had to take the time to implement a custom stylish style for the website in firefox before I started reading it.

<comment><USER4> To prevent having to 'implement custom styling', use Readability (firefox add- on: <https://addons.mozilla.org/en-US/firefox/addon/readability/>) or as for Safari the Reader functionality: <http://shrt.nl/s/shot-UD7ba5RjHg.png>

</comment></comment></comment><comment><USER5> I read the plos article when it came out. Basically, when a cell realises it is infected with a virus sometimes it will try to kill itself. There are a bunch of checks it does to make sure killing itself is a good idea. Many viruses try to counter these checks. DRACO works by short circuiting the detection -> kill self pathway.

It's a great idea. But sometimes a large proportion of cells can get infected when you have a virus. Someone might get in a lot of trouble if all their infected cells instantly died. Like, can anyone speculate what the side effect would be for an AIDS patient? I don't know myself, but I'd want to know more about this before saying this is a miracle cure.

<comment><USER6> "Someone might get in a lot of trouble if all their infected cells instantly died."

This was directly addressed in the linked article.

<comment><USER7> Sounds like a perfect beginning to a real "I am Legend" scenario. Imagine someone releasing a virus that could cross the blood-brain barrier (modified Rabies?) that just infects the cells and causes some minor symptoms that appear to be a standard cold. But anyone who takes this drug will have those brain cells self-destruct right?

<comment><USER8> If you could infect a target with a designer virus, why not just make it kill them directly? Unless you're the villain in a James Bond movie, of course ;)

<comment><USER7> Very true. I guess one would have to have some grudge against the company(s) that made this drug in the future and want to prove that it's dangerous with a zombie apocalypse.

</comment></comment></comment></comment></comment><comment><USER9> Thank you for posting this on HN! This is exactly the kind of underreported bleeding-edge engineering I hope to discover on places like HN.

It's very easy for mainstream journalists to jump on new technologies once they've been developed, but it's up to engineers and scientists themselves to make exciting potential directions better known.

</comment><comment><USER10> Props to the writer for going out an getting the interview on a great story: possible cure for viruses project diagnosed with lethal lack of funding.

But there are some "questions" to not ask in a news interview:

"Oh, wow. That's an amazing idea."

"There haved been articles, but I feel this is definitely front-page material."

I agree, this is amazing interesting stuff and the interviewer and interviewee made it great. But when you tell me how interesting it is instead of letting the content speak, you set off alarms in my head.

Sorry for being a curmudgeon--it's easy to berate things without contributing. Just saying don't let your opinion overshadow the story.

</comment><comment><USER11> My all-time favorite link to put in an HN comment is the one I will put here, "Warning Signs in Experimental Design and Interpretation"

<http://norvig.com/experiment-design.html>

by Peter Norvig, LISP hacker and now director of research at Google.

I hope the preliminary research findings discussed in the interview submitted here are replicated and prove to have clinical benefit for human patients. Finding out whether or not they do will still take much work by other researchers.

<comment><USER12> For this reason along with many others, I can't be impressed when Bezos spends money raising some rocket motors from the bottom of the ocean while potentially one of the greatest medical accomplishments of humans goes almost unfunded.

</comment></comment><comment><USER13> Good rule of thumb: if the title is a question, the answer is no.

<comment><USER14> If I could downvote you I would. As a scientist, skepticism is lazy and arrogant.

<comment><USER15> Are you sure about that?

</comment></comment></comment><comment><USER16> Go to kickstarter or some other funding method that will NOT patent or copyright this. Something like the JOBS acts would provide. This is too disruptive to have in the hands of big pharma.

<comment><USER17> Kickstarter isn't going to provide the hundreds of millions of dollars it costs to take a drug through the FDA approval process.

<comment><USER18> If it can get a million dollars for a _video game_, you don't think it could get a hundred million to cure all viral disease?

The difficulty, of course, is convincing the donors that the likelihood of success is high; with a video game from a reputable publisher, it's near 1, whereas it's much lower for an experimental drug. But the potential gain is certainly many orders of magnitude greater.

</comment></comment></comment><comment><USER19> This is pretty cool, but it's so early in the drug -> product process that it's really difficult to get one's hopes up. The article indicates that they're nowhere near clinical trials, which often take 5 years by themselves - and most drugs get weeded out before they even get to this stage.

</comment><comment><USER20> When I first saw it I though it was fake.

But seriously, PANACEA and DRACO? Is Dr. Todd Rider trolling the crazies?

For example: <http://youtu.be/EneiDKw_zXg> tl;dr: DRACO is attempt by Reptilians to corrupt human DNA, underwater cages, etc

<comment><USER21> Oh how insanely great. He makes sure those of us who don't believe that conspiracy gets treatment while those who do are forced to change their minds.

Two birds, one stone. Awesome.

</comment></comment><comment><USER22> Link to the original research [PDF]:

<http://goo.gl/jfAIw>

</comment><comment><USER23> I wonder why this got published in PLoS ONE rather than a more traditional and higher impact journal.

<comment><USER24> It's already been going around the public news circuit for a while, and they undoubtedly got some extra support and funding because it did. PLoS ONE publications are much easier for the public to access.

<comment><USER23> PLoS ONE is far from the most prestigious open access journal, even within the PLoS family. And even non-open access journals typically allow you to pay a couple thousand dollars to make a paper open access.

</comment></comment></comment><comment><USER25> I wish more science would get behind crowd funding, then we could potentially have this kind of stuff sooner/at all. I wince at all of the amazing science that doesn't kick off, not because of a lack of feasibility or interest but simply because of a lack of funding.

<comment><USER26> If you look at the number of ideas that get funded and fail, I would say there is more money out there than good ideas at the moment.

</comment></comment><comment><USER27> This is great until the fallout is destroying all the potentially "good" viruses with which humans are infected. Little research has been done to determine the good bugs. You can guarantee lots of beneficial viruses will be identified once the adverse affects of their absence begins wreaking havoc.

<comment><USER28> I've never heard of any 'good' viruses. I think you're applying the analogy of benefiical bacteria to viruses, assuming there must be beneficial viruses as well. In the artcile he somewhat addresses this by saying any cell infected by a virus will be killed at some point regardless, so DRACO wouldn't do any additional damage.

Now, I think you're implying that there might be 'good' viruses that we haven't discovered yet. I feel like if that's the case then other animals would certianly have them as well and we would surely figure that out before we got to human trials.

<comment><USER27> Bacteriophages are one type of beneficial virus. The way biology goes I wouldn't be surprised if there are 100's/1000's more. The other complication is it's not necessarily binary whether an invasive agent is good or bad. Slightly tangible, but fascinating nonetheless: [http://www.thisamericanlife.org/radio- archives/episode/404/e...](http://www.thisamericanlife.org/radio- archives/episode/404/enemy-camp-2010) Listen to the part about hook worms.

</comment></comment></comment><comment><USER29> Wow, is that real? How is this not front page news on every network? This would be as big as the discovery of antibiotics.

<comment><USER30> This appeared on reddit a few days ago, and the answer to your question is twofold.

First, this has not yet undergone human testing. In the history of pharmaceuticals, there have been many drugs that performed favorably in animal testing yet failed in human testing. It is simply too early to tell if this drug will be successful in humans.

Secondly, was the idea that eliminating all viruses, as this seems to do, is not the best solution. Our bodies would not get the opportunity to develop resistances in the way the immune system usually does so we would be susceptible to the virus the second time around.

<comment><USER31> There are many viruses dangerous enough that humans tend to die instead of developing resistance. I think that is enough reason to want this sort of drug around.

<comment><USER32> It could also make viral gene therapy _considerably_ safer, and generally reduce the potential bioterror risk of having genetics technology around.

Even if the drug had nasty side effects, it would be great as a last resort similar to ultra-powerful "atomic bomb" antibiotics.

</comment></comment></comment></comment><comment><USER33> Side note: have mercy on your readers and make the text contrast a bit higher.

</comment><comment><USER34> This is a very interesting and novel technique, but it brings to mind a very interesting and (to my knowledge) still very much open question in human biology: just what all _does_ RNA do?

Obviously, we know quite a lot about RNAs such as mRNA, tRNA, and rRNA, but until the later part of the 1990s it would have been nearly impossible to predict such things as snRNA, snoRNA, siRNA, miRNA, and RNAi.

Then there's the question of retrotransposons. Could they cause a spurious triggering of DRACO? How active are they and how important is that activity over short time scales (the time scale of an infection, say)? What about long time scales (say, a lifetime of treating illnesses with DRACO)? Unfortunately, retrotransposons are thought to behave very differently in mice than in humans, so if this research _doesn't_ translate to humans, my bet would be that it has something to do this difference.

All that said, this is very creative work and should rightfully be celebrated.

<comment><USER35> Not to mention viroids - tightly balled RNAs of only a few hundred (220!) nucleotides which, due to the shape they form, coerce replication machinery to reproduce them. Definitely on the very edge of what can be considered "alive".

Edit: that is to say, they don't encode any proteins - they simply loop back on each other and the shape does all the work.

<comment><USER14> The shape is more important as a container, transporting other silencing RNA or miRNA. People have developed nano cages that act as slippery shells to deliver a payload, and so far some insanely promising results in mammalian cells.

For what it's worth, I think this will be the mechanism for majority of gene based drug delivery in 10 years.

<comment><USER35> Oh really? cool. It's been a while since I read anything about viroids. They somehow bundle miRNAs?

<comment><USER14> It's more about using DNA/RNA nanostructures. Imagine a 3d tetrahedron with toehold overhangs made entirely of one strand of DNA/RNA that unravel to deliver the payload. From what I remember, they are soluble through lipid bilayers, making them very effective for delivery.

Imagine a very small 3d hotpocket that can deliver small siRNA or miRNA. Even better, you can program a signal amplification or another message into the structure itself, e.g. joining other structures to form lock-key mechanisms like legos.

</comment></comment></comment></comment></comment><comment><USER36> Here's the MITLL press release: <http://www.ll.mit.edu/news/DRACO.html>

</comment><comment><USER35> Very interesting. I did my honours research in engineering grasses (Medicago) with a complementary RNA to a commonly occurring virus in order to trigger a similar defense. Unfortunately, somehow a few generations later the plants just stopped expressing those genes.

Plants don't have an immune system per-say but they do actively defend against double stranded RNA.

</comment><comment><USER37> It seems that DRACO works by binding double-stranded RNA. This will work for many, but not all, viruses. Viruses can also have single stranded RNA genomes, like influenza, as well as single- and double-stranded DNA genomes, like herpes. Optimistically, this is s cure for a subclass of viruses.

<comment><USER38> Did you read the article? It's not related to the virus's genome, it's related to the RNA that genome produces, which the interviewee contends is always doublestranded. In fact they specifically address DNA viruses and herpes.

</comment></comment><comment><USER39> I'll wait for human trials but I love their ballsy acronym for now:

PANACEA (Pharmacological Augmentation of Nonspecific Anti-pathogen Cellular Enzymes and Activities)

</comment><comment><USER40> its interesting although one potential twist is that viruses may be more the communications vector for genetic material than the actual disease causing process itself (which is the payload).

if this gets widely used in the field, will it disrupt "good" things - evolutionary processes, symbiotic infections, etc?

Will it disrupt the ability of manmade viruses (i.e. gene therapy) from working?

<comment><USER41> I have no idea but I am curious as well. The one thing that did stick out was he said it only lasted 48 hours in the body. So presumably, if you were doing something after it left the body, it would have no effect (assuming it works as intended).

<comment><USER42> In the article the idea of bioengineering Draco into the body was mentioned. My understanding is that in the early stages of pregnancy there's some very weird stuff going on in mammals that appears to involve endogenous retro- viruses. It might be that mammals came into being partly as a result of some reptile having a viral infection that got into some sperm or egg cells. That wouldn't be a reason not to use it as a drug, but the world of biology is very weird and the systems are _open_ in a way computers are not. Viruses have been around for a very long time and like bacteria are embedded into the environment in ways that like fish in water we won't notice until they go away.

<comment><USER41> Ah, I forgot that about that part. It were engineered into us that is an interesting and very different scenario than what I was thinking of (simply taking it to cure/remove/kill viruses)

</comment></comment></comment></comment><comment><USER43> But do we _need_ to cure all viruses? Do we know that all are hostile to humans?

<comment><USER36> As far as I'm aware viruses don't do anything positive for humans, though they can swap genes around and so allow bacteria to evolve more quickly. This is in sharp contrast to antibiotics where we really do rely on a huge number of symbiotic bacteria. So it seems that anti-virus drugs are a much safer thing than the antibiotics we already use.

</comment></comment><comment><USER44> I was slightly baffled and then amused to read the phase

      "And can you take it up to monkey here [at MIT]?".

It took me a moment to work out what that meant (even though I could have read the next sentence for a clue).

</comment><comment><USER45> Well, sad thing is humans have been creating most of the diseases that have been released into the wild for the past 50 years...

Lyme disease, H1N1(now H1N5-X), etc...

The reason they do NOT cure diseases is because, overpopulation would explode. Cancer isn't cured for this reason but, they certainly love money for a whole bunch more research. The same can be said with HIV/AIDS.

You may think its absurd or wrong in concept but, do the math for yourself...

You think 10-billion people by 2020 is a large number...

If they cured even a single major disease(like cancer), 10-billion would be 20-billion by 2030...

It's an interesting thing to know that humans are responsible for killing ourselves only because, they won't fund technologies for space travel & transforming.

Enjoy being slaves on this watery rock.

;-)

<comment><USER46> Your reply is surely in jest.However, if it was not, the Iceman who lived 5,000 years had Lyme disease.

"Perhaps most surprising, researchers found the genetic footprint of bacteria known as Borrelia burgdorferi in his DNA—making the Iceman the earliest known human infected by the bug that causes Lyme disease."[1]

[1][http://ngm.nationalgeographic.com/2011/11/iceman- autopsy/hal...](http://ngm.nationalgeographic.com/2011/11/iceman-autopsy/hall- text)

<comment><USER47> > the Iceman who lived 5,000 years had Lyme disease

I think you mean the iceman who lived 5,000 years ago, otherwise woah!

<comment><USER46> Pre-coffee comment. Thanks for the proof read.

</comment></comment></comment></comment><comment><USER48> Company start-up name ... maybe ... Umbrella Corporation

</comment><comment><USER49> Is Paul Graham going to put money for a start-up pharma to mass produce this if this deems to be silver bullet as it claims to be? I smell a lot of money!

<comment><USER21> Holding the patent on this, once approved by the FDA, will make you able to roll in money for as long as you want.

But getting there will cost an insane amount of money. Far more than YC will ever get. It is more money than any of the VCs have, though they may have enough if you combine the three or four biggest.

And even then the drug may fail.

</comment></comment><comment><USER50> Oh Draco, you do get your reward for not going over to the dark completely...

</comment><comment><USER51> I'm not accepting this real until a respected news network investigates it. That and the fact that they didn't seem to spell check / proof-read it first makes me suspicious.

<comment><USER36> Wait, seriously? I thought you were being sarcastic until I read the second sentence. Mainstream news networks in infamously bad at evaluating the accuracy of scientific research, and often end up reporting ridiculous things even if they're drawing inspiration from valid science.

The way to evaluate the validity of normal scientific research is typically to see if any respectable research journal has published it. And as far as I can tell PLOS counts as a respectable journal. Before you really start believing the results you want to look for other people duplicating the results, but publication itself means that yes, this is serious.</comment></comment>


Show HN: Boltzmann Machines in TensorFlow with Examples: RBM, DBM, AIS - monsta-hd https://github.com/monsta-hd/boltzmann-machines <comment><AUTHOR> I remember writing the RBM in straight CUDA back in ~2008. Back then we had to do our tensor work uphill both ways against the gradient.

<comment><USER2> Why are RBMs so seldom used? What is their weak point? Based on Hinton's talk I thought it was a major breakthrough back then.

<comment><USER3> It was back then..we don't even support them in our framework anymore. Most folks use VAEs and GANs for generative models now. In general, they are just more stable.

<comment><USER4> How about DBN? It is also a generative model but why now rarely used?

ML researchers following trends, like doing end-to-end CNN for whatever problems, and using this LSTM and that GRU and that latest architectures; in similar fashion like web devs picking and dropping javascript frameworks.

<comment><USER3> A DBN is equivalently just stacked RBMs. Most folks just use stacked autoencoders for the exact same reasons you'd use a DBN.

Most "off the shelf" work people do is fairly simple transfer learning on an imagenet cnn.

That or if they do generative, most of the hype is focused on GANs now.

</comment></comment></comment></comment></comment><comment><USER5> I don't have any commentary here other than to say that this is great work!

<comment> monsta-hd Thank you!

</comment></comment><comment><USER6> I am going to run this on my Chromebook asap!

</comment><comment><USER7> Oh...wow. This is amazing!

</comment><comment><USER8> Thank you monsta-hd!

<comment> monsta-hd Welcome :)</comment></comment>


Ancient Horse DNA Shows Scythian Warriors Were Adept Domesticators - <AUTHOR> https://www.nytimes.com/2017/04/27/science/horses-genetics-domestication-scythians.html <comment><USER2> The descriptions of contemporary or near-contemporary historians like Herodotus when describing the habits of their country's enemies must be taken with a grain of salt, e.g., the 'slave-blinding' and 'blood-drinking'.

<comment><USER3> Even calling them "historians" makes them (and their methods) seem more similar to modern historians(') than they were.

</comment></comment><comment><USER4> The Dan Carlin podcast series "Kings of Kings"[1] colorfully describes the Scythians, and many other groups. Fascinating stuff.

1 - [http://www.dancarlin.com/product/hardcore- history-56-kings-k...](http://www.dancarlin.com/product/hardcore- history-56-kings-kings/)

<comment><USER5> His series on Genghis Khan also describes a similar culture.

</comment></comment><comment><USER6> > In modern horses, the Y chromosomes in stallions are almost identical, > reflecting the breeding technique of using a single stallion with desired > characteristics to father many offspring.

Could that be true? I mean, could all modern domesticated stallions have "almost identical" Y chromosomes?

Edit: Perhaps over generalizing?

> ... Lippold based his findings on the results of a 2004 Swedish study that > showed a particular DNA sequence in the Y chromosomes of 52 modern-day > stallions representing 15 different breeds was absolutely identical.

> This doesn't mean modern stallions have no diversity of all, Lippold > cautioned. The researchers only studied one part of the Y chromosome ...

[http://www.thehorse.com/articles/28083/researchers- examine-a...](http://www.thehorse.com/articles/28083/researchers-examine- ancient-stallions-genetic-diversity)

<comment><USER7> Domestication leads to heavy inbreeding and a depression in genetic diversity genome-wide.

Furthermore, the Y chromosome recombines at a much slower rate compared to the autosome, resulting in less diversity. This should be balanced by a higher mutation rate, but again, domestication depresses that.

So no, it's not really surprising to see this.

<comment><USER5> (Source: ~25 years experience working with horses as a hobby)

At least in the US, inbreeding is indeed extensive. The vast majority of male horses are castrated at a young age, since intact males are considered more difficult to train and control (therefore more dangerous to humans) and more expensive to house than castrated males or intact females. Therefore, a small percentage of males end up fathering all the offspring. There are American Quarter Horse stallions with literally thousands of offspring (sometimes to their detriment, as when a popular stallion was belatedly discovered to carry a recessive genetic disease[0]).

It's therefore interesting to a modern horse person to read that "the Scythians maintained the natural herd structure" (a "harem" structure in which one male tends to sexually dominate several females - but several, not thousands, and not generally for his entire life).

[0] [https://en.wikipedia.org/wiki/Impressive_(horse)](https://en.wikipedia.org/wiki/Impressive_\(horse\))

<comment><USER7> Scythians probably put a lot more value on an slow ugly horse that would live 30 years rather than a pretty horse that could sprint but died when it saw its shadow.

<comment><USER5> If you're trying to malign quarter horses, be aware that many can't even sprint anymore (they're being bred more for "western pleasure" e.g. extremely slow, mechanical movements ;-)

<comment><USER8> > a pretty horse that could sprint but died when it saw its shadow

Sounds more like an Arabian horse. Famously skittish but fast.

</comment></comment></comment></comment></comment></comment><comment><USER5> You can see examples of Scythian-style horse acrobatics and archery (by modern Mongolians):

* [https://www.youtube.com/watch?v=bRvHJ5H73cU&t=90s](https://www.youtube.com/watch?v=bRvHJ5H73cU&t=90s)

* [https://www.youtube.com/watch?v=stnNCDT-j1o](https://www.youtube.com/watch?v=stnNCDT-j1o)

(edited to separate links)

<comment><USER9> ...and by modern Kyrgyzs: [https://www.youtube.com/watch?v=_LftDIksFNQ](https://www.youtube.com/watch?v=_LftDIksFNQ)</comment></comment>


French institute suspects nuclear accident in Russia or Kazakhstan in September - <AUTHOR> https://www.reuters.com/article/us-russia-nuclearpower-accident/french-institute-suspects-nuclear-accident-in-russia-or-kazakhstan-in-september-idUSKBN1D92LJ <comment><USER2> Article on the IRSN website (in French) with a map of likely release locations : [http://www.irsn.fr/FR/Actualites_presse/Actualites/Pages/201...](http://www.irsn.fr/FR/Actualites_presse/Actualites/Pages/20171109_Detection- Ruthenium-106-en-france-et-en-europe-resultat-des-investigations-de-l- IRSN.aspx)

<comment><USER3> There's an English synopsis on their website, with the same map: [http://www.irsn.fr/EN/newsroom/News/Pages/20171109_Detection...](http://www.irsn.fr/EN/newsroom/News/Pages/20171109_Detection- of-Ruthenium-106-in-France-and-in-Europe-Results-of-IRSN-investigations.aspx)

</comment></comment><comment><USER4> Detected (and reported) in Slovenia on Oct 9 too: [http://www.ursjv.gov.si/si/info/novica/article/12088/5981/](http://www.ursjv.gov.si/si/info/novica/article/12088/5981/)

Gone now: [http://www.ursjv.gov.si/si/info/novica/archive/2017/11/selec...](http://www.ursjv.gov.si/si/info/novica/archive/2017/11/select/sporocilo_za_javnost/article/12088/5991/)

Sorry, both links in Slovene, but Google Translate can help.

</comment><comment><USER5> How can I detect nuclear fallout at home? It would be interesting to log levels daily and then compare to incidents like this. In particular I'd like to monitor the effect if/when North Korea does an atmospheric test.

<comment><USER6> Get a second hand (army surplus is a good source) Geiger counter with an instrumentation output. You may have to do some conversion if your current computer does not do RS232.

<comment><USER7> The problem is differentiation from background.

A release from NK or Russia, by the time it hits your Geiger counter, will likely be so low that it will be lost in the noise of background radiation. And local sources (such as radon gas) would mask anything but significant nearby events.

The reason why France identified the release is because their detectors can determine different radioisotopes.

It's a little like the difference between a photovoltaic cell and a camera. Your Geiger counter can tell when the "light's on" (presence of radiation) but it takes a different instrument to determine that it's Ruthenium 106.

<comment><USER6> GGP spoke about general levels, not specific elements, and yes, you are 100% right, a Geiger counter is a pretty blunt instrument.

<comment><USER7> Even after Chernobyl and Fukushima, outside of the impacted area, there really wasn't any detectable increase in background.

You're much more likely to get an increase in background going into your basement (because of Radon daughters) than from an nuclear release halfway around the planet.

</comment></comment></comment></comment></comment><comment><USER8> I wonder if the source of the accident is really aware of the accident?

Without knowing a lot of the details, is this something that could happen if a naive, or lazy, employee just decided to incinerate waste? Is this something that could happen if someone was goofing off? Is this something that could be undetected, due to lack of monitoring equipment, at the source?

<comment><USER9> USSR tried to keep Chernobyl blowing up a secret until caught and preassured by Sweden to admit there was an accident. I really don't expect Russia to act different today. Just look at the "we have nothing to do with it" handling when Crimea was invaded.

<comment><USER10> The Communist government even tried to hide the blow up from local population exposing a lot of people to extra risk when trivial measures could have minimized it.

In Minsk, Belarus my mother was warned by friends of friends that worked at a research reactor. They spent few hours trying to identify a leak at their facility as all Geiger counters showed a very high rise over the background level.

Then they were reluctantly told that it was an accident in Chernobyl. Then from the reading of the counters they realized how bad the accident must be and asked all people they knew to stay in doors and close all windows.

</comment></comment></comment><comment><USER11> I remember reading something similar about a year ago. Did anything come of those reports?

<comment><USER12> Last year was a release at a Norwegian research reactor. First of all, that was an impressive feat of analytical chemistry, that they could detect a fairly insignificant leak all over Europe.

[http://www.world-nuclear-news.org/RS-Radioactive-release- for...](http://www.world-nuclear-news.org/RS-Radioactive-release-for- Norwegian-research-reactor-2510165.html)

</comment></comment><comment><USER13> When I was working on my BS in Physics we measured Cesium-137 from nuclear accidents and weapons testing. We wanted to see if we could detect any change due to the release of material in Fukushima. We didn't see any change though because we were using a pretty insensitive gamma spectroscopy method and the increase was so small. I think they later found a small increase using a mass spectrometer.

It's amazing that you can still detect the results of the Chernobyl disaster on the opposite side of the world, decades later. That was one heck of a meltdown!

</comment><comment><USER14> It would be interesting to log levels daily and then compare to incidents

</comment><comment><USER15> It would be sufficient for media to launch shitstorm again.

</comment><comment><USER16> Why do they warn us 2 weeks after the fact ?

Should I up my iodine intake or it's useless against ruthenium ?

edit : according to this article it started sept 29 : [https://phys.org/news/2017-10-spike-airborne- radioactivity-e...](https://phys.org/news/2017-10-spike-airborne- radioactivity-europe.html)

<comment><USER17> Unfortunately, the media and governments do a very poor job of outlining the whys of radiation, and leave it a very scary boogeyman for concerned citizens.

Iodine pills don't magically protect people from radiation. Taking them doesn't do anything to prevent nuclear decay from happening, doesn't grant people superpowers to stand in a radioactive environment, and doesn't let you lick fuel rods without consequence. In fact, taking them is to leverage the chemical benefits of diffusion.

Before I dive right into it, let me mention that a few forms of radioactive decay don't impact humans well. Alpha decays bounce off your clothing and skin, and can only travel a few cm in air. Beta decays bounce off your skin, or only make it so far into the already-dead skin cells, and don't travel very far in air either [0]. Gammas (sunlight) are a different matter, as are neutrons (from nuclear reactors). Hence, the sunscreen and the giant concrete containment units. This all changes if you inhale/ingest radioactive isotopes, and alphas suddenly become the most deadly (ask Alexander Litvinenko) and betas are up there too. Iodine 129 is a beta emitter, a pile of which will continue emitting radiation long after this generation of human beings are ash and dust. Eating this stuff is like eating glass.

Back to the iodine pills: You take this pill because $GOV says so, and it saturates your body (thyroid) with a stable isotope of iodine. It's like taking a half-empty biological sandbox, and filling the rest of it up with sand. The inner child that lives within us can continue playing safely as this iodine doesn't decay. It means no new iodine 129 will be able to be retained in your body, your body is already full of the stable stuff, so such a person _will still ingest iodine 129_ , but _won 't retain it in their body for a long period of time_.

However, failing to take an iodine pill beforehand will mean the sandbox is half-empty when a nuclear fission accident releases iodine 129. This means that sandbox will become (over time) quarter-sand and quarter-glass and still half empty, due to the laws of diffusion. No inner child wants to play in that box. And that means iodine 129 is sticking around inside the body, and in particular the thyroid (which is an organ more sensitive to radiation than others, for reasons I don't know since I'm an engineer not a doctor).

So, how does this stack up against ruthenium?

Your body doesn't use ruthenium in any significant way. It'll just pass it right back out. You can think of it as your body being permanently on the ruthenium pill. Yes, ruthenium 106 is a beta emitter exactly like iodine 129, but with a much shorter half-life of around a year. It decays to Rhodium 106, another beta emitter, which within a minute is already burned out into stable palladium 106. So on the whole, the human body is going to have an extremely tough time concentrating this stuff to dangerous levels inside of it.

So overall, your risk is not zero, but if you want to offset it I recommend not taking an airplane the next time you otherwise would, as flying up at cruising altitude in the atmosphere usually exposes you to more radiation than ruthenium 106 scattered around the earth ever will.

I highly recommend playing with [1] for nuclide information and decay chains.

[0] [https://www.youtube.com/watch?v=Efgy1bV2aQo](https://www.youtube.com/watch?v=Efgy1bV2aQo)

[1] [https://www-nds.iaea.org/relnsd/vcharthtml/VChartHTML.html](https://www- nds.iaea.org/relnsd/vcharthtml/VChartHTML.html)

<comment> Tuna-Fish You got the basics right, but i have to nitpick that I-129 is just not biologically relevant. It's long (millions of years) half life means that it's sufficiently inactive that you could replace all your iodine with it and barely notice. Biologically relevant radioactive contaminants are the short- lived ones, as activity is inversely proportional to half-life. In the case of Iodine, the dangerous one is I-131, as it's short (8 days) half-life means it's very radioactive, and it has a high biological uptake from the environment.

<comment><USER18> I think that _you_ may have gotten the basics wrong here. 1 Bq of I-129 is exactly same radioactivity as 1 Bq of I-131. Its definition is 1 decay per second. The half-life tells how long you have to wait for a given atom to decay, on average. It is not, as you imply, a biological risk factor.

Furthermore, the chemical process by which iodine is absorbed from the bloodstream by the thyroid is unable to discriminate between isotopes. So their biological relevance is actually identical.

If you want a quick and easy way to compare biological impact to the human body for a given isotope, check out the US Federal Guidance Reports 11 & 12\. They have done all the heavy lifting and for a lot of the real nasties, you will actually find that the biological damage is chemical not radiological.

Interestingly, the limit for ingestion if I-129 intake is much lower (indicating a higher biological impact) than I-131 (by a factor of six), primarily BECAUSE it has a long half life. The half life is so long that the clearance rate is basically the biological half-life. Where as the I-131 is so short compared to the biological half-life so within a few months it is gone.

[https://www.epa.gov/sites/production/files/2015-05/documents...](https://www.epa.gov/sites/production/files/2015-05/documents/520-1-88-020.pdf)

<comment><USER19> _1 Bq of I-129 is exactly same radioactivity as 1 Bq of I-131_

In terms of decays per second, sure. Those decays are somewhat less harmful though -- I-131 has betas and gammas in the ~500 keV range, while I-129's emissions are in the ~35 keV range.

But more importantly, 1 _mol_ of I-129 is far less harmful than 1 _mol_ of I-131.

 _the limit for ingestion if I-129 intake is much lower (indicating a higher biological impact) than I-131_

The annual limit for ingestion of I-129 is 0.2 MBq, compared to 1 MBq for I-131. But given their vastly different half-lives, the annual ingestion limit for I-129 is 30 mg, compared to 220 picograms for I-131.

<comment><USER18> I am not going to argue with you about this. I am a radiological scientist, not a someone that has read up on Wikipedia.

No one measures radioactivity in moles.

The FGR11 limit on I-129 is 5 uCi and I-131 is 30 uCi, I know it is not the latest and greatest, but the latest and greatest makes use of probabilistic risk models to quantify the increase in chances of getting cancer. this is less helpful in a discussion of personal danger rather than the collective danger.

<comment><USER18> I take issue to the generalization that short half lives = more danger. That is just not true. Tc-99m is used in diagnostic medicine, it has a half-life of 6 hrs. It does not have more risk than Sr-90 that has a half-life of 29 years.

<comment> Tuna-Fish One mg of Sr-90 has an activity of ~140 uCi. One mg of Tc-99m has an activity of ~5Ci. You probably understand the differences in the implications of handling an amount of material that emits 140uCi compared to one that emits 5Ci.

In medical radiology, the amounts of radioactive isotopes are measured in Bq because the samples are so heavily diluted that it's the only thing you can sensibly measure. This easily hides the fact that when you are talking about roughly equal amounts, Tc-99m is roughly 29 years/6 hours ~=40000 times more dangerous than Sr-90. You just never use equal amounts, when you receive a sample of Tc-99m it's about 40000 times smaller than the Sr-90 sample.</comment></comment></comment></comment></comment></comment></comment></comment>


The end of traditional venture capital - <AUTHOR> http://www.infoworld.com/article/06/09/04/36NMmain_1.html

<comment><USER2> This entry termed as "traditional" venture capital is accurate as I these SaaS dev environments are still incubators of sorts, and still require a piece of the profit. Problem is, the product is not as free-standing - your product is very derivative and always has a bill to pay.</comment>


Learning F#: Case study with branch and bound - <AUTHOR> https://www.youtube.com/watch?v=UZIqQMDZTwc <comment><USER2> I wish the presenter had a better presentation, the code was very hard to read.</comment>