Hacker News: unlogic

New comment by unlogic in "Googlebook"

unlogic — Tue, 12 May 2026 22:42:12 +0000

Taken out of context, an 18+ device called Magic Pointer coming from Google would be wild.

New comment by unlogic in "I'm going back to writing code by hand"

unlogic — Mon, 11 May 2026 13:49:16 +0000

Turning didn't work for me. Impressive as hell indeed! The author is probably already busy 100xing other projects, no time to fix such a minor nuisance.

New comment by unlogic in "Ask HN: Why is "Tea" still on the App Store after so many data breaches?"

unlogic — Wed, 30 Jul 2025 12:37:37 +0000

And that angry user base will do what, exactly? Switch to Android? One can dream.

New comment by unlogic in "Don't Be Frupid"

unlogic — Mon, 10 Feb 2025 19:26:20 +0000

I believe you, but it would be nice if you called out the exact vendors that do that, for others to be cautious. It's not like their pricing is under NDA, right?

New comment by unlogic in "Don't Be Frupid"

unlogic — Mon, 10 Feb 2025 19:20:30 +0000

The term "linear scaling" was invented by cloud companies to sell more cloud.

New comment by unlogic in "Critique of Lazy Sequences in Clojure"

unlogic — Mon, 07 Aug 2023 12:49:46 +0000

Clojure authors are quite conservative about adding such opinionated instruments into the language, especially when they come from outside. But fortunately, being a Lisp allows Clojure to add such language modifications with libraries without forcing those modifications upon every user of the language.

New comment by unlogic in "Critique of Lazy Sequences in Clojure"

unlogic — Mon, 07 Aug 2023 12:47:53 +0000

It could certainly be redesigned to have explicit lazy collections/operations and use transducers as the composition glue. It would be a breaking change, so it's never going to happen in Clojure. But if somebody plans to design a language inspired by Clojure, they should certainly take this hint.

New comment by unlogic in "Critique of Lazy Sequences in Clojure"

unlogic — Mon, 07 Aug 2023 11:37:54 +0000

Well, if you already use transducers, then you are not exactly the target audience:). It's meant more for the younger developers who see a core language feature and feel inclined towards using it despite the drawbacks.

> In other words, it's something I don't think much about anymore, and it doesn't inconvenience me in any noticeable way.

Interesting, because it still does bother me. I mean, if I use lazy sequences and functions on them. Sure, if I consciously avoid them, then it doesn't me anymore, that's the point of the article :D.

New comment by unlogic in "Critique of Lazy Sequences in Clojure"

unlogic — Mon, 07 Aug 2023 08:37:02 +0000

I'm sorry my article had such an effect on you. Despite the inconveniences, it is still a very worthy language to pick up.

Java's Project Valhalla vs. ray tracer: will it go faster?

unlogic — Mon, 03 Jul 2023 13:42:12 +0000

Article URL: http://clojure-goes-fast.com/blog/valhalla-vs-ray-tracer/

Comments URL: https://news.ycombinator.com/item?id=36572760

Points: 7

# Comments: 0

New comment by unlogic in "Beyond Functional Programming: The Verse Programming Language [pdf]"

unlogic — Mon, 12 Dec 2022 10:10:11 +0000

This you can't do, unfortunately. Would have to do something stupid like `(< -1 index length)`.

New comment by unlogic in "Facebook apologizes to users for Apple’s monstrous efforts to protect privacy"

unlogic — Thu, 27 Aug 2020 13:08:54 +0000

IDFA is a cheatcode of its own (ID Full Ammo).

New comment by unlogic in "Storm 2.0"

unlogic — Sun, 02 Jun 2019 15:28:11 +0000

Oh no, I'm saying it's another usecase, not the only one. And yet, it is a pattern I follow quite often in my mixed Clojure/Java projects: Clojure code is much easier to tinker with, take to new directions, rapidly modify and see the results. But once I settle with an approach/algorithm, I rewrite some things to Java for performance, or for easier interop with other Java/Scala teams, or because the imperative mutable code looks much better in Java.

So, you can say that Clojure among everything else is my IDE to write Java code. Is that a bad suit for a language? Depends on your perspective, but I personally am very happy that I have Clojure by my side.

New comment by unlogic in "Storm 2.0"

unlogic — Sun, 02 Jun 2019 11:45:57 +0000

Whatever the benefits of Clojure are, they were enough for Nathan Marz and first contributors to write Storm in it and succeed. Note that it's not an argument about impossibility of writing something like that in Java (see Spark, Flink, Heron, etc). But at that exact moment in time, a Clojure Storm was created and became useful to many people for years. There were many more Java programmers than Clojure programmers then and now, yet the Java coomunity didn't produce their own Storm first.

I think it speaks of something.

New comment by unlogic in "Storm 2.0"

unlogic — Sun, 02 Jun 2019 09:41:33 +0000

To me, this makes total sense as the project moved to Apache. Obviously, much more people will be able to consider contributing when it's in Java. Apache goal is sustainability and long-term viability, and Java would work better for that.

I also consider this a success story for Clojure. It gives Clojure another usecase: a "production-ready prototype" language where the resulting "prototype" can last for eight years and benefit thousands of developers until it gets rewritten to something else when all the hard questions are answered, and most experimentation/wandering is over.

New comment by unlogic in "Shenandoah GC in production: experience report"

unlogic — Sun, 12 May 2019 17:59:11 +0000

Well, if caching takes a small part of the overall workload, then you can't really say it's a "cache workload" or "cache-heavy workload", right?

My answer meant that Shenandoah would work well in a program where cache occupies like 70-80% of the heap, and generational GCs might not. But surely, neither are going to break from a 1%-heap cache.

New comment by unlogic in "Shenandoah GC in production: experience report"

unlogic — Sun, 12 May 2019 14:24:16 +0000

> wouldn't the majority of allocations still happen during a request?

Could you please clarify this question? Do you mean that if cached objects are a small part of the total allocation rate, then generation GCs work well with that?

New comment by unlogic in "Shenandoah GC in production: experience report"

unlogic — Sun, 12 May 2019 10:05:14 +0000

Typo

< tenures all those requests to OldGC

> tenures all those requests to OldGen

New comment by unlogic in "Shenandoah GC in production: experience report"

unlogic — Sun, 12 May 2019 07:39:34 +0000

Completely vice-versa, Shenandoah is much better for caching because it is NOT generational. [LRU] Caches go against generational hypothesis because the oldest elements are evicted first.

New comment by unlogic in "Shenandoah GC in production: experience report"

unlogic — Sun, 12 May 2019 07:37:50 +0000

Hi, author here. You are saying exactly what I was thinking before. But turns out, generational GCs have nasty failure modes when things don't go as expected. E.g., if an upstream experiences its own difficulties and returns responses slower, our service has to keep all the requests in memory longer, so the heap runs out, and G1 performs a few fruitless YoungGCs (without freeing much) and then tenures all those requests to OldGC, and now you have a big OldGC pause bomb waiting for you.

Non-generational GCs don't have this problem, and it's one of the reasons why Shenandoah suited us well there.