I felt the same way with fp-ts then effect in typescript. Pretty cool libraries and I learned a lot about FP while trying them out for a couple of years, but a lot of ceremony and noise due to them (especially effect) almost being a new language on top of typescript.
Recently got the opportunity to try out elixir at my job and I'm liking it thus far, although it is an adjustment. That static typing and type inference are being added to the language right now is helpful.
I had a similar impression with using those constructs on TypeScript.
IMO it's hard to justify creating Option<T>/Result<T,E> wrappers when T|null and T|E will work well enough for the majority of use cases.
effect specifically feels like a different programming language altogether. And maybe going that path and compiling down to TS/JS could've been a better path for them. I'm not on the ecosystem though, so it's an uninformed thought.
I was thinking about this as an approach for a side project to build in order to (speed up) learn elixir/phoenix for work. While the old-school forums dedicated to specific topics work (why re-invent them?) I was thinking of a "tribal" social network.
You as a person decide you want to create a space with a combination of reddit-like features, maybe video, etc. Only people you invite can discover it (or you can allow them to invite people) It could work for neighborhood groups (similar to nextdoor but with a limited crowd that you like/trust), school groups, family, or specific interests -- although specific interests are the idea's weakest selling point since it lacks easy discoverability.
Yeah, there are forums, discord, etc. etc., but I thought it could potentially be interesting. And yeah, people would abuse it (i.e., share pirated and illegal content), so maybe not really viable.
Meh, I used to have that feeling, especially when discovering fp-ts and then effect (neither of which I've been paid to write), but after about four years, I'm tired of writing it period. The standard library for node is horrible; the ecosystem is okay but not great. And I don't even care for effect anymore. I also write go in my job and it's just okay, but the standard library is much better.
I've been playing around with rust in my free time and like it. I think it's a good FP middle ground. Gleam also looks interesting. But to your point I imagine there aren't many jobs paying for rust and practically none for Gleam.
I’m personally strongly opposed to using any library that becomes a new primitive of my project. I’m fine with an intrusive framework, but never a fundamental change to how plain-old business logic is written. That means fp-ts is out. However stuff like JS’s Date can be replaced under these rules - these days perhaps with a Temporal polyfill.
I believe Fly.io deploys some Gleam in prod. I tried playing with Gleam for a bit, but I got stuck trying to make the Actor Model make sense. It’s Gleam’s solution to mutable state, inherited from Erlang and the BEAM. It takes so much code just to emulate a simple, mutable Map. I liked Rust’s middle ground with `mut` in function defs.
Okay, how am I supposed to use them "correctly"? Because me explaining step by step, more so than a junior developer, how to do a small task in an existing codebase for it to get it wrong not once, not twice, not three times, but more is not a productivity boost.
And here's the difference between someone like me and an LLM: I can learn and retain information. If you don't understand this, you don't have a correct understanding of LLMs.
It is entirely true that current LLMs do not learn from their mistakes, and that is a difference between eg an LLM and a human intern.
It is us, the users of the LLMs, that need to learn from those mistakes.
If you prompt an LLM and it makes a mistake, you have to learn not to prompt it in the same way in the future.
It takes a lot of time and experimentation to find the prompting patterns that work.
My current favorite tactic is to dump sizable amounts of example code into the models every time I use them. I find this works extremely well. I will take code that I wrote previously that accomplishes a similar task, drop that in and describe what I want it to build next.
Is it not a bit weird to freely give give away your entire code base (I assume it's personal, not your company's, but maybe I'm wrong) to an entity like Google?
As a business owner that uses Cursor, this is a real risk that I worry about (third parties stealing my code). However, the massive productivity benefit of having access to AI tools far outweighs the risk of them copying my business based on the code alone. Besides, AI is making code less and less valuable. My code is not the moat -- the hard part is the network, traction, brand, distributions, etc.
How common is it to have a personal project that isn't open source? Probably more common than I think, but it seems like a foreign concept to me.
Either my code isn't commercialized so I don't mind "giving" it away, or it is commercialized but wouldn't be safe from a clean room implementation anyway. Isn't that what bigco would do of they really wanted to steal your idea?
It's been refreshing to read these perspectives as a person who has given up on using LLMs. I think there's a lot of delusion going on right now. I can't tell you how many times I've read that LLMs are huge productivity boosters (specifically for developers) without a shred of data/evidence.
On the contrary, I started to rely on them despite them constantly providing incorrect, incoherent answers. Perhaps they can spit out a basic react app from scratch, but I'm working on large code bases, not TODO apps. And the thing is, for the year+ I used them, I got worse as a developer. Using them hampered me learning another language I needed for my job (my fault; but I relied on LLMs vs. reading docs and experimenting myself, which I assume a lot of people do, even experienced devs).
When you get outside the scope of a cruddy app, they fall apart. Trouble is that business only see crud until we as developers have to fill in complex states and that's when hell breaks loose because who tought of that? Certainty not your army of frontend and backend engineers who warned you about this for months on end.....
The future will be of broken UIs and incomplete emails of "I don't know what to do here"..
The sad part is that there is a _lot_ of stuff we can now do with LLMs, that were practically impossible before. And with all the hype, it takes some effort, at least for me, to not get burned out on all
that and stay curious about them.
My opinion is that you just need to be really deliberate in what you use them for. Any workflow that requires human review because precision and responsibility matters leads to the irony of automation: The human in the loop gets bored, especially if the success rate is high, and misses flaws they were meant to react to. Like safety drivers for self driving car testing: A both incredibly intense and incredibly boring job that is very difficult to do well.
Staying in that analogy, driver assist systems that generally keep the driver on the well, engaged and entertained are more effective. Designing software like that is difficult. Development tooling is just one use case, but we could build such _amazingly_ useful features powered by LLMs. Instead, what I see most people build, vibe coding and agentic tools, run right into the ironies of automation.
But well, however it plays out, this too shall pass.
Or someone who has been a developer for a decade plus trying to use these models on actual existing code bases, solving specific problems. In my experience, they waste time and money.
Recently got the opportunity to try out elixir at my job and I'm liking it thus far, although it is an adjustment. That static typing and type inference are being added to the language right now is helpful.