Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tour of our 250k line Clojure codebase

tech.redplanetlabs.com

Post reply on HN
Print view View original

221–230 of 237 posts

Re: Tour of our 250k line Clojure codebase

#221

Post by xpe »

chromanoid wrote: post #191
xpe wrote: post #134

Earlier quoted context omitted.

> Actually this sounds quite horrible. You understand the use case well enough to criticize it?

I can only guess regarding the use case. I still can make a statement that I personally do not think that the coolest part of a codebase should be a new general purpose language at its foundation. To me this reeks of not invented here syndrome, inner-platform effect and KISS "violations". IMO when you provide new tooling you want your developers be able to stand on the shoulders of giants and let them choose the figh…

None of the smells you mentioned are anywhere close to absolutes.

Re: Tour of our 250k line Clojure codebase

#222

Post by coneill »

bgorman wrote: post #149
coneill wrote: post #95

Earlier quoted context omitted.

Seconded. I work in a clojure codebase that were trying to get out of. There's just dead libraries everywhere and stuff that maintained by one person that gets no updates at all. That or we just end up making functional "wrappers" around Java libraries and at that point we might as well just write straight Java. Also yea everyone wants to be so damn smart having macros within macros within macros that no one knows wh…

I’m sorry you are having trouble with Clojure. One thing to keep in mind is that Clojure has excellent interop with Java, and it is trivial to write a small Clojure wrapper that just does critical thing for your dependency injection system e.g. startup and shutdown, and just pass through a reference to the Java object when you need to make function calls. Another thing to keep in mind is that Clojure code is extremel…

I can see where some of that is valuable and the whole pull of the JVM ecosystem and stuff that you get to pull on a lot of other packages and libraries but the majority of what I've seen is a lot of packages we use are just thin wrappers around existing Java and most of the time they have functional paradigms anyway. something like resilience4j for example.

The other large issue in packages ive found is using some performance and monitoring tools to our clojure apps such as DataDog. The java tracing brings the app to a crawl based on how it instruments the compiled clojure code. Since clojure is a dependency itself the core language ends up having instrumentation code injected and the app grinds to a half. Something the Datadog team has not been able to solve.

Overall unfortunately I've just found Clojure isn't really particularly good at anything. It can hog memory, lib support seems iffy, Codebases never seem to have this "wow" factor that lots of people mention about clojure's elegance. I just don't see the promised land.

Re: Tour of our 250k line Clojure codebase

#223

Post by chromanoid »

xpe wrote: post #221
chromanoid wrote: post #191

Earlier quoted context omitted.

I can only guess regarding the use case. I still can make a statement that I personally do not think that the coolest part of a codebase should be a new general purpose language at its foundation. To me this reeks of not invented here syndrome, inner-platform effect and KISS "violations". IMO when you provide new tooling you want your developers be able to stand on the shoulders of giants and let them choose the figh…

None of the smells you mentioned are anywhere close to absolutes.

Of course, that is the nature of the concept.

Re: Tour of our 250k line Clojure codebase

#224

Post by forgetfulness »

cutler wrote: post #193
forgetfulness wrote: post #7

Earlier quoted context omitted.

I think that's also why Clojure use peaked right before Java 8 was released; once Java became a better Java, and libraries started to be designed around more ergonomic APIs than wiring up objects that needed miles of stateful configuration code, the pressure that drove you out of Java and into Clojure began to diminish.

Hardly. Despite being Java-compatible Clojure's philosophy is diametrically opposed to that of Java/OOP so anyone who has experienced the benefits of Clojure would hardly return to Java simply because it managed to fake FP with Single Abstract Methods.

Well, maybe there were not as many die-hard lispers within the Clojure community and many were looking for something that handled better than Java 7. I know two other former Clojure programmers that went to Scala, but also find Java passable enough to just use it rather than Clojure.

Re: Tour of our 250k line Clojure codebase

#225

Post by feoren »

dustingetz wrote: post #98
chromanoid wrote: post #77

> One of the coolest parts of our codebase is the new general purpose language at its foundation. Though the semantics of the language are substantially different than Clojure, it’s defined entirely within Clojure using macros to express the differing behavior. It compiles directly to bytecode using the ASM library. The rest of our system is built using both this language and vanilla Clojure, interoperating seamlessl…

JSX would be an (early) example of this class of language. XML is equivalent to s-expressions. So React.js (drunkly) is just a reactive language embedded in a normal language with seamless ability to hop between them. I elaborate about this equivalence here https://www.reddit.com/r/Clojure/comments/mavg81/the_distinc... . The brilliance is they did this so smoothly that nobody noticed, and with dynamic types, and wit…

