Bekk, a Norwegian consultancy, publishes posts on Elm, front-end performance, UX writing, and team organization, plus its Christmas advent calendars.
HN links it for Elm case studies, including the Vy rewrite and Elm runtime performance work, and for the Bekk Christmas article series.
> - The language doesn't have component composition (like in React or Vue) and you end up having huge chunks of spaghetti code (but to be fair, it kind of works because of the compiler).
Um... yea it does. Elm makes functional composition very easy which which means it's very easy to compose "components" (which are just functions anyway).
> - Only pure functions in Elm, so doing API calls and generating random numbers are unnecessary hard.
I would say that Elm makes doing API calls and generating random #s appropriately hard. Elm strives to corral side effects into one part of the Elm architecture: "commands". By doing this, you're keeping all code that contains side effects at the fringes of the walled garden you're growing.
I think this explicitness/discipline is needed in more codebases.
> - It's complicated to implement routing and to build a Single Page Application.
I agree, it's no Ember, which comes with all the bells and whistles of a full router system, including page transitions, transition errors, data fetching, etc. Richard Feldman has an elm SPA example on github that shows how to create routes, pages, etc. The official Elm Guide also has sections on routing, etc.
> So in the end, Elm is an interesting beast, but I think it's too academical and not really practical for serious projects.
Too "academical"? Tell it to these devs: https://blogg.bekk.no/using-elm-at-vy-e028b11179eb.
I agree, people don't want to manually add all MCP servers they want to connect to. I think we're headed in a direction where dynamic tool discovery will be important. E.g. I want to do "x" which requires doing "y" and "z". The client or server should then search for the tools (or agents as tools) that can do the job. So this would basically be a semantic search for which tools are most likely to do the job, then use those tools, and search for more tools if it needs to. RAG for tools, essentially. I wrote an article on how to give ChatGPT unlimited functions a year ago, where I implemented this method.
I basically created a vector database for functions, and created the store based on the tool description, then added the tool definition as metadata. Then for every request I ran a lookup for tools, added them to the tools list. Since tool definitions are added to the context we would have to do something like this at some stage when we want to implement a lot of tools.
https://blogg.bekk.no/function-retrieval-add-unlimited-functions-to-chatgpt-73916a4606ae
> that is a really short list
But was it a well-known list before this? I hadn't seen it, and know of a few projects that could have been on there.
What I'd like the list to include, though, is some references to the companies discussing using Elm. Pros and cons, the scale to which it is used etc. For instance for Vy there is this blog post: https://blogg.bekk.no/using-elm-at-vy-e028b11179eb
https://blogg.bekk.no/introducing-bekk-christmas-ad01660ccadf
Is there a rule against authors posting their own content? It's not some grand conspiracy, it's just an christmas campaign by a company that has asked their employees to write about topics that interest them, and those articles are shared during advent. On the 25th it'll presumably go quiet again until December 1st 2020.
We are genuinely not trying to spam anyone, just in the mood of sharing knowledge through small daily blog posts in 12 different areas throughout December :) You can see the 12 advent calendars at https://bekk.christmas and a blog post introducing the concept here https://blogg.bekk.no/introducing-bekk-christmas-ad01660ccadf
This article is a part of a larger series that tries to figure out how Elm's runtime performance can be improved: https://blogg.bekk.no/successes-and-failures-in-optimizing-elms-runtime-performance-c8dc88f4e623
I'm the author of the articles, btw.