在 Google App Engine 上选择 Java 还是 Python答案

【问题标题】：Choosing Java vs Python on Google App Engine在 Google App Engine 上选择 Java 还是 Python
【发布时间】：2010-11-08 07:48:08
【问题描述】：

目前，Google App Engine 支持 Python 和 Java。 Java 支持不太成熟。但是，Java 似乎有更长的库列表，尤其是对 Java 字节码的支持，而不管用于编写该代码的语言是什么。哪种语言会提供更好的性能和更强大的功能？请指教。谢谢！

编辑： http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1

编辑： 我所说的“力量”是指更好的可扩展性和包含框架外的可用库。不过，Python 只允许使用纯 Python 库。

【问题讨论】：

现在 Google App Engine is supporting 去（实验）。你对此有何难处？
@pinouchon 我已经开始使用 Go，并将其部署在 GAE 的生产环境中。 GO 在 GAE 上运行良好，几秒钟就可以编译。明智地选择你的网络框架:-)

标签： java python google-app-engine google-cloud-platform google-app-engine-python

【解决方案1】：

我有偏见（作为一名 Python 专家，但在 Java 方面相当生疏），但我认为 GAE 的 Python 运行时目前比 Java 运行时更先进，开发得更好——前者还有一年的时间来开发和成熟，毕竟。

事情将如何发展当然很难预测——Java 方面的需求可能会更强（尤其是因为它不仅与 Java 有关，而且其他语言也位于 JVM 之上，所以这是实现在 App Engine 上运行例如 PHP 或 Ruby 代码）；然而，Python App Engine 团队确实拥有加入 Python 的发明者和非常强大的工程师 Guido van Rossum 的优势。

就灵活性而言，如前所述，Java 引擎确实提供了运行由不同语言（而不仅仅是 Java）生成的 JVM 字节码的可能性——如果您在一家多语言商店，这是一个很大的积极因素。反之亦然，如果您讨厌 Javascript 但必须在用户的浏览器中执行一些代码，Java 的 GWT（从您的 Java 级编码为您生成 Javascript）比 Python 端的替代方案（实际上，如果您选择Python，您将为此目的自己编写一些 JS，而如果您选择 Java，如果您讨厌编写 JS，GWT 是一个可用的替代方案。

就库而言，这几乎是一种清洗——JVM 受到足够多的限制（没有线程、没有自定义类加载器、没有 JNI、没有关系数据库），从而阻碍了现有 Java 库的简单重用，或者更多，与现有的 Python 库相比，Python 运行时的类似限制同样受到了阻碍。

在性能方面，我认为这是一种洗牌，尽管您应该对自己的任务进行基准测试——不要依赖高度优化的基于 JIT 的 JVM 实现的性能而忽略它们的大量启动时间和内存占用，因为应用程序引擎环境非常不同（启动成本将经常支付，因为您的应用程序的实例被启动、停止、移动到不同的主机等，所有这些对您来说都是透明的——这些事件在 Python 运行时环境中通常比使用便宜得多JVM）。

XPath/XSLT 情况（委婉点......）在任何一方都不是完美的，叹息，虽然我认为它在 JVM 中可能没有那么糟糕（显然，Saxon 的大量子集可以是运行，小心）。我认为值得在标题中包含 XPath 和 XSLT 的 Appengine Issues 页面上打开问题——现在只有要求特定库的问题，这是短视的：我并不关心如何实现一个好的 XPath/XSLT ，对于 Python 和/或 Java，只要我能够使用它。（特定的库可能会简化现有代码的迁移，但这不如能够以某种方式执行诸如“快速应用 XSLT 转换”之类的任务！-）。我知道如果措辞得当（尤其是在与语言无关的方式），我会为这样的问题加注星标。

最后但同样重要的是：请记住，您可以拥有不同版本的应用程序（使用相同的数据存储），其中一些使用 Python 运行时实现，一些使用 Java 运行时实现，并且您可以访问不同于“默认/活动”一个具有显式 URL。因此，您可以让 Python 和 Java 代码（在您的应用程序的不同版本中）使用和修改相同的数据存储，从而为您提供更大的灵活性（尽管只有一个具有“好”的 URL，例如foobar.appspot.com——我想这可能只对交互式用户在浏览器上的访问很重要；-)。

【讨论】：

