167 karma · joined June 23, 2015
Location: Slovakia (GMT+1)
Remote: Yes
Willing to relocate: No
Technologies: Clojure, Docker, Common Lisp, Bash/Zsh, Python ...
Email: petern@riseup.net
Résumé/CV: https://drive.google.com/file/d/1YzYDnSo-u823VNVIljVHH6vt8cd...I am currently a core maintainer of Electric Clojure (https://github.com/hyperfiddle/electric), a full-stack, reactive, differential language we use for building rich, dynamic UIs. Most notably I developed the last 2 generations of our compiler and pioneered the UI composition pattern we use today. I work with Clojure for 7+ years, but also did a lot (4y+) of infrastructure work before - Docker, Kubernetes, ELK stack, Kibana and more. I worked in many other languages. I am a systems-level thinker who derives solutions from first principles. I am looking for a new challenge.
Personally I'm not a fan of this abstraction (another layer of indirection). I'd rather take a `transact` function as an argument.
(e/server (let [is-admin? (e/client ...)]))
Even with mutable atoms you'd have to write the `reset!` on the server.Then came libdill, which created the whole "structured concurrency" movement and brought new concepts to light that are now being replicated in python, kotlin, java...
> In Go for example, I don't remember having to clean up fibers manually.
And that is awful if you think about it a bit. There's no composition happening, your go block just goes off somewhere without you having any control of it. It's like goto, only it forks first and never gives back the process handle[2].
[1] https://clojureverse.org/t/missionary-new-release-with-strea... [2] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
There's no VM in clojurescript, it compiles to JS, it is tree-shaken and heavily optimized and minified through Google's Closure compiler.
> resulting in the software running (in this case) 50x slower
The speedup is not a result of abandoning clojurescript, it's from moving from immutable data structures to mutable arrays and primitives. The same can be done in clojurescript or javascript.
I think this is a common misunderstanding, that's why I'm reacting. Nobody claims immutable data structures to be the silver bullet. Computation-heavy parts need to be done in low level code and with primitive types.
What would solve this issue? A common package manager and central repository, across all Linux distributions. Then the small team only needs to package and ship to one repository, in 1 format.
I think this will be better answered by someone who has crossed that bridge than you simply jumping to that conclusion with no experience or data to back up your claim.
Being a pianist might be handy, but you'll still need to practice a lot to see progress.
Docstrings, writing documentation, talking to colleagues on Slack, asking questions on stackoverflow, writing mails, browsing, working in the terminal. We spend a lot of time writing. How much time could one save by e.g. doubling the speed?
Another aspect is of the working memory - will it free your brain's resources? Will allow writing at the speed of thought allow for new/more thoughts?
I think we should explore these waters, and steno is a solid choice.
Any project of the size you mention needs technical leadership and constrained choices (for IO we use this, we do http this way..). This will be true regardless of what language you're using.
Nobody cares if it compiles together. The point is if a new feature or a bug fix is introduced in a breaking way you cannot bump your dependency and start using it, or progressively move to the new API.
I also failed to understand the "everything is a java.lang.Object" sentence. It doesn't make a clojure map mutable. In the end it's all just ones and zeroes, but that misses the point.
Please note that forcing an execution model in the language will inadvertently cause headaches for some kinds of domains. Since clojure makes no wild choices the language can be ported to other runtimes (.net, js) and benefit from future runtime improvements without breaking the language (JVM virtual threads, value types).
Since the core is small and lisps are extensible, we can have a multitude of choices in libraries. So if you really like typy things you can check out core.typed, spec, schema, malli etc. If you want async you can check out manifold, promesa, core.async etc. If you want non-blocking effects handling you can check out missionary or darkleaf/effect.
I'll enjoy reading your production-grade brainfuck code.
A language's built-ins and idioms greatly influence what you say and how you say it. If your mother tongue doesn't have words to describe any emotions you'll have a hard time explaining them. You're talking only about the other side of the coin. Yes, people can write terrible clojure code, you need to be a good programmer to write good code. But please consider rewriting this bash one-liner in pure C (or assembly)
grep FOO */* | wc -l
Having a language to express your domain concisely is essential in reducing code complexity, time-to-market, bugs etc.Yes, and the result of that is cabal hell. Types aren't there to help you break your API. Once the API is out and it has users it is rude to break them. The linux kernel is a prime example how far can you get if you don't break your users.