Earlier quoted context omitted.
It’s honestly top of mind question for someone like me, who loves Clojure but doesn’t want to be disadvantaged for this reason. Like I wonder if the “Blub paradox” is still real or if we’re in a world where “if Blub isn’t the answer you aren’t using enough of it (spat from an LLM)”. Like try finding YC job posting without TS and/or Python in the requirements :-/
if you like working in a certain language, just do it and the opportunities will come along. I really love elixir and I started 5 years ago when it wasn't so popular. nevertheless, I found a niche building MVPs for people. eventually I met my cofounders and we built our entire startup on elixir. today I work on elixir all day and we recently hired an elixir engineer.
Electric Clojure v3: Differential Dataflow for UI [video]
51–53 of 53 posts
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#52Earlier quoted context omitted.
I've seen that the author of Electric Clojure is pretty involved in the startup scene and I was curious about how those folks perceive the changing world.
It’s honestly top of mind question for someone like me, who loves Clojure but doesn’t want to be disadvantaged for this reason. Like I wonder if the “Blub paradox” is still real or if we’re in a world where “if Blub isn’t the answer you aren’t using enough of it (spat from an LLM)”. Like try finding YC job posting without TS and/or Python in the requirements :-/
- locally reasoned about (pure functions that compose)
- static type checking (so that nonsense is discovered at compile time)
Weirdly this makes Python a worse choice and Haskell a better one. Clojure benefits a little bit.
I don’t think people are choosing language stacks based on what is best for the problem. The main factor is “what do I already know?”
Re: Electric Clojure v3: Differential Dataflow for UI [video]
#53Earlier quoted context omitted.
if you like working in a certain language, just do it and the opportunities will come along. I really love elixir and I started 5 years ago when it wasn't so popular. nevertheless, I found a niche building MVPs for people. eventually I met my cofounders and we built our entire startup on elixir. today I work on elixir all day and we recently hired an elixir engineer.
you made the decision to start elixir before the rapid recent developments of AI. it's a different world now, and the value that elixir provides relative to another language e.g. python is much different now. it makes far less sense to do what you are talking about in the current state of the word.
Copilot and other ai powered autocompletes mostly amount to large boilerplate generators. macros in lisp and elxiir are strictly better in terms of long term maintenence in the cases that warrant that. But autogenerated code with a junior checking it in under "trust me bro" does not instill confidence in me.
I'm reminded of a situation a few months ago with my (nontechnical) cofounder. He had been discussing our recent funding round and strategies for growth with another CTO friend he knew. The approach he was a proponent of was hiring a bunch of gifted juniors and watching them like hawks. The idea is that they would produce lots of code for all the upcoming features. The problem here is obvious. Juniors make messes and more code != better code. These new AI powered pushes seem to basicly be this strategy on steroids. I can certainly see the strength of it if you're trying to build fast, get traction and get acquired before the house of cards falls apart.
Personally, I don't see it as a optimal strategy when you're trying to build a viable long term business. Platform matters. Ergonomics matter and most importantly, Human intelligence matters. We hired another senior engineer instead and we're doing fine. If I had to do it over again, I would still stick with elixir.