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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Erlang/OTP 24 highlights

454 点作者 nifoc大约 4 年前

17 条评论

travisgriggs大约 4 年前
&gt; there are still 260k lines of code added and 320k lines removed<p>So a net reduction of 60K lines of code? And yet functionality was added to the system as well. That&#x27;s praiseworthy IMO.<p>Imagine if &quot;we did more with less&quot; infected much of software development today.
评论 #27131906 未加载
评论 #27132180 未加载
评论 #27146531 未加载
rubyn00bie大约 4 年前
OMG, YES! The JIT is here... and holy crap, if you haven&#x27;t tried it yet... it&#x27;s awesome (everything feels snappier). I&#x27;m particularly stoked for the receive optimizations and process aliases.<p>BEAM just gets better and better. It&#x27;s a good time to be an Erlanger&#x2F;Elixirist...
评论 #27137052 未加载
评论 #27130988 未加载
评论 #27131735 未加载
macintux大约 4 年前
Erlang has long, long needed better error messages. These changes look very welcome.<p>Overall this looks like quite a nice set of improvements. Kudos to the team.
评论 #27129322 未加载
sgrytoyr大约 4 年前
Working with Elixir on a daily basis is mostly a pleasure, but those &quot;ArgumentError&quot; errors have been super annoying.<p>Looks like Elixir 1.12 will take full advantage of EEP 54:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;elixir-lang&#x2F;elixir&#x2F;releases&#x2F;tag&#x2F;v1.12.0-rc.0" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;elixir-lang&#x2F;elixir&#x2F;releases&#x2F;tag&#x2F;v1.12.0-r...</a>
评论 #27131060 未加载
semilattice大约 4 年前
Seems like there is less and less reason for not using Erlang for distributed coordinated compute broker tasks.<p>I have a stateless java backend servicing REST APIs. These backends are load-balanced by nginx.<p>Now the time is approaching where I need to introduce some form of global state (that involves global caching, message passing, registering&#x2F;discovery of known workers, periodic (cron-like tasks), etc).<p>I would much prefer a single tool to add to my backend stack (currently Java + postgres) to cover most of the above needs.<p>With the performance improvement + persistent_term [1] -- in current Erlang, I basically get:<p>- a light weight distributed K&#x2F;V cache<p>- a ZeroMQ like on-wire messaging system (built into erlang)<p>- discovery&#x2F;coordination<p>- a distributed compute grid<p>- a way to write my own routines within that compute grid, and have them exposed via Java interface to my existing backend.<p>I do not need &#x27;fastest&#x27; possible performance or least memory consumption. I just need them to be &#x27;reasonable&#x27;, &#x27;known&#x27; and &#x27;controllable&#x27; (not to exceed some baseline).<p>Erlang is just looking better and better (and I prefer its syntax to Elixir, for some reason.).<p>[1] <a href="https:&#x2F;&#x2F;erlang.org&#x2F;doc&#x2F;man&#x2F;persistent_term.html" rel="nofollow">https:&#x2F;&#x2F;erlang.org&#x2F;doc&#x2F;man&#x2F;persistent_term.html</a>
评论 #27140957 未加载
namelosw大约 4 年前
Nice update on the error message!<p>Speaking of error message. I love that Erlang gives the exact parameter values in the call stack. (I guess this is generally possible because immutable data structures are enforced in the whole language?) It saves a lot of time than just speculating with call stack only.
exciteabletom大约 4 年前
I love the new error messages. Rust seems to have started that trend, Python also added better errors recently.
评论 #27131944 未加载
评论 #27129998 未加载
评论 #27130779 未加载
评论 #27129301 未加载
评论 #27129727 未加载
niho大约 4 年前
Improved error messages is great. But one area specifically that is in desperate need of some love is the type errors from Dialyzer. They are rarely helpful to identify what is actually wrong in the code. Typically the error message will point to something several layers up or down in the call stack and prints out a huge blob of unreadable and unhelpful type signatures. Most of the time the best you can do is to simply compile and run the system to figure out what is wrong with the types. The obscurity of the type errors remind me of C++ template errors.
评论 #27134257 未加载
AlchemistCamp大约 4 年前
I&#x27;ve been looking forward to the JIT for months. This is fantastic!
评论 #27129797 未加载
mrslave大约 4 年前
Slightly off-topic from someone who hasn&#x27;t touched Erlang in almost 20 years: if my app is distributed with Erlang&#x2F;Elixir, I kind of feel like my choice of database should be something with excellent horizontal scaling too. Can someone offer some insight into the trends in 3rd-party tools like databases for Erlang applications?
评论 #27131776 未加载
评论 #27131769 未加载
评论 #27133148 未加载
评论 #27132011 未加载
评论 #27131707 未加载
tiffanyh大约 4 年前
BeamASM vs HiPE?<p>Since BeamASM doesn&#x27;t support HiPE - has anyone seen benchmarks of BeamASM (JIT) vs HiPE. I&#x27;ve searched and searched and can&#x27;t find such analysis.<p>(Super excited the JIT work is seeing light after 10+ years)
评论 #27138780 未加载
评论 #27132213 未加载
评论 #27133235 未加载
评论 #27135179 未加载
评论 #27132857 未加载
fredrikholm大约 4 年前
Always puts a smile on my face when I read these, the team does an amazing job. Cheers! :)
btbuildem大约 4 年前
Sometimes I&#x27;ll sit there, look at the error trying to decipher it, and I forget who I am and what I was doing.<p>Great work on the improvements!
lpgauth大约 4 年前
I&#x27;m going to miss those `badarg` errors :D
评论 #27130597 未加载
评论 #27132931 未加载
评论 #27130548 未加载
dang大约 4 年前
One past thread:<p><i>Erlang&#x2F;OTP 24 Release Candidate 1</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26260127" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26260127</a> - Feb 2021 (15 comments)
truth_seeker大约 4 年前
Adoption of JIT on robust platform like BEAM is excellent news. Although i would wait for one or more release major releases till I see the significant improvement in computational aspect of the code.
gideon13大约 4 年前
bring on the ARM support