Another great 3D experience, right into your web browser. Netlify is a fantastic hosting solution with a great developer experience.
Readit NewsGulthor commented on Netlify Celebrates 5M Developers – 3D Game 5-million-devs.netlify.co... · Posted by u/guigui
This project makes me want to play SimCity 2000 again. Congrats, nice execution.
A finely crafted piece of art.
Out of curiosity, do you plan to make this project open source? I'd be curious to learn about some the technical details.
Gulthor commented on Effect 3.0: Production-Grade TypeScript effect.website/blog/effec... · Posted by u/MichaelArnaldi
We've been using Effect in production since late 2021. Fantastic tool, can't wait for persistent workflows.
Gulthor commented on Amazon Neptune – Fast, reliable graph database built for the cloud aws.amazon.com/neptune... · Posted by u/irs
There are two main paradigms here
1) "native" graph db Neo4J is an example of this. This takes advantage of index-free adjacency. Each node knows what other nodes it is connected to and hence traversals are very fast. The issues you run into are when you try to scale. Data that fits onto a single machine is fine and you can replicate your data for fast parallel reads/traversals across disparate regions of a massive graph. However you no longer have the concept of data sharding and distributing the graph as index-free adjacencies don't translate across physical machines. And another drawback is highly connected vertices, you will expend a tremendous amount of resources deleting or mutating a vertex with, say, 10^6 edges. But that vertex is probably a bot so you should delete him anyway.
2) inverted index graphs, non-native graphs, whatever anti-marketing name it might have. These rely on tables of vertices and other tables of edges. Indexes make them fast, not as fast for reads but very fast for writes. And you get distributed databases (Cassandra, for example, a powerful workhorse of a backend with data sharding and replication factor, etc.). But then you have to yet another index to maintain and the overhead can get expensive. This is the model adopted by DataStax, who bought Titan DB (hence the public fork to Janus) and integrated it with some optimisations and enterprise tools (monitoring etc, solr search engine) to sit on top of Cassandra.
Both now have improved integration with things like Spark. Cypher is probably faster than Tinkerpop Gremlin especially with the bolt serialisation introduced in recent versions of neo4j.
So janus is the graph abstraction layer of the second type and so needs somewhere to save these relationships. It all comes down to use case (and marketing) to decide what works best for you.
Recommended reads on the native vs non-native topic:
* https://www.datastax.com/dev/blog/a-letter-regarding-native-... (tldr; there is no such thing as a native graph database)
* https://neo4j.com/blog/note-native-graph-databases/ (tldr; native graph databases do exist)
Regarding Cypher vs Gremlin: serialization could be a thing but what matters among other things are efficient query optimizations, algorithm and (physical) data model. Ultimately, databases are all reading from 1-dimensional spaces (RAM or disk), either randomly or (best) sequentially. If you can colocate vertices with their respective edges, you're fine: this is trivial for graphs with no edges or graphs that form a linear chain. If not, then things start to become fun, especially in a distributed way. This will impact performance; the language, not so much.
Gulthor commented on Keep Out – WebGL Game Experiment littleworkshop.fr/keepout... · Posted by u/mariuz
Author here. In case it's not obvious from the article, the game URL is: http://www.playkeepout.com
Happy to answer any questions!
Nice piece of game! Any chance you could write a couple blog posts about the technical challenges you had to face, if any? I'm especially interested in the way you generate levels. Thanks.
Gulthor commented on Show HN: Linkurious, the first data visualization platform for graph databases linkurio.us/... · Posted by u/david_p
Thanks!
We are in talks with Allegro and OrientDB and have clearly planned to develop connectors for these databases.
As for TitanDB, since we will probably develop our OrientDB connector on top of it's Gremlin API [1], it'll be little work to write the TitanDB connector after that (they have a Gremlin API too).
To clear out a possible minor confusion for readers here - Titan's only API is Gremlin (though there also is a lower level Java API). You guys should also have a look at ArangoDB, which also supports Gremlin.
Linkurious with upcoming TinkerPop3/Gremlin will definitely be quite interesting to use. Keep up the good work.