271–280 of 320 posts
Earlier quoted context omitted.
Another approach is career suicide. Both moves are isomorphic in many companies today and will be pretty much all companies in the future.
I don't really understand your comment. Are you saying it's "career suicide" to not use AI slop?
Earlier quoted context omitted.
Such as? Having known Lisp since 1996, and avid digital archaeologist, I wonder which famous implementations are those.
Even Emacs Lisp has had a byte code compiler since forever, and since Emacs 28 it compiles to native machine code via libgccjit. Toy lisp interpreters are easy and fun and everywhere, often written in lisp itself, but the same books that teach them go on to teach compilers. SICP chapter 4 is the metacircular evaluator, chapter 5 is the compiler. That ordering is the point: interpretation is the pedagogy, compilation…
WOW.
Hey Avi - didn't know you were an HNer fun to see you / your co on here :)
I am surprised by this take, honestly. We're a Haskell shop (and have been for over 10 years now) and are finding agentic development with Haskell to work pretty damn well. Cold compile times in Haskell are painful indeed. Our development practices don't really cause us to do that much - even with agents. It's unclear to me if the development practices at Scarf that cause them to hit this pain often are worth it if i…
It not that it didn't work at all, so much as that it worked much better in other languages when we compared side-to-side. It's possible we had dev practices that could have been modified further to suit Haskell better (we had been doing that for years already), but increasingly I want the toolchain to adapt to us, not the other way around.
Most of the issues presented are valid, but overstated. It’s just PR for the swap.
I'm not trying to be reductive but the article's a lot of words for "We're vibecoding our app now and the glorious (almost almighty) Haskell compiler is too slow for the agent to iterate it's mistakes until it gets it right."
I strongly agree with the premise of this article, which is why I am surprised that the author moved away from Haskell to Python. For some time now it’s felt clear (or at least extremely) compelling that agents need fast compile times in order to be effective, especially when you’re working in parallel. But the other thing that has felt just as obvious is that agents need strong type systems and narrow guardrails in…
Main factors were (roughly in order): - None of us are experts in Rust, and we're all solid at Python. - Rust felt like an under-correction for what we wanted (get all friction in front of the LLM out of the way). - Our high-performance stuff is not being migrated at this time (Scarf Gateway), so we're just talking about basic CRUD backends here. Basically any language will work.
But as others said: if Haskell was not giving you too much in terms of excellent typing system then maybe going for a PL with a much faster compiler like Golang would have been best for you.
I'm not trying to be reductive but the article's a lot of words for "We're vibecoding our app now and the glorious (almost almighty) Haskell compiler is too slow for the agent to iterate it's mistakes until it gets it right."
I'm not trying to be reductive but the article's a lot of words for "We're vibecoding our app now and the glorious (almost almighty) Haskell compiler is too slow for the agent to iterate it's mistakes until it gets it right."
I was puzzled by this article at first, but when you put it that way it makes more sense. The author also had a presentation awhile back about why Haskell is a terrible language for startups to adopt. I imagine that in the current venture environment vibe coding is being pushed heavily by investors since companies are effectively in an arms race where feature development cost is moving towards zero and investors don'…
Iteration speed is not only to appease business people. As a long-time dev I prefer for my PL and its tooling to not stand in my way. I want to be enabled, not be left a scarred veteran with badges of honor like "Managed to install 5 dependencies and compile and run! And it only took me 3 hours!" or some such.
Compare to Golang, Rust, Elixir, and no small amount of others -- you add a dependency, run a command, twiddle your thumbs 30 seconds, done.
I want to solve problems. Not troubleshoot tooling that should have been prod-ready 10 years ago.
I am increasingly wondering if we are in a post-language world in terms of development. Why would I ask an agent to write a server in anything other than the most efficient language, although efficiency can take several forms: runtime, token usage during development, and wall clock dev time (affected by slow compile times for example). My intuition is that type-safe languages with fast compilers are the best option.…