2024年Clojure状态调查!中分享你的想法。

欢迎!请访问关于页面以了解更多关于如何使用本站的信息。

+2
Clojure

我是Clojure的粉丝,因为它简单、多线程模式、语言稳定性以及出色的Java互操作性。但我对静态类型更是情有独钟,这对多人项目来说非常有帮助。

Typescript为JS增加了一层高质量的类型检查,这可以在编译时消除许多编程错误。同时,它也开启了诸多编辑器/IDE工具的可能性。我认为,Typescript是JS历史上的最佳发明。

我不知道Clojure核心团队或者任何有能力并有资源支持的团队是否在考虑为Clojure开发类似TypeScript的工具?

如果不是,为什么呢?

谢谢

1 个答案

+5

Clojure核心团队没有计划为Clojure开发静态类型,因为我们认为这不是必要的。我们的努力集中在spec(《https://clojure.org/about/spec》),它提供了对描述Clojure数据和函数可选规范的支撑。

Typed Clojure项目(《https://typedclojure.org/》)是Ambrose Bonnaire-Sergeant在其攻读博士期间进行的一项大型工作。你可能还对Spectrum(《https://github.com/arohner/spectrum》),它基于spec的静态类型检查感兴趣。就我所知,这两个都不被广泛使用,且开发较为活跃。

发表评论
编辑了
感谢您的回答。

我们研究了规范并发现它主要是一个运行时的事情。对于文档和测试非常有帮助,但在我的看法中,它无法完成类型系统所能做的事情。

我们是一个小型的初创公司,有一些程序员。当我们开始时,我们认真考虑了Clojure,但最终我们决定使用Scala,因为它的强大类型系统。当我们需要JS时,我们也使用TypeScript。

我确信许多Clojure粉丝都和我处于同样的情况。他们喜欢它,并希望用它进行严肃的工作,但由于缺少类型检查,不得不选择其他语言。为了澄清,我的意思是Clojure不是一种不适合严肃工作的语言。我的意思是对于一些团队或公司来说,类型系统在选择语言或严重项目的技术堆栈时是一个重要的因素。

我了解无类型是Clojure的一个特性。但是TypeScript证明了良好的类型系统可以为灵活且有强大类型的语言生态系统增添巨大价值。

附言:前几天我在2017年的一次Clojure会议上听到了由Zach Tellman发表的关于抽象的技术演讲。我记得他分享了一个观点,在Lisp语言家族中,包括Clojure在内的Clojure过于灵活,这在某种程度上阻碍了它的成功。
发表评论
TypeScript不是一个“证明”类型系统“增添巨大价值”的语言,但我认为您评论中的重要观点是“对于某些团队……类型系统是一个重要因素”。而对于那些重视灵活性的团队来说,像Clojure这样的语言将远远优于Scala。

在我工作的地方,我们尝试引入Scala,但类型系统使每个人都感到沮丧,所以我们转向了Clojure。那是在将近九年前,现在我们运行了四十多个在线约会网站,拥有数百万客户,我们使用完全的Clojure后端。我们发现它提供的力量和灵活性使得我们可以非常快速地改变和完善系统。我们在生产中大量使用Spec进行输入验证,以及在测试中所需要的一切,因为它可以比类型系统更强大,因为它可以以类型系统无法描述的方式描述形状和行为。
by
感谢您分享您的见解。

我可以问问您正在使用哪个Clojure Web框架吗?

REST API服务是我们服务的关键部分。我们曾是Netty的忠实粉丝,在开始自己的商铺前,我们曾在一个基于Netty的定制REST API框架上运行。所以当我们开始时,我们想选择一个基于Netty的Web/REST框架。我们评估了Clojure的,发现大部分Clojure Web框架没有积极维护或者缺乏生产案例。我们最感兴趣的一个,aleph,似乎也被遗弃了。

这也是我们选择Scala(主要是因为Akka http)的原因之一。但我仍然热衷于将Clojure引入其他项目,正是因为你提到了的那些原因。

了解您的技术堆栈会非常有帮助。谢谢。
by
我想补充一点,clj-kondo最近增加了一种简单类型检查的功能,这也值得了解一下:[链接](https://github.com/borkdude/clj-kondo/blob/master/doc/types.md)
by
而且为了回答您的问题,很多人已经在生产环境中成功地使用了Aleph。所以我认为这是一个安全的选择。

话虽如此,我认为最具积极维护的、支持netty(和其他)的HTTP服务器可能是Pedestal:[链接](https://github.com/pedestal/pedestal)

否则,在Clojure中最受欢迎且积极维护的选择是ring,[链接](https://github.com/ring-clojure/ring),它可以与Jetty服务器捆绑的ring-jetty-adapter一起使用。

为了进一步学习,我建议您阅读这篇指南:[链接](https://purelyfunctional.tv/mini-guide/clojure-web-servers/)

还要记住,您可以直接使用Netty,Clojure的Java互操作性相当不错,远优于Scala的。因此直接使用Java服务器接口也是一个不错的选择。
谢谢。

正如您所说,如果我们决定从Clojure开始做一些事情,我们可能会直接使用Netty。我们对Netty之上的Java互操作性进行了一些实验,一切都很顺利。裸机的方法会给我们更多的灵活性。
我们不用Clojure的“框架”。我们使用一系列库。Ring是大多数应用的核心。我们使用Compojure在我们的几乎所有应用程序中进行路由(我们在一个中使用Bidi)。我们主要使用内嵌的Jetty Web服务器(通过“标准”Ring适配器),但所有我们的应用程序也可以根据命令行参数和/或环境变量启动http-kit。我们直接使用Netty,一个依赖于SocketIO的应用程序(通过Java互操作性)。

我们在约12个服务中使用了大量其他库的组合。其中一些是服务器端渲染的HTML - 我们几乎使用Selmer来进行所有的HTML渲染,Hiccup在一个地方用于从Clojure数据渲染HTML片段。

我们最初在2015年考虑将ClojureScript作为可能的前端,但当时的生态系统非常原始,工具似乎很脆弱(当时,Clojure和ClojureScript之间的差距比现在大得多)。因此,我们决定用JS和React.js / Redux / Immutable.js等构建面向客户的应用程序。我们有一个专注于JS的前端团队。

如果我们今天再次进行相同的项目,我认为我们会再次评估ClojureScript作为一项严肃的竞争者,因为生态系统在过去4-5年里发生了巨大的变化。我不知道那时我们会选择JS还是cljs。
谢谢。这非常有帮助。我们可能也会考虑Clojurescript。

顺便问一下,我可以建议这个论坛的版主将一个主题固定在顶部的帖子供 clojure 开发者分享其技术堆栈和见解吗?

我认为这对社区会有很大帮助。
非常有帮助。谢谢
我认为这里有误解
"静态类型,对于有多个开发者的项目来说非常有帮助"
"Clojure 核心团队没有计划为 Clojure 开发静态类型,因为我们认为它不必要。我们的努力集中在 spec (https://clojure.org/about/spec)) 上"

据我所知,如果我有误,请纠正我,发帖者请求的是“设计时类型”,而答案涉及的是Java理解的静态类型。

我所寻找的,以及可能的问题作者所寻找的,是编写
 
(defn describe-dog [^:happy-puppy-co.api/dog dog]


并且让智能感知提取  :happy-puppy-co.api/dog spec 并提供基于其键及其相应子spec的提示。即:帮助我按照作者意图使用 ::dog,而无需查看其文件。

TypeScript 编译后不存在,其输出是JavaScript。TS的最大好处是它可以帮助你更快地理解其他人代码(同时也提供一些避免误用的帮助,但这只是其次)。
我看不清楚你的评论与原始问题是否一致,但如果你在询问与函数定义集成的规范,那么这正是我们在规范2中考虑的事情。
by
by
那么,以下又是如何解释的?

“我是……静态类型的粉丝,这对于有多于几个开发者的项目非常有帮助。

TypeScript...也打开了大量编辑器/IDE工具的可能性。我认为TypeScript是发生在JS上的最好的事情。”

 据我所知,这意味着你必须不断与大量你、甚至你的团队之前都没有编写或审查过的代码工作。对于企业级应用,通常会有数十个具有30+键的dto,且命名非常不一致。典型的思维过程是这样的:“好吧,我们的函数将获得一个'sales-deal' dto,我需要将其转换为'financing-deal'并发送到分析,'sales-deal'上的利润率属性叫什么?是'margin'、'markup',还是仅仅是'rate'?而且它是十进制吗,还是sales-deals仍然具有作为详细的项目作为一个子-dto的率组成部分?”然后为'financing-deal'提出相同的问题...

我完全支持“发生在JS上的最好的事情”这一部分。遗憾的是,尝试ClojureScript感觉就像回到了JS——这不好。我赞赏spec的强大功能及其如何帮助我在运行时和测试中。现在我想要做的是将所有这些强大功能集成到我的IDE中,以帮助我编写代码。如果我还没有编写它,那么就没有什么可运行或测试的。
by
附言。为了更好说明我想要什么,请查看这个库:https://github.com/vriad/zod
它允许你在设计/编译时定义由TS编译器理解并使用的类似规范的schema。

//规范定义 - 在TS编译之后存在并可用于验证schema
const dogSchema = z.object({
  name: z.string(),
  绝育: z.boolean(),
});

// 验证运行时模式
const cujo = dogSchema.parse({
  name: 'Cujo',
  neutered: true,
}); // 通过,返回 Dog

// TypeScript 类型定义 - 在 TS 编译后不存在
type Dog = z.infer<typeof dogSchema>;
/*
等同于
type Dog = {
  name: string;
  neutered: boolean;
}
*/

// 使用推断类型进行编译时类型检查和设计时智能感知
const fido: Dog = {
  name: 'Fido',
}; // TypeError: 缺失必需属性 `neutered`
...