TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Motoko, a programming language for building directly on the internet

155 点作者 markdog12超过 4 年前

16 条评论

tines超过 4 年前
Looks cool. One thing though, the page says<p>&gt; 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)<p>This isn&#x27;t really true afaik. You can still have logical race conditions if you don&#x27;t synchronize messages (but they won&#x27;t be architectural races), and you can still have deadlocks if two actors wait on messages from each other at the same time.<p>I feel like people often treat race conditions and deadlocks as small, computer-architecture ideas when really they&#x27;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.
评论 #24296189 未加载
tlack超过 4 年前
Code sample:<p>Actor model with explicit synchronicity and access scoping:<p><pre><code> actor Counter { var value = 0; public func inc() : async Nat { value += 1; return value; }; } </code></pre> Types and specificity:<p><pre><code> type Tree&lt;T&gt; = { #leaf : T; #branch : {left : Tree&lt;T&gt;; right : Tree&lt;T&gt;}; }; func iterTree&lt;T&gt;(tree : Tree&lt;T&gt;, f : T -&gt; ()) { switch (tree) { case (#leaf(x)) { f(x) }; case (#branch{left; right}) { iterTree&lt;T&gt;(left, f); iterTree&lt;T&gt;(right, f); }; } } </code></pre> Source: <a href="https:&#x2F;&#x2F;sdk.dfinity.org&#x2F;docs&#x2F;language-guide&#x2F;motoko.html" rel="nofollow">https:&#x2F;&#x2F;sdk.dfinity.org&#x2F;docs&#x2F;language-guide&#x2F;motoko.html</a><p>Not to my taste personally.
评论 #24291287 未加载
评论 #24290721 未加载
评论 #24290271 未加载
评论 #24296493 未加载
评论 #24290632 未加载
RcouF1uZ4gsC超过 4 年前
&gt; 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.<p>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 &quot;Internet Computer persistence pod&quot;, that is a huge issue.
评论 #24291705 未加载
miki123211超过 4 年前
IMO, the next step for distributed programming, and one web assembly could finally enable, will be communicating with code, not messages.<p>Imagine you&#x27;re building an app that lets users of a music streaming service see how much time they spent listening to particular genres of music.<p>The way you would do this with REST, SOAP or similar could roughly be:<p>1. Retrieve the user&#x27;s whole listen history.<p>2. For each track, send a request to get the track info, which includes album and duration.<p>3. For each album, retrieve the album info, which contains the genre.<p>4. Tabulate the returned data.<p>That&#x27;s thousands of requests, and a lot of network bandwidth wasted.<p>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.<p>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&#x27;s API cloud.<p>Such a function could use fine-grained API calls to retrieve what it needs. It would be executing on the service&#x27;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.<p>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.
评论 #24294070 未加载
评论 #24294409 未加载
评论 #24296667 未加载
评论 #24295247 未加载
评论 #24294538 未加载
评论 #24294402 未加载
vorpalhex超过 4 年前
&gt; and of course it has a flexible type system that is actually sound, ... No holes!<p>And this is where I went from &quot;good faith reading&quot; 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&#x27;t discovered how your particular abstraction is broken doesn&#x27;t mean it isn&#x27;t.
评论 #24294151 未加载
评论 #24294947 未加载
评论 #24294154 未加载
whateveracct超过 4 年前
The programming model seems nice (orthogonal persistence especially), but the fact that it&#x27;s running decentralized is a big cost.<p>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超过 4 年前
Disclosure: I work at DFINITY, but not on this team. I can probably answer most questions folks may have...
评论 #24290294 未加载
评论 #24293522 未加载
评论 #24290522 未加载
评论 #24290350 未加载
评论 #24290454 未加载
评论 #24269450 未加载
评论 #24295598 未加载
dgellow超过 4 年前
No code examples in the entire article?
评论 #24293228 未加载
daxfohl超过 4 年前
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&#x27;s a bug there somewhere someone can exploit. I don&#x27;t understand. Is there a mathematical way to verify that a wasm interpreter is secure?
评论 #24295194 未加载
foxes超过 4 年前
Sounds a bit like Ethereum but without a cryptocurrency?
评论 #24293877 未加载
评论 #24293904 未加载
评论 #24290926 未加载
评论 #24293739 未加载
M0T0K0超过 4 年前
Perhaps I should learn this? ;)<p>Idk web assembly yet though, scanning to figure out how this could be useful for an amateur web-dev.
评论 #24296465 未加载
Kinrany超过 4 年前
Makes me think we&#x27;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.
评论 #24296492 未加载
qazpot超过 4 年前
So, this is Erlang.
marta_morena_25超过 4 年前
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 &quot;Hey here: This is the problem the world has. Here is how we solved it&quot;. But anything blockchain related already went more like &quot;Uhh look, here is a blockchain. Enjoy&quot;. This is worse...<p>This seems to be just like Ethereum without the blockchain. What does &quot;building directly on the internet&quot; 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&#x27;t make any sense. But hey, it got WASM, so must be cool.
评论 #24293987 未加载
评论 #24292084 未加载
browsergap超过 4 年前
Ghost in the shell reference? Motoko Kusanagi
评论 #24293738 未加载
Hazae41超过 4 年前
<a href="https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a>
评论 #24294232 未加载
评论 #24293628 未加载