I don't know if this is coincidence or not but Cursor just made a post breaking down why they moved to their own solution in place or Ripgrep and it makes a lot of sense from a cursory (haha) read.
HN user
Royalaid
[ my public key: https://keybase.io/royalaid; my proof: https://keybase.io/royalaid/sigs/hTPgbil9Eyy5V_cnV3EZ0qOR1kFapICILKuZWXPbRlw ]
Was inevitable but it is cool to see that the Cursor team are really making good use of the tech. Tab complete + the new Composer model are very good at targeted, narrow tasks.
Just want to say love your work! Js-interop was super useful when I was working in clojurescript land.
Something like off chain calculations or state management which then can be subtree’d out and used on chain. I think something like 1inch or Paraswap style of app were you need to do huge, in single tx terms, calculations to optimize trades across dexs and then provably import that work on chain. In reality because this is so new I doubt many people have any idea how to actually use it effectively right now but there is a lot of potential.
Cognitect, the company that shepherds and maintains Clojure, has joined Nubank (https://cognitect.com/blog/2020/07/23/Cognitect-Joins-Nubank) and so they are starting to flesh and grow the core team as well as fund some of the open source projects/devs that the ecosystem relies on (https://cognitect.com/blog/2020/12/15/sponsoring-open-source...).
Add to this a lot of people are changing jobs and pushing for using more alternative languages or exploring new languages and as a result many people are building in what they want instead of what they are forced to use at work. The sibling comment about roam is a good example as they have had a lot of press lately.
And more importantly this is what a lot of people are doing in industry, for better or worse, and so seeing this all laid out together is important IMO.
For what it's worth my grandfather has a laundry shoot in his home, but his is in the wall and is small enough that a child would have difficulty fitting through if they should reach.
Just to add to this idea, it's important to understand when the circle is near the start or end especially. I found myself not sure when to start breathing and not sure when to stop. I think the color idea will definitely help but sure if this specifically addresses this issue.
Either way very cool idea for an app
That is extremely fair but again it doesn't have deep hooks and the convenience that Javascript and CRA have with, for example Intellij. This isn't a problem that is easily solved, Colin is only one person and JetBrains is a huge team, but it is still a gap that Clojure needs to have a story around to attract more developers and to make our lives as devs starting new projects easier.
Part of the problem could have been that I was using Spacemacs and package support and that may have broken it but circling back around this connects with meeting people halfway, I don't want to learn Emacs style control, I know Vim, Vim works elsewhere, and I just want to write Clojure. I can do that now with Cursive so the trade off isn't worth it. A lot of people learning feel and think this way in my experience, especially if I selling Clojure to someone who is reluctant, anecdotally at least 4 people I know have followed this path, I am sure it extends beyond them.
Per the big files, its not so much Clojure but output at the REPL. Especially as a noob accidentally grabbing way to much data for a buffer is really easy, Emacs hangs, REPL and process dies and has to be rebooted and you have to bring up everything again. This is non-trivial friction when learning and should really be handled gracefully by the editor.
As for everything else regarding Emacs and learning all these points stand and are valid but still don't address the problem of someone wanting to learn Clojure and instead having to learn Emacs + Clojure + Cider. For someone just starting on the path most won't have more than 3 files of CLJ and may not even interact with Lein or Deps. Refactoring IS important but not to them. I just don't think the trade off is worth it for someone just toying around with CLJ in their free time. It may not be the best metric but "time to hello world" and "time to blog" matter to people coming in because it shows that the promise that they are sold is something that they can reach and achieve.
Mostly that there is an interplay between the config that gets spit out by CRA and the editors that consume it, I don't need to give intellij the run config for the 400th time, it's just there by default. I click run and it runs.
An exercise for you to try that might illustrate it. Setup create-react-app and get hello world up and running. Now do the same with Clojurescript. That should include a way to hot reload and edit because that is often the next steps.
Notice the friction that CLJS still has and the aimlessness of starting from a build script as is suggested on the Clojure site vs getting a functional build in two commands.
I don't want to come across as ungrateful for the hard work that David and Alex and the whole team put in, they are the only reason have dev tools that feel comfortable to me and I can't thank them enough for that, but I just want to point out that friction and difficulty and to try and get people who do understand to put themselves in the shoes of developers who don't and to acknowledge that we as a community can aspire to more.
While we can suggest Cider as an option, I have had nontrivial problems with breakage on updating, Emacs falling over with long lines of text, Windows support, etc. I also know that I am not the only one who has had these problems https://twitter.com/ztellman/status/1055152840589496320.
These kinds of issues a part of the tooling gap and are real reasons people give up on Clojure and I do find the dismissive attitude of most when I have suggested this in the past off putting.
Addressing Emacs specifically, while it would be probably worth the investment it is not an answer most people want to hear and when we suggest that Clojure is this great thing it is important to show people on some of their terms because learning a new editor on top of Clojure more then we should be asking IMHO and for all the talk of Clojure being pragmatic this feels directly opposed to that ethos.
Let me emphasize, I don't want to say anyone is doing anything wrong or that Emacs isn't the right way forward but it had to be acknowledged that there are real problems that path that need improvement when it comes to onboarding new developers and with daily use.
I have posted about this before but Clojure does have tooling problems specifically ergonomics.
Look at create-react-app. Two commands and a ton of editor integration across intellij, vscode, vim, etc gives you incredible access to a rich ecosystem and plugs together really nicely with sensible defaults.
Clojure has some answers in this space but everything feels bolted on and not nearly as polished. A big part of the problem is the size of the community, there just isn't enough hands to build out the infrastructure that other langs enjoy.
I still love Clojure and will continue to use it but in order to do so I have to understand that some simpler things will just be more work.
Unsurprising but still sad to see it be officially cancelled. Having gone the last few years and growing up on Blizzard's games it does feel slowly like Blizzard is losing their way and this kind of throws salt in the wound, not that anyone is to blame for this particular situation.
I think this is a natural reaction to advice being over prescribed and totally agree that in your free time you should do whatever it is you want and this is solid advice.
BUT I think we should also acknowledge that everything that slows you down in your free time has a reason for existing and most of that is communication or knowledge sharing within a team. Naming conventions, unit tests, and general documentation all exist to help other team members keep up with the pace of changes in the repository. If you're not planning to do something in a team setting or for this to be consumed outside of the work that you do then you don't need these things. But if you want to share with everyone else it's important that you don't totally ignore these things because it will come back to bite you in the long run.
Personally I see this a lot in normal interview style questions. They are geared towards an imperative approach, find this thing in a 2d matrix based on some way of manipulating the indexes is a common example. If you try a functional approach it is possible but often times akward or super dense looking code much like the double linked list example above.
I feel like this comes from the fact that while languages are extremely easy to bend into a shape that fits the problem and take a long time to learn so it's often easier for programmers to put out a bad solution instead trying to get the problem and the language to meet in the middle.
Just go look on Twitter, in the Clojure hashtag at least, something that rarely sees people needing jobs, there have been a hire me thread, a several individual posts for people asking work, and more and more post about people getting laid off. This will just continue to increase as the virus does it's thing.
Customer Data Infrastructure
Thanks for posting this. The threat modeling in this thread feels very much out of wack with my personal experience. The thing that has lead to the most compromised accounts for myself is old, short, unchanged passwords on accounts I had forgotten that probably have been leaked.
I think Babashka (bb) takes important lessons learned about how Clojure grew and applies them well. Piggieback on the tools and libraries already in place and just provide a simpler, more uniform syntax and build in portable standard library (in Clojure and I assume in bb just really need to use maps and arrays). Clojurescript (CLJS) does this beautifully and bb is setup to achieve the a similar success story. CLJS is not perfect (see https://twitter.com/royalaid/status/1224830807807676417 for an example of the runtime leaking through) but it is wonderfully pragmatic and incredibly productive and hope to see bb become to bash what Clojure is for Java and CLJS is for JS.
I went through something that rhymes with what you went through. My wife got in USC and I found a job in Irivine. We moved here and things were okay for a while, about 2 years, and then the job was gone. That was a very stressful 4 months. We stuck it out, I commuted to Santa Monica from Irvine everyday ( 6 hour commute by train). Then I eventually found the gig I am at now and have been for the past two years. We go back every Christmas and 4th of July to visit our family's but I have to say everytime I land back at SNA I feel so much relief I am back in CA.
Just my two cents.
I think the reason this happens is because there is a belief that, and who knows maybe it's the truth, people buy emotionally. Business and marketing books (E-myth and How to win friends come to mind specifically) constantly parrot that "sales studies" and "marketing research" show that people buy, or this case download, with their feelings. This seems to lead people to add vacuous fluff to marketing pages to "appeal" to someone's emotions.
As you can tell by most of comment I think this isn't the whole truth and that really things live somewhere in the middle and that the domain and scope of interaction greatly shift this spectrum one way or another, picking a doctor/lawyer vs picking and IDE comes to mind for myself, YMMV with that example and might even further drive home the point.
Long story long, marketing is hard and the people doing the marketing often aren't domain experts and have to rely on the information passed to them through a convoluted game of telephone via authors and experts that can't even communicate everything needed to be effective because they themselves aren't good at teaching.
I have been messing around with Flexbox quite a bit at work and this will be a super useful reference, thanks!
I will say that the latest changes on nightly really feel like it is close enough to other browser to be a decent replacement
I love Learn X in Y minutes! It is a great reference (how do I do basic thing x in language y) or useful for teaching yourself the basics of a language if you know one that rhymes e.g. C# and Java.
I used it recently to get my barings in Bash and then used the terminology I learned from the examples to finish my glue code.
Was this code good and super idiomatic? I don't think so but I also don't care. That job is done and I am on to bigger and better things.
Much like Wikipedia with regards to research, it's an overview and gives you the tools to dig deep but it doesn't really "teach" you any given language.
The biggest thing I have noticed, granted I don't have a ton experience with either system, is point 1 outlined in the "Other Differences" section.
Datomic’s datom model provides a very granular and comprehensive interface for expressing novelty through the assertion and retraction of facts. Crux instead uses documents (i.e. schemaless EDN maps) which are atomically ingested and processed as groups of facts that correspond to top-level fields with each document. This design choice simplifies bitemporal indexing (i.e. the use of valid time + transaction time coordinates) whilst satisfying typical requirements and improving the ergonomics of integration with other document-oriented systems. Additionally, the ordering of fields using the same key in a document is naturally preserved and can be readily retrieved, whereas Datomic requires explicit modelling of order for cardinality-many attributes. The main downside of Crux’s document model is that re-transacting entire documents to update a single field can be considered inefficient, but this could be mitigated using lower-level compression techniques and content-addressable storage. Retractions in Crux are implicit and deleted documents are simply replaced with empty documents
So what this means in pratice is that in Datomic you don't really "have" an entity/document (this isn't entirely true but feel free to dig into the details https://docs.datomic.com/on-prem/entities.html) but rather a set of facts (rows/tuples) at any given time, or across time, generally gathered up under one id. You can query on one of those facts and get exactly that back, one or more specific facts. Crux has this ability to query parts/attributes of a document but in terms of updating its all or nothing. There are other, more niche, considerations. One example I can can cite is looking at an entity through time in Datomic can be alien at first whereas with Crux its just a document, but overall this is the biggest thing I have noticed.
Oh and Datomic is pretty well battle tested and has the full support of Cognitect behind it whereas Crux is a newer OSS product by Juxt. That is both a pro and con for both camps, just depends on your needs.
Having dealt with Datomic at work I really have come around to the way thinking that Datomic promotes. Having history that you can query along with having datalog and a graph database as opposed to a relational database has its benefits.
While it isn't the same https://juxt.pro/crux/docs/index.html is a good compromise in the space and is open source albeit a very freshly released project. One of the major blockers I had to adoption, needing Kafka, is no longer an issue with the release of https://github.com/juxt/crux/tree/master/crux-jdbc. A great starting point if anyone wants to check Crux out at a distance is https://nextjournal.com/crux-tutorial, starting https://nextjournal.com/crux-tutorial/start
Are you using Clojure or Clojurescript?
Afaik this is not true see https://shadow-cljs.github.io/docs/UsersGuide.html#target-no...