_halgari

CLJS has been self hosted for about a year now. It's cool, but its really not needed. Google Closure on the other hand is amazing. I've seen speed improvements of 10x when switching to advanced compilation mode. Its not just dead code elimination, its also partial evaluation and inlining.

If you enable source maps you can set breakpoints in your cljs code. And IIRC browsers are testing support for non JS reply right now.

React is about the only real framework in the ClojureScript community, via frameworks like Om.Next and Reframe. React in JS is rather clunky since you're dealing with a mutable language that prefers OOP primitives. In ClojureScript most UIs are data-driven and declarative and that's where the strengths of React really shine. So I would argue that ClojureScript turned React into a better React.

Absolutely, I think the "perfect world" would be adopting some of the ideas Rich proposes but adding (git url + sha) as the dependency management system.

Of course for that to work well you'd also need to protect yourself from people deleting their git hub repos, or rewriting git history.

Sadly then Go went and shot themselves in the foot. Originally (I assumed this hasn't changed), you specified dependencies via git URLs. Sounds great, but then they went and said every dependency always used the head of master. So now you're in the horrific situation of your deps suddenly changing whenever your build decides to pull the latest from the git repos.

(Note: I don't use go, but this was the situation about 3 years ago when I last looked).

Read up on Lisp Favored Erlang, there's a lot of reasons why Clojure doesn't work well on BEAM, and they're covered by the author of LFE.

Exactly my thoughts. Every DSL needs an escape hatch at some point. What do I do when EVE isn't fast enough or lacks some feature I need.

ZMQ's default behavior (and in some cases only behavior) of dropping new messages when buffers are full, made it a no-go for my client. We ended up switching away from ZMQ to a more traditional durable queue and ended up saving a ton of code complexity and got a lot of reliability in the process. Having now researched it I can't think of a reason I'd ever use ZMQ again. I'll either use a durable queue when I care about message delivery, or something much more traditional when I don't.

"Elixir is blazing fast" it says, so I follow the link and notice that "blazing fast" apparently means 10x the speed of Ruby. I don't think that phrase means what they think it means.

You honored my rant with a reply, so I will honor it with a reply as well :)

The problem is this...when software is designed it is critical to know what is being solved. I don't think the problem set or the way they will be solved has been nailed down, or if it is, it has never been properly explained. In two years of work, and 2mil in funding I would have expected at least a usable alpha (80% complete prototype) in this amount of time. Perhaps that's a wrong expectation, but without even a problem statement and a roadmap, how am I to know?

I have yet to see a rationale for Eve. I'd love to see a 1 paragraph description of what the problem is Eve is trying to solve. Then a bullet point list of goals and non-goals. After that I would love to see a list of architectural decisions (is Eve distributed or not, what size of datasets is Eve aiming for, etc.). After that I'd love to see a list of tradeoffs (because we are distributed, we have these problems. 1GB datasets will require optimizations around ingestion, etc).

Without all of this, all I see is two years of vaporware and a few developers spending investor money hacking on pet projects.

At this point the Eve project is so far out in left-field it's astounding. If you start with Lighttable and move on through Aurora and Eve you see the same patter over and over.

1) say X is broken we should fix it 2) we will fix X in a way that we don't have time to explain in detail now 3) please send money! 4) .... 5) we didn't solve X but we worked on Y and Z! 6) Y is broken we should fix it. 7) don't have details on how we will solve Y but please send money. 8) .... 9) we didn't solve Y but we worked on Z and Z'

What started as a Lighttable eventually got set-aside for Aurora. What then started as a Excel like environment, morphed several times into databases, temporal stores, and who knows what else. The even started building Eve in Rust and Typescript! Can't see those anymore on the github, but hey! I can see Lua and JS!

I tend to agree. In my opinion, if a job interview required me to brush up that much on a topic it either means:

a) the company is putting to much emphasis on "non-google" programming, which doesn't match reality (real software engineering isn't a closed book test).

b) I don't know the subject matter well enough and it would be a bad fit anyways.

Install IntelliJ install cursive. Done.

Have a friend who as learning to program. He got Cursive going in less than 30min

Something that is often very hard to understand (it took me years to do so). Is that maintaining a language is insanely hard. Everything has a cost. Let me give a good example: A few years back someone submitted a patch that improved the error messages in Clojure. Worked great, just a single extra "if" and a message. It was committed to master.

Then people's code got way slower. Why? Well this was a often used function and that single if blew the JVM inline budget causing that function to never be inlined. And that improvement had to he yanked out.

When we talk about patches for a language, we have to realize that if we don't want constantly breaking APIs we have to test that a patch doesn't break existing code, that it also doesn't slow down existing code (or at least not enough that users would care), that in all sorts of cases the JVM won't freak out and do something bad. Then we also have to make sure that the change doesn't restrict the language in the future. Does making some interface public mean it will always be public? Are we happy to keep it that way for all time?

Taking all that into consideration, I have to sit back and say , yeah, maybe I'll just remember to only hand sets to the functions in `clojure.set`. Or maybe I'll help out by adding clojure.spec annotations for these functions so I can turn them on during testing.

In the end, I'd much rather have a rough-around-the-edges language that takes a garbage-in-garbage-out approach, than one that breaks the API at every turn. Perhaps they aren't mutually exclusive, but it certainly takes a heroic effort, and a lot of prioritization.