React is not a "reactive language", and JSX is an abomination, so I'm not sure this is a rebuttal to the GP's "this sounds horrible" point.

Re: Tour of our 250k line Clojure codebase

#226

Post by mbrodersen »

chairhairair wrote: post #8

Is there more info about the tool itself that claims 100X decrease in application development cost? Quite the claim.

I know Clojure well enough to call BS on that claim. Unless you compare what they do with the worst possible incompetent alternative.

Re: Tour of our 250k line Clojure codebase

#227

Post by mbrodersen »

jahewson wrote: post #36
geospeck wrote: post #22

> And doing things dynamically means we can enforce stronger constraints than possible with static type systems. Can someone please explain this to a novice like me?

Taken literally the claim isn’t true - a Turing complete type system can enforce any constraint that a Turing complete programming language can. But your everyday type systems typically can’t express concepts like “a list of at least 3 elements” or “a number which is a power of 2”.

Refinement types and Dependent types can do all of that. But you are right that mainstream languages ca’t do that today. Hopefully that will change.

Re: Tour of our 250k line Clojure codebase

#228

Post by sortalongo »

davidrupp wrote: post #44
mberning wrote: post #14

Earlier quoted context omitted.

It does seem odd. Stealth product. Bold claims. 3 blog posts one of which is a funding announcement and the other two having nothing to do with the product. I am intrigued but also a bit skeptical.

Nathan Marz was the original creator of what became Apache Storm [1], which powered Twitter for some time. Skepticism is healthy, perhaps even warranted here, but I'm not betting against him just yet. [1] https://en.wikipedia.org/wiki/Apache_Storm

“Powered Twitter” is an overstatement. Storm was indeed used at Twitter for select streaming use cases, but it was a bit of a mess and ended up being rewritten from the ground up for 10x improvements in latency and throughout [1]. Marz was at the company for Storm is also not very well regarded in the stream processing community due to its restrictive model, poor guarantees, and abysmal performance [3].

I have nothing against Marz, but I do think skepticism is warranted until we see what they’ve built.

[1] https://blog.twitter.com/engineering/en_us/a/2015/flying-fas... [2] https://blog.twitter.com/engineering/en_us/topics/infrastruc... [3] I worked at Twitter for 3 years, then at Google on Millwheel and Streaming Dataflow.

Re: Tour of our 250k line Clojure codebase

#229

Post by raspasov »

coneill wrote: post #220
raspasov wrote: post #109

Earlier quoted context omitted.

I've been using Clojure for almost 10 years and writing macros has always been discouraged in the community. You don't see too many of them in the wild, and for good reasons. If you're writing macros on a daily basis, you better have a really good reason for it.

The codebase im in is 10+ years old and macros are everywhere. Were macros a super hyped at one point in the past? I'm fairly new to Clojure just by virtue of being part of this system rewrite but I see stuff everywhere in the code im working in like in the article where there just seems to be macros that accomplish nothing except obscuring already built in constructs for the sake of maybe saving a few lines of code…

No, I don't think they were hyped at any point.

They are used in certain libraries like https://github.com/ptaoussanis/timbre but for things that are simply not possible without macros, for example (timbre/spy (+ 1 1)) will actually print both the expression and the result:

DEBUG [ss.experimental.scratch:1] - (+ 1 1) => 2

This is one of my favorite debugging tools. IMO beats a debugger hands down! Printing can also be disabled with a global library flag without code modification.

Perhaps if the macros are "simple" they can be unpacked relatively easily. I do understand how mentally challenging that can be for somebody who's just starting with Clojure. I've been using Clojure for a long time and only just recently became more comfortable with macros after I made a conscious effort in that direction. I'm still far from an "expert" in them.

Re: Tour of our 250k line Clojure codebase

#230

Post by justsomeuser »

justsomeuser wrote: post #200
chromanoid wrote: post #77

> One of the coolest parts of our codebase is the new general purpose language at its foundation. Though the semantics of the language are substantially different than Clojure, it’s defined entirely within Clojure using macros to express the differing behavior. It compiles directly to bytecode using the ASM library. The rest of our system is built using both this language and vanilla Clojure, interoperating seamlessl…

I thought the same. Clojure is already a niche language, but then you go and niche the niche by implementing another language on top. Could work out if its essential to offering a 10x service, but I doubt the multiplier is that higher to warrant such an engineering cost of developing and maintaining another language on top of Clojure. Also, there would be many layers to get to the machine code (Custom lang -> Clojure…

If you disagree please explain your perspective...
Post reply on HN