Hacker News Reader

Comment by oilbagz | Hacker News Reader

I like this, but I feel its important to point out that this is effectively unusable by the very people who would benefit from it most: non-web developers.

If this were a drop-in C/C++ library, I'd use it immediately in my native apps and adopt it as a widespread platform technology. I want to be able to do this, and if it were truly a working technology, I'd put it in every single app I use.

But as a Node/JS library, it is off limits.

Please, decentralization guys, consider native languages first, and toy languages next. These technologies are never going to be embraced unless they treat native platforms as first-class systems for their manifestation.

View on HN

Amen to this! I too got really excited until I saw it was JavaScript. For me to use it I'd have to link against some sort of JavaScript interpreter (ew) and probably incur performance penalties shoveling the data too and fro.

Can't we just have nice, normal libraries like we used to? Tools that require me to install a huge new build system, package management (cough golang cough) just to run quickly lose their appeal.

The answer is the same as it always was: you'll have "normal" libraries when somebody writes them (it could even be you). Most new application development relies on web servers, where JavaScript is very relevant and normal.

There is a Go implementation available https://github.com/berty/go-orbit-db

What is the definition of a toy language? That’s a new term for me.

I (thankfully) haven’t written C++ in over 20 years, but if I had to drop back down to a low level language, it’d be C or a compile-to-C language. C is the language these things should target, in my opinion.

> What is the definition of a toy language?

A language that doesn't require as much hair-pulling to learn, so you can't feel as smug for knowing it.

So... not Javascript then?

> What is the definition of a toy language? That’s a new term for me.

I would imagine most non-compiled, scripting languages. They are ok when building the business logic of an application on top of faster building blocks but not ok for application building blocks such as a database.

Systems developer here. I made an account to answer this, because the OP is 100% right about this.

A toy language is one which you do not allow to escape the play-room/sandbox, you play with it (because hey, you can, so why not..), but you would not actually use it.

The reason this is important for decentralization efforts, is that the OS should be doing this.

Sure, paint the pretty UI, but expose the entire thing to common OS-level abstractions, please, and then host the scripts, kthxbai ..

(A non-toy language is one you are very comfortable shipping. Javascript is that for a lot of people. Not for systems programmers = it is an application execution environment, not a place for things which must operate, as part of the system, without much user hassle ..)

Something like https://dqlite.io/ would fit your needs? It's distributed thanks to Raft with all consequences. It's not viable to call it P2P as it lacks node discovery et cetera. Yet, it's distributed.

I would play with some Python.

Me too! But the thing is, a vanilla C library can be used by anything. It's the lowest common denominator. I can easily call into a C library from Python, Perl,... MATLAB... and I don't know JavaScript but I bet it's not hard from there either. That can't be said about any other language.

Performance is oft cited as why systems software is written in C (or C++ with C bindings), but I think a much stronger reason is the universality. C runs on everything from big iron to the smallest microcontroller.

orbitdb runs on browsers, via WebRTC. It's much easier to embrace something that runs on a web page than something that you have to download and run.

Reply on news.ycombinator.com