
Motoko, a programming language for building directly on the internet - markdog12
https://stackoverflow.blog/2020/08/24/motoko-the-language-that-turns-the-web-into-a-computer/
======
tlack
Code sample:

Actor model with explicit synchronicity and access scoping:

    
    
      actor Counter {
        var value = 0;
        public func inc() : async Nat {
          value += 1;
          return value;
        };
      }
    

Types and specificity:

    
    
      type Tree<T> = {
        #leaf : T;
        #branch : {left : Tree<T>; right : Tree<T>};
      };
    
      func iterTree<T>(tree : Tree<T>, f : T -> ()) {
        switch (tree) {
          case (#leaf(x)) { f(x) };
          case (#branch{left; right}) {
            iterTree<T>(left, f);
            iterTree<T>(right, f);
          };
        }
      }
    

Source: [https://sdk.dfinity.org/docs/language-
guide/motoko.html](https://sdk.dfinity.org/docs/language-guide/motoko.html)

Not to my taste personally.

~~~
smabie
Looks like Scala, but uglier.

~~~
anentropic
an impressive feat in itself

------
tines
Looks cool. One thing though, the page says

> Actors are a great model for concurrent programming because they
> automatically prevent race conditions (thanks to atomicity and encapsulated
> state) and deadlocks (because execution never blocks)

This isn't really true afaik. You can still have logical race conditions if
you don't synchronize messages (but they won't be architectural races), and
you can still have deadlocks if two actors wait on messages from each other at
the same time.

I feel like people often treat race conditions and deadlocks as small,
computer-architecture ideas when really they're quite broad concepts. You may
be able to prevent them automatically at certain scales, like say a single
uint64, but when you try to treat two uint64s as a single uint128 then
suddenly race conditions are possible again, despite the guarantees your
language has made on the smaller scale.

~~~
kjeetgill
I agree completely! And this shows up in just about any language because of
that — however — I kinda get where the author is coming from.

When a certain amount of state is encapsulated within a single actor (or a
single message for that matter) you can act on all of it sorta transactionally
since no other actor has access.

This is probably more power/control than some programers have had in other
languages or paradigms.

Your full program state dosn't retain this property once it spans actors but
what can ya do.

------
RcouF1uZ4gsC
> Instead, the Internet Computer implements orthogonal persistence—yet another
> old idea where a program has the illusion of running “forever” and its
> memory staying alive (at least until it is explicitly taken down). In
> Motoko, this means that developers do not have to worry about explicitly
> saving their data or bother with files or an external database: whatever
> values or data structures are stored in program variables will still be
> there when the next message arrives, even if that is months later.

My guess is that storage persistence is the Godzilla of all leaky
abstractions. There are huge tradeoffs in regards to consistency, durability,
random access, performance, and cost. In addition, there are huge issues with
lock-in. If I can save my data to sqlite or postgress or even S3, I know that
I will be able to migrate the data to other languages and systems pretty
easily. But if all my data is in a abstract "Internet Computer persistence
pod", that is a huge issue.

~~~
pavlov
This model also seems to ignore data deletion, which is a huge concern for any
serious business of any size.

You can’t have users’ personal data lingering in a soup of opaque cloud
continuations for months. There needs to be a way to strongly commit deletions
and audit that the data is gone. And once you build that on top of the
“Internet Computer”, my guess is that it will look disappointingly like a very
slow ordinary database.

------
miki123211
IMO, the next step for distributed programming, and one web assembly could
finally enable, will be communicating with code, not messages.

Imagine you're building an app that lets users of a music streaming service
see how much time they spent listening to particular genres of music.

The way you would do this with REST, SOAP or similar could roughly be:

1\. Retrieve the user's whole listen history.

2\. For each track, send a request to get the track info, which includes album
and duration.

3\. For each album, retrieve the album info, which contains the genre.

4\. Tabulate the returned data.

That's thousands of requests, and a lot of network bandwidth wasted.

GraphQL is a bit better, you only receive what you need, and you send just one
request, but you still get a whole lot of track objects, which need to go
through the network and be processed on your side.

With my proposed approach, you would send a piece of wasm code, a bit similar
to a Lambda function, which would run on the streaming service's API cloud.

Such a function could use fine-grained API calls to retrieve what it needs. It
would be executing on the service's network, so round trips would be either
short or nonexistent. After tabulating the data, it would send back a simple
JSON with the genres and time spent.

This approach would allow developers to extend any service in ways the
original developers have never imagined. We could also re-think the way
backends and frontends communicate, giving frontend devs a way to do even
more, without changing the back end.

~~~
riwsky
You’re really on to something with this query language for structured data
idea! I’d find it super-useful as a dev to be able to think of a backing
service not as a set of disconnected endpoints, but a base of operations for
dealing with data.

If only such structured query language data bases existed, I bet they would
get a lot of use.

(No but really: how is what you’re describing meaningfully different from SQL,
especially with the restrictions you’d want to put on the code in practice?)

~~~
nawgz
I agree with your comment highly.

I also find the idea of arbitrary code execution on a remote host to build a
derivative service to be a quite naive point-of-view. Even if you can validate
that the code isn't going to pwn you - a mighty stretch - how can one justify
being a recipient of free compute cycles on someone else's infra? It's not
quite realistic to me

~~~
miki123211
> I also find the idea of arbitrary code execution on a remote host to build a
> derivative service to be a quite naive point-of-view. Even if you can
> validate that the code isn't going to pwn you - a mighty stretch

Be aware that's exactly what you are doing when you go to any modern site. You
let a remote server execute arbitrary code on your computer, trusting it's not
going to pwn you. Sure, there were tons of loopholes in the first few years of
JS, but now browsers and operating systems are so secure that it's mostly a
non-issue. Web assembly is a sandboxing-first technology, so I don't think
it's an impossible or even a particularly hard issue to solve.

>how can one justify being a recipient of free compute cycles on someone
else's infra? It's not quite realistic to me

Well, there are API call limits, or something equivalent to them. Maybe
computing credits in this instance. Calculating how much computing resources
you're using is something that i.e. AWS Lambda does already, no reason why an
open-source runtime couldn't do so either. The fact it wouldn't be native
code, executed directly by the CPU, but Wasm executed by a VM, makes things
even simpler.

~~~
nawgz
>but now browsers and operating systems are so secure that it's mostly a non-
issue

Right, which is the point - it took an absolutely behemoth effort backed by
megacorps to get us to this point. These applications are public-facing
because that's the key way for the corps to make money - content delivery.

Why would anyone put this same effort into building more complicated internal
services _enabling derivative services to extract value from their platform_?

> Calculating how much computing resources you're using is something that i.e.
> AWS Lambda does already

Yes, exactly - another megacorp built a service that makes them huge amounts
of money, and now they sell access to it. This code is certainly not publicly
accessible

So, again, help me bridge this gap - what possible reason would Spotify (to
further GP's example) build such a platform for? This means that Spotify needs
to maintain massively more infrastructure in order to help _others_ extract
value from their platform.

It just doesn't check out. Is it objectively a more efficient method of
computation? Yes. Is it also completely misaligned with corporate incentives
in the modern day? In my opinion, yes.

------
vorpalhex
> and of course it has a flexible type system that is actually sound, ... No
> holes!

And this is where I went from "good faith reading" to actually not believing
the article. Every general language that has made this claim has had holes -
and those holes are usually patchable, but to claim a language with almost no
adoption is leak proof is foolhardy at best. Just because you haven't
discovered how your particular abstraction is broken doesn't mean it isn't.

~~~
norswap
Copy/pasted from google search:

> A sound type system means you can never get into a state where an expression
> evaluates to a value that doesn't match the expression's static type.

It's not actually _that_ hard to make a provably sound type system. The claim
can only strain belief if it includes some type-level feature that makes this
difficult.

Of course, it should also be proved. e.g. Java's type system is not sound even
though there is no good design reason while it shouldn't be (to be fair - it
only happens in cases so intricately twisted that nobody will ever stumble on
them by accident).

------
whateveracct
The programming model seems nice (orthogonal persistence especially), but the
fact that it's running decentralized is a big cost.

Maybe someone will provide the same developer niceness in a traditional cloud
way. The only people who would prefer DFINITY at that point are people who
really care about decentralization (which is fewer than the marketing hype
suggests imo.)

------
sventhereturned
Disclosure: I work at DFINITY, but not on this team. I can probably answer
most questions folks may have...

~~~
marvy
If I understand the persistence stuff correctly, programs don't do explicit
I/O but instead just run forever and thus use normal variables and data
structures to store state.

This sounds very convenient until one fine day you decide add a new feature,
so you need to change your code, but the new code has different variables and
there may not be any sensible way to "port" the data.

~~~
jpalomaki
” Motoko provides numerous features to help you leverage this environment,
including language features that allow your heap to self-migrate when you
upgrade the software of a canister.” [https://sdk.dfinity.org/docs/language-
guide/motoko.html](https://sdk.dfinity.org/docs/language-guide/motoko.html)

So in this sense it could be a bit like creating migrations to your database.
Maybe on ”cloud scale” you just would like to migrate the data when it is
used.

Edit: Few more details in this document:
[https://sdk.dfinity.org/docs/language-guide/actors-
async.htm...](https://sdk.dfinity.org/docs/language-guide/actors-async.html)

~~~
marvy
Okay, so the magic ingredient is that variables that are marked "stable" are
treated specially. Nice!

------
dgellow
No code examples in the entire article?

~~~
jmull
I was thinking it might be AI-generated, and while it could string together
these common concepts very impressively, it could not generate code samples.

But I suppose it’s probably actually the kind of article the AI engines digest
in order to be able to generate similar ones.

------
daxfohl
I keep seeing that wasm is safe and secure. But to my understanding wasm is
just a bytecode spec. The interpreters are what have to be judged secure. If
an interpreter has a hole then the sandbox is escapable. As you add jits and
various cpu optimizations and other options, the more likely there's a bug
there somewhere someone can exploit. I don't understand. Is there a
mathematical way to verify that a wasm interpreter is secure?

~~~
IncRnd
Yes, there is, but you need to define what it should be secure against. Then,
a proof can be constructed, given particular assumptions. I doubt this will
ever be done for wasm.

------
foxes
Sounds a bit like Ethereum but without a cryptocurrency?

~~~
SkyMarshal
It’s more like Solidity done right, by a team of expert language designers.
It’s the scripting language for DFINITY, so it does actually have a token,
fwiw.

------
M0T0K0
Perhaps I should learn this? ;)

Idk web assembly yet though, scanning to figure out how this could be useful
for an amateur web-dev.

~~~
lukevp
Don’t learn this or web assembly, learn TypeScript and then Rust. TS will
teach you a lot about type systems, classes, modules, interfaces, async/await,
etc. Rust will teach you about memory management, filter expressions, futures,
(im)mutability, etc. They are both mature languages that are usable in your
web dev context and that you’ll be able to find resources to learn. No one is
writing WebAssembly manually, it’s even lower level than regular assembly. It
would be super painful to write directly, it’s meant as a virtual architecture
that can be efficiently executed.

------
Kinrany
Makes me think we're close to the stage where different languages can be
easily combined in the same project, and therefore can be created willy-nilly
as easily as DSLs in Lisps.

~~~
lukevp
This already exists on the JVM or the .NET CLR. The concept of an intermediate
language is also old. It’s easy to call between languages as well. The
“innovation” is really the true OO nature of everything being message passing,
and no real persistence mechanism.

------
qazpot
So, this is Erlang.

------
marta_morena_25
That sounds more like clickbait. Just as if someone took the latest marketing
buzzwords and somehow tried to make a product out of it. If there was any meat
to this, they would lead with the use case and say "Hey here: This is the
problem the world has. Here is how we solved it". But anything blockchain
related already went more like "Uhh look, here is a blockchain. Enjoy". This
is worse...

This seems to be just like Ethereum without the blockchain. What does
"building directly on the internet" even mean? What do I ever need
distributed, cryptographic consensus for? The use-case escapes me completely,
this even seems more useless than Ethereum, where I can see at least some
applications thanks to the blockchain. But that thing without the blockchain
just doesn't make any sense. But hey, it got WASM, so must be cool.

~~~
mpfundstein
the fact that you call Ethereum useless shows that you are way too ignorant to
voice such a strong opinion.

educate yourself and try again.

i work with bchains since 2013 and ethereum is a major driver for a lot of
innovation and real life applications. i've built an energy trading platform
on top of it that allows local business to localize their energy management.
its deployed and working, granted , in a small poc here in Adam. but still.

also what do you think powers 99% of all altcoins?

~~~
gverrilla
is there a hub of some sort to follow ethereum projects? last time I checked
(few months I believe) cryptocats was the app with more activity. also I'm
curious about your project, if there's anything you're willing to share

~~~
intotheabyss
Just search for DeFi (decentralized finance).

------
browsergap
Ghost in the shell reference? Motoko Kusanagi

~~~
wonks
Ah, I was wondering which anime they were referring to with this...

------
Hazae41
[https://xkcd.com/927/](https://xkcd.com/927/)

~~~
rainpain
I think the guy who made the internet is also trying to fix the worst bits
rather than reinventing it. I'm backing Mr Berners-Lee.
[https://en.m.wikipedia.org/wiki/Solid_(web_decentralization_...](https://en.m.wikipedia.org/wiki/Solid_\(web_decentralization_project\))