GWT 主要是一种客户端技术——无论您的后端是 python 还是 java，您都可以使用它。由于必须在 JSON 上执行 rpc 而不是 GWT 内置的 RPC，因此您失去了一些语法糖，但是如果您讨厌 JS 并使用 python，它仍然值得一看:)
有睡衣 (pyjs.org) 作为 GWT 的 Pythonic 替代品 - 它会使用 Python 代码并将其编译为 Javascript，就像 GWT 为 Java 代码所做的那样。
只是为了给出一个“5年后”的观点。作为一名 Java 开发人员，我觉得 GAE 正在运行一个过时的堆栈。你不会找到Java 8 support、（they are running Java 6 以及带有Servlet API 2.5 的遗留 Jetty 6 容器），总而言之，GAE 中的 Java 支持仍然停留在 2010 年。虽然我喜欢 GAE 的简单性和 Google 强大的服务，但我可以'在他们升级其堆栈之前，不要推荐 GAE for Java。

【解决方案2】：

观看此应用了解 Python 和 Java 性能的变化：

http://gaejava.appspot.com/ （编辑：抱歉，链接现在已断开。但是当我看到它最后运行时，以下段落仍然适用）

目前，Python 和使用 Java 中的低级 API 比 Java 上的 JDO 更快，对于这个简单的测试。至少如果底层引擎发生变化，该应用应该反映性能变化。

【讨论】：

恕我直言，我发现这个测试简单到毫无意义。对于它的价值...如果您确实使用 Java/GAE，我建议使用低级 API 并避免使用 JDO 或任何其他框架。更重要的是，JDO 为您提供了正在使用关系数据库的“感觉”，这可能会产生“误导”。
我同意避免使用 JDO，部分原因是您提到的原因，但也因为它比低级慢。（测试通常显示。）它只是暗示存在性能差异，因此要么不要使用 JDO，要么针对您的特定任务进行测试。我已将我自己的所有代码从 JDO 和低级 API 移至 Objectify。无论如何，这也表明 Python 肯定不是 GAE 性能的差表亲。
你的应用，它正在抛出内部服务器错误。
谢谢汤姆。可悲的是，不是我的应用程序。已经邮寄了可能有联系的人。
我想看看objectify在这个测试中的比较

【解决方案3】：

根据在其他平台上运行这些 VM 的经验，我认为 Java 可能会比 Python 获得更多的原始性能。但是，不要低估 Python 的卖点：Python 语言在代码行方面的生产力要高得多——普遍的共识是，Python 需要等效 Java 程序的三分之一代码，同时保持相同或更高的可读性。无需显式编译步骤即可立即运行代码的能力使这一优势倍增。

