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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Go Execution Modes

111 点作者 Rooki超过 10 年前

9 条评论

personZ超过 10 年前
The dogma about preventing the sharing of pointers with C is a bit concerning. I&#x27;ve made use of that mechanism, to fantastic effect, albeit understanding the risks and consequences. The notion that it must be prevented because bad things can happen if you aren&#x27;t careful isn&#x27;t a starter, as there are essentially zero people doing that who&#x27;ve had problems. Instead a lot of people have enjoyed fantastic productivity because of the similarities of the implementations, and the synergy that allows.<p>But the team wants move to a compacting GC. Fine, add pin&#x2F;unpin idioms. This ground has been well covered by other languages. Don&#x27;t completely destroy a very productive mechanism because in some oddball cases it might not work.
评论 #8268475 未加载
评论 #8268764 未加载
评论 #8267790 未加载
pauldix超过 10 年前
This would be awesome to have. +1!<p>With InfluxDB we want to give users the ability to define custom functions and it looks like this could be used to let people do that in Go or any language really. Whereas right now we&#x27;re limited to doing something like using LuaJIT.
axaxs超过 10 年前
I would love to see the gc compiler support building dynamically linked executables against a libgo runtime Ala gccgo. Unless I&#x27;m misreading, this case doesn&#x27;t seem covered. I love the standalone binary deployment ease as of now, but on a machine with tens of go applications, the binary size redundancy gets old. Or did I miss something?
评论 #8267204 未加载
评论 #8267632 未加载
评论 #8269031 未加载
Rapzid超过 10 年前
I think the more relevant news in there for most is the support for dynamic&#x2F;runtime loading. The title here makes it sound like it&#x27;s just for dynamic linking but I read the article to article to be sure and was pleasantly surprised :)
评论 #8267004 未加载
lobster_johnson超过 10 年前
&gt; Building Go packages as a shared library<p>Yes, please! We have a few potential Go projects which are blocked by the inability to separate Go code into plugins.<p>I have toyed with the idea of forking child processes and implementing plugins via pipe I&#x2F;O, but that&#x27;s a very unfriendly API interface, and I don&#x27;t feel very inspired. (Go isn&#x27;t that great at POSIX stuff like forking, either.)
评论 #8268693 未加载
bkeroack超过 10 年前
I realize it&#x27;s just an early draft, but it&#x27;s interesting (alarming?) that the proposed plugin API has no facilities for plugin discovery or separate namespaces. Nor any apparent ability for the plugin consumer to introspect into plugins.<p>I suppose the namespace issue can be mitigated by a strict naming convention (something like &quot;[application_name].[plugin_name]&quot;), but the others are kind of a bummer.<p>I don&#x27;t have a whole lot of positive things to say about the Python setuptools API (perhaps better called &quot;lack-of-API internal interface&quot;), but at least it&#x27;s possible to dynamically load python plugins from arbitrary locations in the filesystem and programmatically discover their contents.
评论 #8269884 未加载
评论 #8269473 未加载
easytiger超过 10 年前
Is there a mirror? For those of us in the corporate wasteland this is not accesible
JuiceSSH超过 10 年前
Interesting that it will allow compilation of PIE executables. This is a mandatory requirement for any binaries run on newer versions of Android (L+).
评论 #8267798 未加载
frik超过 10 年前
The doc doesn&#x27;t mention a timeline or Go version when we may see the new planned features.
评论 #8267107 未加载