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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Inko Programming Language

195 点作者 gautamcgoel超过 1 年前

15 条评论

karmakaze超过 1 年前
&gt; Inko uses lightweight processes for concurrency, and its concurrency model is inspired by Erlang and Pony. Processes are isolated from each other and communicate by sending messages. Processes and messages are defined as classes and methods, and the compiler type-checks these to ensure correctness.<p>&gt; The compiler ensures that data sent between processes is unique, meaning there are no outside references to the data. This removes the need for (deep) copying data, and makes data races impossible. Inko also supports multi-producer multi-consumer channels, allowing processes to communicate with each other without needing explicit references to each other.<p>Now I&#x27;m very interested. I was wondering why with &#x27;actors&#x27; we&#x27;d still mark functions as async. It seems that a class marked async is analogous to an actor.<p><pre><code> class async Counter { let @value: Int fn async mut increment { @value += 1 } fn async send_to(channel: Channel[Int]) { channel.send(@value) } }</code></pre>
评论 #38271577 未加载
toastal超过 1 年前
&gt; To add a package, first create a GitHub repository for your package. While Inko&#x27;s package manager supports the use of any Git repository (e.g. one hosted on GitLab), the above list is populated using GitHub repositories only.<p>So another community that wants to lock itself into Microsoft products as well as Git in general. Why should a user’s choice for DVCS &amp; forge make them feel less supported or inferior?
评论 #38278282 未加载
评论 #38274420 未加载
评论 #38275496 未加载
评论 #38274580 未加载
评论 #38276254 未加载
评论 #38275743 未加载
dang超过 1 年前
Related. Others?<p><i>Show HN: Inko 0.10.0 – build concurrent software with confidence</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32811621">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=32811621</a> - Sept 2022 (3 comments)<p><i>Inko 0.5.0 released, featuring the first steps towards a self-hosting compiler</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20988908">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20988908</a> - Sept 2019 (7 comments)<p><i>Inko (a gradually-typed object-oriented programming language) 0.4.0 released</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19893035">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19893035</a> - May 2019 (1 comment)<p><i>Show HN: Inko – A safe and concurrent object-oriented programming language</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17702237">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17702237</a> - Aug 2018 (45 comments)
tedunangst超过 1 年前
This looks enough like rust that I&#x27;m not sure why I&#x27;d pick it over rust. What would be some concrete programs that would be difficult or tedious to write in rust and easy in inko? Could really use a section on &quot;here&#x27;s rust code you&#x27;d like to write but compiler won&#x27;t let you&quot; and how inko works.
评论 #38274360 未加载
评论 #38271900 未加载
评论 #38271983 未加载
sudarshnachakra超过 1 年前
I had been only following this language with some interest, I guess this was born in gitlab not sure if the creator(s) still work there. This is what I&#x27;d have wanted golang to be (albeit with GC when you do not have clear lifetimes).<p>But how would you differentiate yourself from <a href="https:&#x2F;&#x2F;gleam.run" rel="nofollow noreferrer">https:&#x2F;&#x2F;gleam.run</a> which can leverage the OTP, I&#x27;d be more interested if we can adapt Gleam to graalvm isolates so we can leverage the JVM ecosystem.
评论 #38275548 未加载
pvelagal超过 1 年前
Inko means “one more” in Telugu, a language spoken in South India (Satya Nadella’s mother tongue). So its one more programming language!
评论 #38273273 未加载
pmontra超过 1 年前
An advantage over Erlang and Elixir is that this looks like any language from the C&#x2F;Java family including all the clutter as in<p><pre><code> import std.fs.file.ReadOnlyFile import std.stdio.STDOUT class async Main { fn async main { </code></pre> We basically have a zero signal to noise ratio here but it&#x27;s a declarative pattern common to many successful languages so it will make many people feel at home. I think it&#x27;s a good design decision.<p>On the other side I feel like the naming decisions in the error handling section are weird. The expect method breaks my expectations:<p><pre><code> let file = ReadOnlyFile .new(&#x27;README.md&#x27;) .expect(&quot;the file doesn&#x27;t exist&quot;) file .read_all(bytes) .expect(&#x27;failed to read the file&#x27;) </code></pre> Well, no: I expect the file to exist and to be able to read from it.<p>An expect method is common in test libraries and it behaves like an assertion. When I see an expect method I expect it to have a condition and stop the program if it evaluates to false, or propagate the error in any way appropriate to the language. So I expected<p><pre><code> let file = ReadOnlyFile .new(&#x27;README.md&#x27;) .fail(&quot;no_ro&quot;, &quot;the file exists but it is not read only&quot;) .expect(&quot;created&quot;) .expect(&quot;open&quot;) </code></pre> I intentionally changed the probable behavior of the class, that seems not to create a read only file but only to open it. I made it create the file to show a softer version of expect() than an assertion. At least one of them must be true. The implementation of how to chain those methods without failing at the first failed expect() is a detail.<p>And about .unwrap_or(0), what that even means? The linked post [1] hints about a<p><pre><code> &quot;wrapper type,” like Maybe&lt;T&gt; </code></pre> so it&#x27;s an established naming convention in some language but if it works as I think, what about this?<p><pre><code> .default(0) </code></pre> That because unwrap_or seems to ignore errors and return a default. If it doesn&#x27;t, it confirms that it&#x27;s a bad name.<p>[1] <a href="https:&#x2F;&#x2F;joeduffyblog.com&#x2F;2016&#x2F;02&#x2F;07&#x2F;the-error-model&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;joeduffyblog.com&#x2F;2016&#x2F;02&#x2F;07&#x2F;the-error-model&#x2F;</a>
评论 #38275564 未加载
评论 #38273587 未加载
评论 #38336333 未加载
pzmarzly超过 1 年前
Given the big similarity to Rust, and having similar target group (people who care about concurrency in compiled languages), what made you decide to stray from Rust syntax @YorickPeterse ? Personal preference?<p>It&#x27;s all about small stuff like: `async fn` (Rust) vs `fn async` (Inko), skipping parens for 0-arity functions in Inko, `::` vs `.`, `Generic&lt;T&gt;` vs `Generic[T]`.
评论 #38286773 未加载
评论 #38278807 未加载
评论 #38289785 未加载
评论 #38276375 未加载
arp242超过 1 年前
Having pre-built binaries would be hugely helpful; I can&#x27;t get it to compile (can&#x27;t &quot;find&quot; LLVM, even though it&#x27;s installed and everything <i>should</i> be set up right – doesn&#x27;t help that llvm-sys error message isn&#x27;t very helpful in explaining what went wrong).<p>I have no doubt I could get it to work if I spent more time on it, but ... I have no idea of that&#x27;s going to be worth the effort, because I don&#x27;t know if Inko is even interesting for me, as I can&#x27;t actually try.
macintux超过 1 年前
Related discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38261982">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38261982</a>
alecthomas超过 1 年前
Are there binaries for ivm? If ivm is intended to make it easier to manage inko versions, having to install it via another language&#x27;s toolchain (Rust) seems a bit onerous.<p>Edit: Oh I see, ivm itself relies on Cargo to build inko rather than downloading binaries.<p>Still, it would be nice if it didn&#x27;t need another language&#x27;s toolchain just to use Inko :(
评论 #38275627 未加载
thatxliner超过 1 年前
&gt; Inko allows...moving of the borrowed values while borrows exist<p>Yet<p>&gt; With Inko you never again have to worry about NULL pointers, use-after-free errors, unexpected runtime errors, data races, and other types of errors commonly found in other languages<p>I’m wondering how that can possibly work? Surely the memory safety guarantees are not as strong as Rust’s guarantees.
评论 #38271627 未加载
评论 #38271593 未加载
评论 #38271286 未加载
评论 #38271249 未加载
api超过 1 年前
Seems like a very stripped down Rust.
评论 #38272752 未加载
评论 #38271792 未加载
评论 #38287966 未加载
matrix2596超过 1 年前
funny in my language inko (telugu) means another. so its yet another programming language.
评论 #38275695 未加载
librasteve超过 1 年前
Sadly another language with concurrency support that fails to learn the lessons from occam <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Occam_(programming_language)" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Occam_(programming_language)</a>.<p>Erlang, Go, Rust, Raku and now Inko all missed the point: 1. synchronous channels guarantee correctness 2. so the same code can be run concurrently (ie lightweight processes on one CPU) or in parallel mapped to multiple non shared memory CPUs
评论 #38276616 未加载
评论 #38392337 未加载