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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Clojure needs a Rails

252 点作者 janetacarr将近 3 年前

43 条评论

weavejester将近 3 年前
What would a &#x27;Clojure on Rails&#x27; framework look like? I think that&#x27;s the primary reason why such a framework has yet to find traction; there&#x27;s no single, obvious way to go about it.<p>The efforts made so far in this space have taken many different approaches, because they&#x27;re all experiments. Explorations of what an idiomatic Clojure web framework might potentially look like. Clojure has been around for over a decade now, and it&#x27;s fairly mature as a language; but it&#x27;s ideology is young in comparison to more established paradigms like OOP.<p>To make matters more complex, Rails came to prominence in an era where web applications were mostly of one type: server-side HTML with a sprinkling of JavaScript. Nowadays there tends to be more options, e.g. a web application may consist of a single HTML shim, with a thick React client that talks to a GraphQL back end.<p>So on the one hand we have a language that&#x27;s still exploring its identity; on the other we have a rapidly changing idea of what a web application should be.<p>My <i>guess</i> is that an idiomatic Clojure web service would look like a client-accessible relational database with a strong security model and datalog queries, along with some system for adding in side-effectful hooks to respond to data change. In other words, something rather different in design to Rails.
评论 #32289849 未加载
评论 #32289222 未加载
评论 #32293412 未加载
评论 #32291137 未加载
vemv将近 3 年前
I also thought &quot;Clojure needs a Rails&quot; some 5 years ago. Nowadays (multiple, real-world Clojure jobs later) I don&#x27;t.<p>I also learned that trying to second-guess why developers spend their time in certain libraries and not in other endeavors (like frameworks) comes across as pretty disrespectful and actually ignorant (considering that those people are very often more skilled&#x2F;experienced than most of us).<p>(Good related read: Open Source Is Not About You)<p>So I&#x27;d recommend to anyone, open your mind, be ready to have some preconceptions changed, and contribute a significant deal to (Clojure) OSS to truly appreciate what we have. And write more interop ;)
thom将近 3 年前
I think the thing people most struggle with in Clojure is that it looks like it should be an incredibly pure, deeply opinionated language but it’s actually extremely pragmatic. There is never going to be a long lived, vertically integrated, do everything framework for Clojure. If it was going to happen it would have already. Rails took off because burnt out enterprise Java developers wanted to quit and have fun again. Clojure happened because enterprise Java developers wanted to do enterprise Java better.
评论 #32290050 未加载
评论 #32316863 未加载
lolinder将近 3 年前
&gt; If we used interop for everything mundane, Clojure would really just be an S-expression shaped husk over Java code. Not a very good solution.<p>I don&#x27;t have a lot of experience with Clojure, but speaking as someone who uses Kotlin on the server side, this attitude strikes me as odd. <i>Most</i> of the reason to use a JVM language is to take advantage of the mature and well-maintained Java libraries for basically everything.<p>If interop is considered a last resort (to the point where you reach for a 3-year-old unofficial Stripe library over the officially maintained Java one), what&#x27;s the point of running on the JVM at all?
评论 #32292691 未加载
评论 #32289269 未加载
评论 #32288782 未加载
评论 #32294518 未加载
评论 #32289450 未加载
评论 #32288761 未加载
avanai将近 3 年前
I think this article vastly undersells the value of Java(script) interop. The ability to call out to a well-maintained library in two of the most widely-used languages in the industry is one of the major selling points of Clojure as a pragmatic LISP, versus e.g. Racket or CL. The reason why there are so many half-baked wrappers around popular Java libraries is that it’s reasonably trivial to write one yourself on demand, so that’s what people do.
ttymck将近 3 年前
At some point, do we have to consider that the problem might be Clojure itself? Does LISP lend itself to &quot;Rails&quot; -- a Rails that people want to work with? I ask, genuinely, as a near-total outsider.<p>The comparison to Elixir got me really thinking. I appreciate your &quot;call to action&quot;, but community consensus gathering wasn&#x27;t necessary for Phoenix to emerge as an option-of-choice, it gained traction because it is _good_.<p>Surely there are large organizations using full stack Clojure, similar to the Lawrence World-Journal. Is there something about LISP that makes it hard for them to abstract their &quot;framework&quot; bits into an open source package?
评论 #32288854 未加载
评论 #32288724 未加载
评论 #32289988 未加载
评论 #32291544 未加载
评论 #32292339 未加载
评论 #32289578 未加载
hombre_fatal将近 3 年前
I think this is just a cultural thing where the ecosystem prefers to compose things together. The Node ecosystem also hasn&#x27;t centralized around a Rails. People tend to just use Express.<p>Also, the syslog server example doesn&#x27;t seem like something a Rails would solve.<p>&gt; can we please just get together at the next Conj conference decide what our &quot;Rails&quot; is going to be?<p>I think these days we, OP included, tend to use &quot;Rails&quot; to not just mean a monolithic framework, but also one that monopolizes the ecosystem which is one thing that made Rails good.<p>But since it&#x27;s been tried before in the Clojure and Node ecosystems, maybe people just don&#x27;t care for it.
Jeaye将近 3 年前
I disagree that Clojure needs a Rails, in the sense that there&#x27;s a single framework to use for all web server needs. However, I do really think Clojure needs a better documentation story for web development across the board.<p>Getting a ring + reitit + malli + integrant + core.async + vertx-mongo server running requires putting together a _lot_ of different pieces. A framework is one way to solve this, but so too is documentation. Perhaps it&#x27;s just my Clojure mindset, but I&#x27;d be hesitant to reach for a one-stop-shop framework for all of the above, but I would definitely be interested in some docs which helped guide me hook all of them together. Is there such a thing as a documentation framework? :)<p>-- Thinking about how Clojure devs feel about libraries makes me realize how ironic it is that so many of them use Emacs.
评论 #32294000 未加载
评论 #32293820 未加载
评论 #32296972 未加载
phtrivier将近 3 年前
And clojure is actually in a better position than other niche languages because _at least_ you have the option of calling the boring and maintained java library to ship _something_ (it might be something non lispy, maybe a bit less efficient and maintainable but at least you solved the business issue.)<p>Try doing that in some other languages were your underlying platform has even less libraries than a JVM...
评论 #32290009 未加载
评论 #32288524 未加载
评论 #32288646 未加载
egypturnash将近 3 年前
Suzi just needs to find an excuse to spend a couple years building a serious thing <i>entirely in Clojure</i>, no matter what. And then to disentangle all of the logic particular to her thing from the application framework she&#x27;s built for this (or the existing one she used as a starting point), as well as disentangle anything that she thinks should be an external library, and release it all for free.<p>Suzi may need to wait to do this until after her current gig has won the Startup Lottery. Or perhaps she may need to quit her current gig and figure out how to get a bunch of other Clojure-lovers to pay her rent while she does this. Good luck.
评论 #32289035 未加载
wirrbel将近 3 年前
I developed for fun in Clojure and ClojureScript probably for 3 years, it was tremendous fun and got me into Lisps. In many ways Clojure does still hit the sweet spots from a language design perspective for me.<p>I have revisited Clojure every now and then after and IMHO its in a weird state, too popular and successful to completely die, but also limited to reach wider adoption.<p>When revisiting old projects I have seen countless of Clojure dependencies having died in the meantime. I have replaced utility libraries with more recent utility libraries sometimes several times. Very annoying. Paradoxically the core API is really stable to a degree that bugs aren&#x27;t fixed that are a behaviour userland code might rely on.<p>But its overall I think more of a symptom than a cause for frictions when developing Clojure. Community management is bad, even worse that RH nourishes this elitist aura around himself. Then the JVM integration is of course the blessing that led to Clojure&#x27;s initial success but is at the same time limiting. The Java community by majority seems to gravitate towards Scala (weird scala version incompatibilities incoming, Scala DLL Hell) and Kotlin.<p>So overall Clojure is in a strange situation. For picking it up on-the-job its not the responsible choice probably for most situations I work in. For my private tinkering the JVM dependency feels just a little too heavyweight. I don&#x27;t see that Clojure will hit an inflection point of adoption in any way in the future that would make it a viable candidate for me to use at work.<p>I really would hope that a Clojure-on-guile or Clojure-on-racket implementation becomes ready at some point that would make me want to switch from Scheme to Clojure for the toy projects at least.
评论 #32289779 未加载
评论 #32289871 未加载
评论 #32290273 未加载
评论 #32290692 未加载
评论 #32293168 未加载
评论 #32289715 未加载
slifin将近 3 年前
Clojure typically doesn&#x27;t attract the kind of developers who want to work on &quot;boring&quot; things<p>So there is an imbalance there<p>On one hand I&#x27;m kind of happy there&#x27;s no one true way in Clojure to do web dev, because as I think Rich said, it&#x27;s not a solved problem<p>So if we couple too heavily to one opinion on web dev then it&#x27;s going to fail us as a community on a big scale and be hard to move away from<p>Sets of libraries are typically easier to swap out<p>In reality I think most Clojure businesses end up on reagent or and reframe and they are the defacto ways of doing web dev<p>For &quot;solved&quot; problems like stripe calls it would be nice if we had more people working on maintaining libraries but as a Clojurian myself I know I wouldn&#x27;t do that myself so I only have me and people like me to blame
评论 #32288872 未加载
评论 #32289653 未加载
评论 #32289053 未加载
评论 #32288907 未加载
jwr将近 3 年前
From a point of view of someone who wrote and maintains a big SaaS written in Clojure and ClojureScript:<p>* The libraries could definitely be improved and we <i>do</i> need better approaches to web apps.<p>* But we do not necessarily need all-revolutionary-totally-different-reinvent-everything approaches that require you to throw away everything you have ever seen.<p>* &quot;Last commit 3 years ago&quot; is not necessarily a problem.<p>* I&#x27;ve spent an incredible amount of time on things which I expected would have been solved a million times. Stuff like session management, authentication, webhook handling, all of which become way more complicated if you use things like websockets.<p>* While there, I learned that it&#x27;s very difficult to come up with abstractions that handle all the edge cases. Sooner or later you need that webhook that is authenticated differently, some API calls do not need authentication, and some of your upper layer code needs that request source IP address, because the EU said so in the laws for handling VAT.<p>Also, even with all the reservations, I still can&#x27;t imagine writing and maintaining my app in anything other than Clojure and ClojureScript. It would no longer be a one-person project.<p>So, while I would like to see more stuff being developed, I am not sure if a &quot;Rails for Clojure&quot; makes sense, and I have no idea how to write one. I have a suspicion I am not the only one thinking along these lines, and it could be one of the reasons why we don&#x27;t have anything of the kind.<p>Instead, what I do is contribute a little bit to various Clojure funding projects, either directly to developers or to organizations like Clojurists Together.
nickjj将近 3 年前
The blog post mentions Elixir and while Elixir has its own mini-Rails with a lot less opinions, you&#x27;ll still run into the same problems as Clojure around things like wanting a Stripe supported library, or PayPal, or Braintree, or Paddle or a ton of other popular 3rd party SAAS SDKs that exist in Ruby, Python, Node, PHP, Go, etc..<p>It&#x27;s one of the reasons I stopped using Elixir. When I reached out to Stripe (and other 3rd party tools) they said the demand wasn&#x27;t there to justify the dev time to maintain an official library internally. I think this is the reality to expect when using a more niche language. That may be ok if you&#x27;re ok with that but it&#x27;s important to know that&#x27;s what you&#x27;re getting into when you choose languages like this. It&#x27;s a personal preference.
评论 #32289530 未加载
评论 #32289482 未加载
georgeoliver将近 3 年前
&gt;If we used interop for everything mundane, Clojure would really just be an S-expression shaped husk over Java code. Not a very good solution.<p>IMO some programmers pursue purity (no pun intended) over pragmatism, at their own expense. I understand the appeal, it&#x27;s like hand planing a board with your vintage No. 8 instead of sending it through the Powermatic.
评论 #32288730 未加载
评论 #32288518 未加载
troutwine将近 3 年前
It’s an interesting argument. However, I’m not sure about it. Consider Rust doesn’t have a Rails per se but the ecosystem it is thriving. It seems more like an indication that the Clojure community of developers is either focused on things other than the article is concerned with, or its period of popularity has waned and the libraries that do exist from that time are slowly rotting. I think about Erlang before Elixir. In its niche Erlang had a very good set of libraries, primarily centered around lower level network communication type things. But for integration with popular APIs etc. not so much. After Elixir and an influx of new people the off-the-shelf library situation got significantly better. I don’t think that’s because they were doing Rails type things necessarily but more because there was a more diverse pool of developer community, whereas the Erlang community was slowly shrinking through attrition.<p>If you want Clojure to thrive again you’ll have to stop the attrition of its developer community. Maybe that’s by building a Rails but even your example in-article where Go is more suitable isn’t really a web type problem. What problems can Clojure solve that other languages can’t, in a way that is worth the effort for someone new to the ecosystem?
评论 #32289084 未加载
评论 #32290513 未加载
b123400将近 3 年前
Not exactly Clojure-related, but I wonder how acceptable is it for a programmer to suggest a technical decision by one’s own passion over company’s interest.<p>&gt; The business case for Go is very strong now. Sh*t.<p>It sounded like a negative news for Suzi as she wanted to promote Clojure, but it’s positive for the company, as Go is a more suitable choice in this case. If a programmer is asked to make a technical decision, comes up if a solution based mostly on passion, isn’t it misleading? I’ve seen a Haskeller claiming “this thing can be better expressed in a custom DSL” and started to write a parser, which in retrospect absolutely unnecessary, the passion was so strong that decisions got irrational. Shouldn’t a programmer be honest and say “this is not the best tool, but it’s my favorite, using it makes me happy”?
评论 #32292820 未加载
评论 #32292882 未加载
janetacarr将近 3 年前
Since it keeps coming up, I&#x27;d like to clarify that I&#x27;m not advocating for a port of Rails or some kind of analog. I should have chosen a better post title.<p>I have never used Rails.<p>I&#x27;m arguing Clojure has missing or rotting libraries, requiring us to re-implement logic we&#x27;ve all done at least once because people are fixated building web frameworks, and I think it&#x27;s motivated by people trying to build the Rails for Clojure. I really can&#x27;t think of any other reason for people to build so many web frameworks at this point.<p>The Rails for Clojure is an idea, one the community rallies around, one where people won&#x27;t reinvent the wheel over and over again, so that we can have a lot more non-web packages for Clojure.<p>I&#x27;m quite literally saying, the effort could be better spent elsewhere.
评论 #32291516 未加载
z9znz将近 3 年前
There is the Kit framework <a href="https:&#x2F;&#x2F;kit-clj.github.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kit-clj.github.io&#x2F;</a> which looks promising. It is rather new, and the documentation is quite limited, but I think it has a good chance at growing into something new people would find an accessible starting point for Clojure web development.<p>There is also a project called Coast which appears to be a direct attempt to make a Rails-like framework. However, the repo activity seems ... quiet. Granted, Clojure is special for having a lot of libraries which are quite old and appear dead but are instead apparently complete or satisfactory, and as such they don&#x27;t get new commits.<p>I&#x27;m still waiting for a configurable platform (in any language) which allows you to specify the things you need, and it provides the working foundation. It then has a plugin structure so you can build your business logic in any of several languages, and importantly it doesn&#x27;t suffer from the usual code generation problem where it only works one time (the first time). Wordpress is sort of this, but it&#x27;s slow and architecturally awful.
ben_jones将近 3 年前
Im sorry I couldn&#x27;t get past a hypothetical Org allowing a single developer to yolo-yeet bespoke languages, frameworks, tooling, into internal-critical-business-project after internal-critical-business-project.<p>If your Org behaves like the above you could have the best Rails-Closure framework in the world but you&#x27;re still destined for implosion.
waffletower将近 3 年前
Clojure libraries target microservices with a precision that no other language ecosystem has. In essence, Clojure web services developers rail against Rails and other bloated, unnecessarily complected (<a href="https:&#x2F;&#x2F;www.infoq.com&#x2F;presentations&#x2F;Simple-Made-Easy&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.infoq.com&#x2F;presentations&#x2F;Simple-Made-Easy&#x2F;</a>) frameworks of the 90s. As a Clojurist I too rail against Rails. I don&#x27;t think that expansive model fits the problem space. I have had painful experiences in the past maintaining Rails projects wondering why they didn&#x27;t know of DRY. If there is a essence within Rails that you feel could be distilled into a lean Clojure model, build it out in a library and share it.
评论 #32293102 未加载
评论 #32289927 未加载
评论 #32289236 未加载
jayceedenton将近 3 年前
In my experience Clojure teams use high quality Java and JavaScript libraries all the time. It&#x27;s more often than not a piece of cake.<p>&#x27;Clojure needs a rails&#x27; has come up perennially for that last 10 years. I don&#x27;t disagree, as I think convergence on one web solution rather than a constant churn would have great benefits. The idea that you can&#x27;t use sysdig, or whatever, because there is no Clojure library, is nonsense. Interop is good and Clojure is nicer than Java for writing Java :)<p>Also, you can overload functions with further aritiss in protocols just fine. Nothing to do with variadics.
评论 #32289755 未加载
fmakunbound将近 3 年前
This might be what happens when the community seems to follow “composable libraries over frameworks”. You still have to do the composing, and it’s not obvious how to do that.
评论 #32293897 未加载
polote将近 3 年前
If you need a Rails, why not directly use Rails? For what kind of web application Clojure is better than python or Ruby or nodejs?
评论 #32290896 未加载
justinhj将近 3 年前
I see exactly the same thing in the Scala community. Your first instinct when you need a library is to find a pure Scala one, when many times there are far superior (in terms of maturity, stability and documentation) in the Java word. Sometimes it makes sense to write an intermediate wrapper but not always.
otikik将近 3 年前
Lua never got a Rails, but it got a Grim Fandango (the best &quot;mainstream&quot; video game that shipped it [1]). That game marked an inflection point in adoption of Lua as a scripting language for video games, and that expanded to other areas afterwards.<p>Perhaps it worth exploring what other niches like that would make sense for Clojure. For example: It seems to me that its lipsy nature would meld well with artificial reasoning and perhaps AI. Some sort of PyTorch competitor, perhaps? How is the Java ecosystem with regards to AI libraries?<p>[1] <a href="https:&#x2F;&#x2F;es.wikipedia.org&#x2F;wiki&#x2F;Grim_Fandango" rel="nofollow">https:&#x2F;&#x2F;es.wikipedia.org&#x2F;wiki&#x2F;Grim_Fandango</a>
carl_sandland将近 3 年前
Apologies if this is a bit daft, I just experimented with Java&#x2F;Clojure interop and I think most people here are talking about Clojure&#x2F;Java interop: note the different order. I built a Java &#x27;application&#x27; that uses Java&#x27;s rich libraries to handle all the &quot;I&#x2F;O stuff and interactions&quot;, and called out via clojure.api to a clojure functional core. This seemed to work very well.. But I can see this means learning two languages (not 1.5). Just wondering if many people do this?<p>Get the Java code to collect a bunch of abstract data values and feed it into the functional core, which is pure clojure with very few libraries at all.
评论 #32295255 未加载
danjac将近 3 年前
There&#x27;s no &quot;Rails for Go&quot; either, so not sure why that is brought up as a comparison.<p>I suspect (from dabbling in Clojure some years ago) that the Clojure community has more enthusiasts than practical users, who enjoy building stuff that meets a Platonic ideal of language purity instead of the messy work of supporting long-term libraries that are far from Lispy perfection but meet the needs of real world projects.
davedx将近 3 年前
I don’t think API wrapper libraries add that much value and I usually only use them if it’s absolutely necessary. Most APIs are just REST calls…
评论 #32290814 未加载
评论 #32288995 未加载
dustingetz将近 3 年前
clojure is about simple composition not magic, so any solution starts by solving frontend&#x2F;backend data sync in a composable way. Absent that you are just in the tarpit so most commercial shops might as well be in the typescript tarpit with everyone else and benefit from the larger ecosystem.
tus666将近 3 年前
&gt; &quot;It&#x27;ll probably take two months to build this relay because there&#x27;s no syslog server library for Clojure.&quot; she says.<p>&gt; &quot;Oh wow, I didn&#x27;t think it would take that long.&quot; Sam says.<p>The correct answer should have been:<p>&gt; &quot;Who asked you to write it in Clojure?&quot;
评论 #32295759 未加载
liveoneggs将近 3 年前
This comes up a lot and, I think, Laravel provides a great model for competing with rails. Stripe integration - <a href="https:&#x2F;&#x2F;laravel.com&#x2F;docs&#x2F;9.x&#x2F;billing" rel="nofollow">https:&#x2F;&#x2F;laravel.com&#x2F;docs&#x2F;9.x&#x2F;billing</a>
justnotworthit将近 3 年前
I&#x27;ve used lots of little utilities and scripts in many languages, but I can&#x27;t recall running across a clojure project. Occassionally java of course, but nothing with source code in clojure. Is clojure more serverside&#x2F;business?
xwdv将近 3 年前
One of the hurdles to having a true Clojure on Rails is finding a suitably synonym for “Rails” except starting with a C.<p>Perhaps Clojure on Causeways or something?
blain_the_train将近 3 年前
MVC don&#x27;t help with strip payment integrations.
fny将近 3 年前
I often wonder whether we&#x27;re about to move from the golden age of software into the golden age of bitrot. Software ate the world. There&#x27;s been enough money sloshing around that programmers have had the luxury to develop umpteen tools in umpteen languages that solve the EXACT SAME PROBLEM. At some point the party will stop and we&#x27;re bound to run out of people willing to prep for FizzBuzz interviews just so they can support a ball of Clojure&#x2F;JavaScript&#x2F;PHP&#x2F;Python&#x2F;Ruby.
d_t_w将近 3 年前
&gt; If we used interop for everything mundane, Clojure would really just be an S-expression shaped husk over Java code. Not a very good solution.<p>Interop into the host system in Clojure is idiomatic. I think often there is a misunderstanding of the difference between information systems and artificial ones. Rich Hickey gives a plain english explanation in section 2.1 of his fantastic talk &quot;A History of Clojure&quot;. [1]<p>I have been using interop into Java for the mundane for ten years. Our general approach is to simply use p&#x2F;datafy to convert the result of interop calls immediately back into Clojure datastructures.<p>I don&#x27;t find that approach onerous and it doesn&#x27;t impact our overall system design any more than using a third party DSL. The interop ensures we take ownership of our Java dependencies rather than using an outdated thin DSL wrapper which provides no real value anyway (as I assume the Stripe example would be). In the past where I&#x27;ve worked on projects with those wrapper DSL I tend to throw them out, they&#x27;re the wrong idea.<p>In my case I use stable, mature, artificial systems provided by Java to underpin my application. My application is an information system, where I use the lean power of Clojure to implement complex functionality without the drag of Java.<p>The result is an echo of the Destroy All Software talk &quot;Funcational Core, Imperative Shell&quot; [2], but rather more a &quot;Data-Oriented Core, Type Oriented Shell&quot;. The end goal being to enable my small team to ship better and faster than our competitors<p>The most important artificial system in our application is Jetty, the networking framework. The next is the Kafka Client &#x2F; Streams API. That&#x27;s our Type Oriented Shell. The magic of the application is Clojure, everything in between. The glue is interop, p&#x2F;datafy, and transit.<p>In some cases the magic, value-adding, bespoke software part a developer is attempting to add between the Type Oriented Shell parts is tiny, and the result feels like an S-Expression shaped husk. In my case that magic part is enormous, and the benefit of using Clojure obvious.<p>If you are shipping an information system, the problem domain is non-trivial, and you are delivering on the JVM, I believe you should use Clojure to attack that problem. For me it has been game-changing in terms of pace and quality of delivery. Right tool for the right task.<p>Clojure is also enormously more fun and liberating to work in than Java, and you shouldn&#x27;t underestimate the power of joy as a morale maintainer when working on one problem for a long time. I first started working on our product in May, 2018 and I enjoy working on it today.<p>For context, I worked in Java for 15 years before adopting Clojure a decade ago so I understand the relative benefits of shipping production information systems in both languages. I&#x27;m also probably more comfortable just using Java interop than some Clojure developers.<p>We have plans to open-source the useful parts of our type-oriented shell and the glue that binds them in the next few months, along with our solution for managing dynamic system state, but then again I&#x27;ve been faintly promising that for three years so take it with a grain of salt.<p>The application I work on is enterprise-grade tooling for Apache Kafka: <a href="https:&#x2F;&#x2F;kpow.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kpow.io&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;download.clojure.org&#x2F;papers&#x2F;clojure-hopl-iv-final.pdf" rel="nofollow">https:&#x2F;&#x2F;download.clojure.org&#x2F;papers&#x2F;clojure-hopl-iv-final.pd...</a><p>[2] <a href="https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;screencasts&#x2F;catalog&#x2F;functional-core-imperative-shell" rel="nofollow">https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;screencasts&#x2F;catalog&#x2F;funct...</a>
didibus将近 3 年前
&gt; Next on her docket was the Stripe payment integration. Should be the same thing as the website. Suzi sees there are a number of Stripe Clojure libraries to choose from<p>Stripe is just a bunch of rest calls, why are you looking for a useless wrapper that only builds up HTTP requests?<p>I&#x27;ll sound like a true Clojurian, but this is just the kind of complexity Clojure eskews. You don&#x27;t need an SDK for Stripe.<p>And if you want one, just use the Java SDK directly that&#x27;s well maintained probably by Stripe itself.<p>That&#x27;s why each time you looked at the libraries they barely did anything, because there&#x27;s barely anything needed to do.<p>That&#x27;s also why if you look at the cognitect aws-api you&#x27;ll see they&#x27;ve basically un-frameworked all the complexity from the official Java SDK, they&#x27;ve turned it back into plain http requests where all you have to do is put the JSON payload together and send it.<p>&gt; only to find there is no syslog server library for Clojure that she can find<p>To be honest, seems weird to not just use a off the shelf syslog server, but still this seems a kind of niche use case, if you look, most languages don&#x27;t seem to have great existing syslog server libs. It&#x27;s kind of surprising that Go does to be honest, this might be one of those where you bite the bullet.<p>Now, it does look like you can use Spring, and I don&#x27;t think spring is very hard to use with Clojure, but I recognize there&#x27;s no guides or tutorials to go by.<p>If you look at Java, Syslog4j is 10 years old without commits, so I mean, if Java even doesn&#x27;t have an actively maintained syslog server, I&#x27;d say this really isn&#x27;t a good example, why Go has an active one I have no clue haha, that&#x27;s the more curious part.<p>Now, it also does seem like it&#x27;s just some UDP protocol, and while that&#x27;s more complicated then an http call, I still think there&#x27;s a lot of these where if people learned how to just do them, again you wouldn&#x27;t need a library, the idea behind syslog is how simple the protocol is to implement.<p>&gt; Suzi estimates the project with Go instead. The business case for Go is very strong now. Sh*t.<p>What was the estimate with Go as compared?<p>&gt; but it&#x27;s really hard to sell management on building an entire library when another language has so many batteries built in<p>I didn&#x27;t resonate unfortunately, I have the opposite feeling, I always find a Java or JavaScript lib for anything they want (well syslog maybe not haha), if there isn&#x27;t a Clojure one. And that&#x27;s the only reason why I can get away using Clojure, where I could never use Elixir, Haskell, CommonLisp, or any other language that haven&#x27;t blown up yet.<p>When it comes to management, I don&#x27;t say I&#x27;m building a library, I just do the work. Implement the behavior or feature and if I made it into a reusable library then that&#x27;s just benefit on the next project where I might reuse it.<p>In the end, I&#x27;m always faster with Clojure, because it just tends to require so much less code, ceremony and the REPL is a super power for quickly exploring and iterating, at least for me.<p>&gt; If we used interop for everything mundane, Clojure would really just be an S-expression shaped husk over Java code. Not a very good solution.<p>It&#x27;s an amazing solution. That&#x27;s exactly why Clojure is so awesome. Doing it all in Java or Go or JavaScript would be 10 times worse. Use Clojure for your business logic, the core of your app, what gives your business true value, and delegate the mundane to old boring and chunky like Java and JavaScript, but now you have a much nicer language, syntax and a REPL on top. What&#x27;s not nice about this?<p>A Clojure API might be slightly nicer, but often wouldn&#x27;t, because the mundane generally is intrinsically messy, it&#x27;s often IO and is all about side-effects. It&#x27;s also so easy to make your own Clojure API, like just wrap things in a function done. Now you use that function instead everywhere.<p>People act like interop is this complicated, difficult, and effortful thing, that&#x27;s going to drastically slow you down and render you code unreadable and unextandable. That&#x27;s not true one bit. The interop is pretty damn good, and at least for me, in terms of the time to delivery, it takes me no longer to use a Clojure API that the interop directly with the Java API. But just like everything else, you have to learn how it works and then you&#x27;re good.
piggybox将近 3 年前
&gt; Java has Play<p>Is Play still (or ever was?) the go-to web framework for Java?
rubyist5eva将近 3 年前
Stop trying to make Rails in things that can’t be rails. Rails is Rails uniquely because it is RUBY on Rails. It plays uniquely into Rubys strengths, that’s what makes it what it is.
didibus将近 3 年前
&gt; It&#x27;s awesome, but can we please just get together at the next Conj conference decide what our &quot;Rails&quot; is going to be? That way we can get down to business<p>I like the rallying call here. I do think it be nice for the community to do whatever to help Clojure&#x27;s viability and popularity.<p>That said, my issue is that I disagree with the approach. I&#x27;ve already moved on to business and I use Clojure.<p>I think this is the clash the community faces. On one side you&#x27;ve got the people who seem discontent with the libraries approach, and refuse to embrace the hosted nature, they want a native Clojure, no reliance on interop. They might not know Java or JavaScript and might be unfamiliar with their runtimes, or simply discontent with them and don&#x27;t want to touch them ever.<p>Then you&#x27;ve got the other side of the community, I think where I fall in, I want to do things my way, don&#x27;t want to learn any framework, instead I&#x27;ll just do it like I feel and it&#x27;ll work better for me, as I&#x27;ll know it ins&#x2F;out. I dislike framework, I&#x27;d rather just straight up use things directly, I want as little indirection, and I have no issue using interop and having a few wrapper shims when needed.<p>That side of the community is just delivering business as usual with what&#x27;s already there, and it doesn&#x27;t seem much more is needed.<p>Unfortunately, I also think there&#x27;s another dimension between this dichotomy, the latter group, where I fall for example, I think is leaning more experienced, senior, team lead, Clojure is their third to fourth professional language, they&#x27;ve settled in it. The Stackoverflow survey did show Clojure had the most senior leaning user base, and probably because of that is also highest paid.<p>I think this is an issue, because take me, in Java, C# or some other language I&#x27;ve worked in professionally, I&#x27;m all up on advocating for use of the frameworks, the DI, the design patterns, and I&#x27;ll contribute. These languages are too heavy, you can never get anything done quickly or without the man-power, and you don&#x27;t want too, it&#x27;s not fun. So you need to rally yourself behind one thing, even if it&#x27;s not perfect, there&#x27;s no room for experiments.<p>The reason I&#x27;m using Clojure is to get away from that though, it&#x27;s for the freedom to experiment, the ability to within the business budget, be able to deliver the same amount yet custom built half of it exactly as I want.<p>I couldn&#x27;t get away with that in Java, I&#x27;d miss deadlines.<p>So if I assume half the community is like me, I think that&#x27;s a lot of people who don&#x27;t want to focus on one framework, or one way to do things.
antupis将近 3 年前
I think what Clojure needs is to be best at some very practical real world usecase so kinda what Rails was 2007 or Python and ML were 2013.
quickthrower2将近 3 年前
What, JVM language with no ffi?