After some truely horrific experiences with Riak K/V, especially combined with Riak Solr, I won't touch anything from Basho with a ten foot pole. Not sure what's going on over there, but the reality of Riak in production was miles away from what Basho's sales claimed was possible. And yes, we even spent about 4 months working with their tech support. It almost seems that "It's based on Erlang thus it scales" was the entirety of their design work.

I've also worked with Cassandra and have nothing but good to say about it, did what we asked it right out-of-the-box. Datastax was really helpful as well.

--

And I have no affiliation with either Basho nor Datastax, just really happy with one product and completely blown away with the poor performance of the other.

Can you link a quote or a point in that video? What does Boeing's use of Clojure have to do with Cognitect?

I find it highly implausible. Most likely OP ignored the full context of the statement. I can't imagine any of my co-workers recommending Java Maps over PHMs except in very rare interop situations. Likewise, I can't remember the last time I even saw a ConcurrentHashMap used in Clojure code, or STM for that matter. Most of the code I write, and work with, is as recommended for years: Persistent data in as few atoms as possible.

No ill-will directed at the OP, but it's hard not to take umbrage at the suggestion that I am a snake-oil salesman. So yes, references please!

>> "don't use persistent data structures, use Java's" Love to see a reference for this.

yes, to bump a version number in a build script. the last meaningful change was 3 months ago.

This article is several months old, and the linked repo hasn't been updated in about two months.

No, it's just that things like actors and STM, and yes, even LMAX are completely overkill for many of the projects out there. Go read up on what LMAX was designed to solve, millions of messages a second. I've worked on several very large projects for huge corporations, where their message load was 1 thousand messages a second peak.

So yea, I don't use STM much, and I never use actors, I use queues quite a bit, but I benchmark them first and use the one that fits best with existing infrastructure and causes the least amount of friction with my client while still getting the job done. It has nothing to do with "actually working on hardware" or "science". Except perhaps that I apply the scientific method in choosing my tech, and that never ends up being LMAX for the jobs I work on.

Except some of us understand these concepts, see how they can be used, but yet don't understand why we would ever use them.

In all these sort of articles I've never seen something that can't be done simpler with a bit of mutability sprinkled here and there. Sure having something 100% pure is great, but I don't know if I want that if it requires a 10x increase in complexity.

Programmers should know their trade-offs. It's not so much that STM should be avoided, but that the use cases it was designed for don't often present themselves in production. Same with agents, core.async, metadata, etc.

So I also get a bit twitchy when I hear for wholesale use of Timbre, Component, Schema. Every one of these libraries has tradeoffs. And those tradeoffs should be understood before adopting them. As an example, if you have a need for Schema, perhaps your data model needs some refining. Maybe you need Schema at the edges of your API, but you should define why you need a library before you just adopt it wholesale.

Likewise with Timbre, often we need tight integration with Java tools, so perhaps my project really does need a "native" java logging library.

Perhaps "understand all the trade-offs" should be the mantra of programming, in any language.

Pieter, I spoke with you back in 2013 at CodeMesh, about OSS development. I remember asking "if you default to merging PRs even if you don't agree with the, how can you assure quality control". And IIRC your answer was something along the lines of : "Why should I assume that I have the only answer for what quality is".

The frank humility of that answer has stuck with me over the years. And that simple 15min conversation has resulted in hours of contemplation. So thank you for making me think.

Agreed, I'm not even convinced you need anything async here. In that sense you could probably write this with OS threads and you language of choice.

Big hairy core.async go blocks like shown in these articles makes me a tad uneasy (see the sync source in the second part to this article). Because they seem to be programmed in a mostly imperative style. Almost every time I see a go block loop, I see code that could be better written with core.async/pipeline. `If` statements can be come filters, transformations can become map. And with the addition of transducers all this becomes much cleaner.

So in that sense, I think many FRP-esque libraries have something going for them, they force their users into a model that is more declarative than imperative. That sort of programming can and should be done with core.async. Go blocks are a primitive, build abstractions on top of that and keep your app code declarative.

It's an excellent paper. The way it describes logic programs as a stream of environments is very general. I've taken the basic concepts in this paper and implemented them with Clojure lazy seqs, CSP (https://github.com/halgari/async-mu-kanren/blob/master/src/a...), and transducers. Monads (as described in this paper) probably have the fewest drawbacks, but the technique can be implemented many ways.

I recommend the following: 1) read up on how Om.Next handles remote calls. Not that it's the only way to do it, but it de-couples the async functionality of a remote call from the rendering loop. 2) Just code against something like Google Closure's XHR libraries, making a HTTP call isn't complicated, just wrap basic functions to suit your needs.

But over all, no matter what you use, core.async, or callbacks or whatever, limit the async bits to the edges of your code. Done correctly (Om.Next is a great example) you shouldn't need a whole lot of async bits to get a nice clean app. If you have core.async "go" blocks littered all through your codebase, you're doing something wrong.

One of the reasons that ClojureScript is so fast and efficient is that it leans heavily on the Google Closure optimizing compiler. This compiler goes beyond normal "minimzation" and goes into dead code removal, function inlining and a ton of other stuff. That compiler is written in Java. So it's highly unlikely that JVM is removed as a dev-time requirement anytime in the near future.

On the other hand, I have never really seen a need to remove it. Once the CLJS compiler is up and running, incremental compilations on huge codebases (~300 files) takes a fraction of a second. So in the end...I'd rather have the JVM as a requirement if it allows that fast of a dev cycle.

let's not forget crazy stuff like going into debug mode and then evaling random clojure code in the context of the debugger