如何将 Erlang 推到我的工作场所
我认为 Erlang 非常适合我工作场所开发的服务器系统（目前使用 Java 开发）。我有点怀疑开发人员（他们对函数式或 Erlang 不了解）和管理者如何接受这一点。
关于如何处理这个问题有什么想法吗？我正在考虑一些混合系统，其中核心高度可靠的基础设施使用 Elrang，而应用程序特定的东西是用 Java 开发的（作为节点？）
I think Erlang is very well suited for server systems developed in my workplace (currently developed in Java). I am a bit skeptical how this would be accepted both by developers (who have no idea about functional or Erlang) and by managers.
Any ideas on how to approach the issue? I am thinking about some hybrid system, where the hardcore highly reliable infra uses Elrang, and app specific stuff developed in Java (as nodes?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
有几种方法，但都不能保证实际有效。
如果您工作的公司实际上已经拥有可用的 Java 代码库，那么当您建议用另一种语言重写它时，他们不太可能认真对待您。
您是否相信 Erlang 是一个更好的选择的真正考验是：退出并创办一家竞争公司，并带来您在当前行业中拥有的技术洞察力。你的经理实际上是在比较类似的风险场景，就像你辞职时会做的那样，他们正在寻找与你一样的成功保证事实，考虑留下“安全”的薪水。
至于如何集成，请查看Erlang中的jinterface应用程序。它允许 Java 代码向 Erlang 节点发送消息，并且允许 Java 将邮箱公开给 Erlang 节点，就像有 Erlang 进程一样。
There are a few approaches, and neither have any guarantees to actually work
If the company you work for actually have a working code base in Java already, they're not likely to take you seriously when you suggest to rewrite it in another language.
The true test that you believe in Erlang being a much better choice: Quit and start up a competing company and bring the technology insight you have in your current industry. Your managers are really comparing a similar risk-scenario as you would do if you were to quit your job, and they are looking for the same assuring facts for success as you would do, to consider leaving a "safe" paycheck.
As for how to integrate, check out the jinterface application in Erlang. It allows Java code to send messages to Erlang nodes, and it allows Java to expose mailboxes to the Erlang nodes as if there were Erlang processes.
对于经理来说，这一切都与 ROI（投资回报率）有关：经理会关心（公司的）绩效。为了迎合他的商业本质，你必须使用美元（或任何适当的货币）来证明这一点。
请注意，兼职开展一个“臭鼬工作”项目来“证明”你的基于 Erlang 的解决方案可能会适得其反：“既然你有时间玩 Erlang，那你为什么不花时间在这个项目上呢？” （当然，并不是所有的管理者/公司都会这样想）。
您必须考虑整个提案，例如对团队的影响、待开发的技能等。这都是关于金钱的。
如果我给你一个建议：从小事做起，种下一颗种子，培育它，看着它成长。
一位智者曾经对我说过：
It's all about ROI (Return On Investment) to a manager: a manager will be concerned about performance (of the company). In order to appeal to his business nature, you'll have to make a case for it using dollar$ (or whatever appropriate currency).
Beware that undertaking a "skunkwork" project on the side to "prove" your solution based on Erlang might backfire: "so you had time to play with Erlang, why didn't you spend the time on the project then?" (Of course, not all managers/companies would think this way).
You have to take into account the whole proposal e.g. impact on the team, skills to be developed etc. It's all about money.
If I have an advice for you: start small, plant a seed, nurture it and watch it grow.
A wise man once said to me:
首先不以重写为目标，而是使用 erlang 来实现新功能/项目。重写的成本可能很高，而在 erlang 上冒险去做一些本来就很耗时且成本高昂的事情是很难推销的。但如果有一个新的部分可以用 erlang 和 java 完成，你就有更好的机会。该项目将足够小，希望您能够尽早发现 erlang 是否合适并进行相应的调整。当 erlang 在该项目中证明自己时，您将拥有更好的数据来证明您的观点。
Start by not targetting a rewrite but using erlang for a new feature/project. Rewrites can be expensive and taking a chance on erlang for something that is already a time consuming and costly undertaking is a hard sell. But if there is a new piece that could be done in erlang and java, you stand a better chance. The project will be small enough hopefully that you can discover early if erlang is a good fit and adapt accordingly. And when erlang proves itself in that project you will have better data to make your case with.
我们将 RabbitMQ 引入我们的基础设施中，该基础设施目前运行 C++、Java 和 Python 应用程序的组合。我并不是特别打算让团队转向 Erlang，但如果我真的打算这样做，那么引入一个编写良好且恰好使用 Erlang 的第三方工具是一个非常好的入门方法。
一个主要的警告是，虽然 Erlang 是一门非常值得学习的语言，但其周边技术（特别是 OTP）具有巨大的学习曲线，并且在许多方面（调试、IDE 等）都极其原始。它一直在变得更好，但如果你不警告那些不情愿的皈依者在完全不同的环境中学习编程的痛苦，他们就会把你钉在十字架上。即使是简单的事情，比如缺乏代码感知技术（例如，输入“foo.”，IDE 会告诉您可以在 foo 上调用哪些方法）也会给人留下非常糟糕的印象。
We're introducing RabbitMQ into our infrastructure, which currently runs a combination of C++, Java and Python applications. I'm not specifically intending to move the team towards Erlang, but if I were, introducing a well-written third-party tool that just happens to use Erlang is a very good way to get the foot in the door.
One major caveat is that while Erlang is a wonderful language to learn, the surrounding technology (OTP in particular) has a huge learning curve and is extremely primitive in many ways (debugging, IDE's, etc.). It is getting better all the time, but reluctant converts will crucify you if you don't warn them about the pain of learning to program in a radically different environment. Even simple things like the lack of code-sense technology (E.g., type 'foo.' and the IDE tells you what methods you can call on foo) can leave a really bad taste in the mouth.