关于可用的库，您会发现大部分 Python 运行时库都是开箱即用的（Java 也是如此）。 AppEngine 也支持流行的 Django Web 框架 (http://www.djangoproject.com/)。

关于“权力”，很难理解您的意思，但 Python 用于许多不同的领域，尤其是 Web：YouTube 和 Sourceforge 都是用 Python 编写的（截至上周）。

【讨论】：

谢谢 Judy2K！我所说的权力是指可以做更多的事情并且易于扩展。

【解决方案4】：

2013 年 6 月：这个视频是谷歌工程师的一个很好的回答：

http://www.youtube.com/watch?v=tLriM2krw2E

TLDR;是：

选择您和您的团队最高效的语言
如果您想为生产构建一些东西：Java 或 Python（不是 Go）
如果您有一个大团队和复杂的代码库：Java（因为静态代码分析和重构）
快速迭代的小团队：Python（尽管 Java 也可以）

【讨论】：

【解决方案5】：

在选择 Python 和 Java 时要考虑的一个重要问题是您将如何使用每种语言的数据存储（本主题已经很好地涵盖了原始问题的大多数其他角度） .

对于 Java，标准方法是使用 JDO 或 JPA。它们非常适合可移植性，但不太适合数据存储。

有一个低级 API 可用，但这对于日常使用来说太低级了 - 它更适合构建 3rd 方库。

对于 Python，有一个 API 专门设计用于为应用程序提供对数据存储的简单而强大的访问。它很棒，只是它不可移植，因此会将您锁定在 GAE 中。

幸运的是，针对两种语言列出的弱点正在开发解决方案。

对于 Java，低级 API 用于开发比 JDO/JPA (IMO) 更适合数据存储的持久性库。示例包括 Siena project 和 Objectify。

我最近开始使用 Objectify，发现它非常易于使用并且非常适合数据存储，而且它的日益流行已转化为良好的支持。例如，Google 的新 Cloud Endpoints 服务正式支持 Objectify。另一方面，Objectify 仅适用于数据存储，而 Siena 受到数据存储的“启发”，但旨在与各种 SQL 数据库和 NoSQL 数据存储一起使用。

对于 Python，正在努力允许在 GAE 之外使用 Python GAE 数据存储 API。一个例子是谷歌发布的用于 SDK 的 SQLite 后端，但我怀疑他们是否打算将其发展为可用于生产的东西。 TyphoonAE 项目可能具有更大的潜力，但我认为它还没有准备好生产（如果我错了，请纠正我）。

如果有人对任何这些替代方案有经验或知道其他人，请在评论中添加它们。就个人而言，我真的很喜欢 GAE 数据存储 - 我发现它比 AWS SimpleDB 有了很大的改进 - 所以我希望这些努力能够成功，以缓解使用它时的一些问题。

【讨论】：

【解决方案6】：

我强烈推荐 Java 用于 GAE，原因如下：

性能：Java 可能比 Python 更快。
Python 开发面临缺乏第三方库的压力。例如，根本没有用于 Python/GAE 的 XSLT。几乎所有 Python 库都是 C 绑定（GAE 不支持这些）。
Memcache API：Java SDK 比 Python SDK 有更多有趣的功能。
数据存储区 API：JDO 非常慢，但原生 Java 数据存储区 API 非常快速和简单。

我现在在开发中使用 Java/GAE。

【讨论】：

@Paul - 如果 JDO 不可行，您能否推荐（或提供链接）在 GAE 上使用 Java 处理持久性的最佳方法？
@Mark，抱歉耽搁了。我认为code.google.com/p/objectify-appengine 是目前最好的选择。
-1 表示第 2 点和第 3 点中的彻头彻尾的谎言，而第 4 点没有任何意义。
@Triptych，让我知道用于 python/GAE 的 XSLT 处理器的名称是什么？ memcache/python/GAE 的 CAS(putIfUntouched) 操作相当于什么？
@Paul 如果您希望我将这些内容视为您的答案的一部分，您应该将它们包含在您的答案中。相反，你包括了一串半真半假的事实。没有人会根据您现在提出的极端案例来选择一种语言。

【解决方案7】：

如您所见，使用 JVM 并不限制您使用 Java 语言。可以在here 找到 JVM 语言列表和链接。但是，Google App Engine 确实限制了您可以在普通 Java SE 集中使用的类集，您需要调查是否可以在应用引擎上使用这些实现。 p>

编辑：我看到你找到了这样一个列表

我无法评论 Python 的性能。然而，JVM 在性能方面是一个非常强大的平台，因为它能够在运行时动态编译和优化代码。

最终的性能将取决于您的应用程序的功能以及您的编码方式。在没有更多信息的情况下，我认为不可能在这方面给出更多的指示。

【讨论】：

感谢您的及时回复，Brian。我打算将应用程序重点放在 url 获取和 XML 解析和 XSLT 处理上。向浏览器提供 HTTP 内容的次数将会减少。

【解决方案8】：

我对 Python/Django SDK 的简洁、直接和无问题感到惊讶。然而，我开始遇到需要开始做更多 JavaScript 的情况，并认为我可能想要利用 GWT 和其他 Java 实用程序。我刚刚完成了 GAE Java 教程的一半，并且遇到了一个接一个的问题：Eclipse 配置问题、JRE 版本问题、Java 令人麻木的复杂性，以及一个令人困惑且可能损坏的教程。查看此站点以及从此处链接的其他站点对我来说很重要。我要回到 Python，我会研究睡衣来帮助我应对 JavaScript 挑战。

【讨论】：

【解决方案9】：

我的谈话有点晚了，但这是我的两分钱。我真的很难在 Python 和 Java 之间做出选择，因为我精通这两种语言。众所周知，两者都有优点和缺点，您必须考虑您的要求和最适合您的项目的框架。

就像我通常在这种困境中所做的那样，我会寻找数字来支持我的决定。我决定使用 Python 的原因有很多，但就我而言，有一个情节是引爆点。如果您在 GitHub 中搜索截至 2014 年 9 月的“Google App Engine”，您会发现如下图：

这些数字可能存在许多偏差，但总体而言，GAE Python 存储库的数量是 GAE Java 存储库的三倍。不仅如此，如果您按“星数”列出项目，您会看到大多数 Python 项目出现在顶部（您必须考虑到 Python 的存在时间更长）。对我来说，这为 Python 提供了一个强有力的案例，因为我考虑到了社区的采用和支持、文档以及开源项目的可用性。

【讨论】：

【解决方案10】：

这是一个很好的问题，我认为许多回答都给出了很好的观点，就围栏两边的利弊。我已经尝试过 Python 和基于 JVM 的 AppEngine（在我的例子中，我使用的是 Gaelyk，这是一个为 AppEngine 构建的 Groovy 应用程序框架）。当谈到平台上的性能时，我没有考虑过的一件事是在栅栏的 Java 端发生的“加载请求”的含义。使用 Groovy 时，这些加载请求是一个杀手。

我就该主题 (http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/) 发表了一篇文章，我希望找到解决问题的方法，但如果没有，我想我会回到 Python + Django 组合直到冷启动 java 请求的影响较小。

【讨论】：

【解决方案11】：

与 Python 用户相比，我听到 Java 用户抱怨 AppEngine 的次数较多，我会说 Python 的使用压力要小得多。

【讨论】：

我听说福特车主比科尼赛克车主抱怨他们的车要多得多。为什么会这样？

【解决方案12】：

还有一个项目Unladen Swallow，如果不是谷歌所有的话，它显然是谷歌资助的。他们正在尝试为 Python 2.6.1 字节码实现基于 LLVM 的后端，因此他们可以使用 JIT 和各种不错的本机代码/GC/多核优化。（好话：“我们不希望做原创工作，而是尽可能多地使用过去 30 年的研究成果。”）他们正在寻找 CPython 的 5 倍加速。

当然，这并不能回答您的直接问题，而是指向未来（希望如此）“缩小差距”（如果有的话）。

【讨论】：

Unladen Swallow 现在是一个死项目，最后一次提交是over a year old。

【解决方案13】：

如今，python 的美妙之处在于它与其他语言的交流能力如何。例如，您可以使用 Jython 在同一张表上同时使用 python 和 java。当然，即使 jython 完全支持 java 库，它也不完全支持 python 库。但如果您想弄乱 Java 库，它是一个理想的解决方案。它甚至允许您将其与 Java 代码混合，而无需额外编码。

但即使是python本身也做了一些步骤。例如，参见 ctypes，接近 C speed ，直接访问 C 库，所有这些都不会离开 python 编码的舒适。 Cython 更进一步，允许轻松地将 c 代码与 python 代码混合，或者即使您不想混淆 c 或 c++，您仍然可以在 python 中编码，但使用静态类型变量，使您的 python 程序与 C 应用程序一样快.顺便说一下，Cython 被 google 使用和支持。

昨天我什至发现了用于内联 C 甚至汇编的 Python 工具（参见 CorePy），没有比这更强大的了。

Python 无疑是一门非常成熟的语言，不仅自立，而且能够与任何其他语言轻松协作。我认为这就是使 python 成为理想解决方案的原因，即使在非常高级和苛刻的场景中也是如此。

使用 python，您可以访问 C/C++、Java、.NET 和许多其他库，几乎为零的额外编码为您提供了一种最小化、简化和美化编码的语言。它是一种非常诱人的语言。

【讨论】：

问题是关于GAE上的java vs python，有很多限制。因此，您的论点不适用。
我同意@Daniyar 的观点，这个答案有点（或可能完全）不合时宜，但我喜欢这个答案，这是我一直在寻找的。感谢 Kilon 分享这些知识。可能这是错误的地方，但你肯定做了一些知识分享。 +1 和荣誉。

【解决方案14】：

尽管 GWT 似乎与我正在开发的那种应用程序完美匹配，但 Python 已经消失了。 JPA 在 GAE 上相当混乱（例如，没有 @Embeddable 和其他模糊的未记录限制）。花了一周的时间，我可以说 Java 目前在 GAE 上感觉不太好。

【讨论】：

【解决方案15】：

需要考虑的是您打算使用的框架。并非所有 Java 端的框架都非常适合在 App Engine 上运行的应用程序，这与传统的 Java 应用服务器有些不同。

要考虑的一件事是应用程序启动时间。对于传统的 Java Web 应用程序，您实际上不需要考虑这一点。应用程序启动，然后运行。启动需要 5 秒还是几分钟并不重要。使用 App Engine，您最终可能会遇到应用程序仅在请求进入时才启动的情况。这意味着用户在您的应用程序启动时正在等待。保留实例等新的 GAE 功能在这里有所帮助，但请先检查。

另一件事是 GAE psoes 对 Java 的不同限制。并非所有框架都对可以使用的类的限制或不允许使用线程或无法访问本地文件系统的事实感到满意。这些问题可能很容易通过谷歌搜索 GAE 兼容性来发现。

我还看到一些人抱怨现代 UI 框架（即 Wicket）上的会话大小问题。通常，这些框架倾向于进行某些权衡，以使开发变得有趣、快速和简单。有时这可能会导致与 App Engine 限制的冲突。

我最初开始使用 Java 开发 GAE，但由于这些原因，我转而使用 Python。我的个人感觉是 Python 是 App Engine 开发的更好选择。我认为 Java 更“在家”，例如在 Amazon 的 Elastic Beanstalk 上。

但是 App Engine 的变化非常迅速。 GAE 正在改变自己，随着它变得越来越流行，框架也在改变以解决其局限性。

【讨论】：