Threads for ZachDevelop
-
After looking for pro/cons in Elm and ReamsonML, my final point was that although Elm has a great pattern and offer simplicity, the interop with JS to import any external library is not fitting the need that I have.
If I ever need to write apps without JS interoperability, then elm would be great, but for now, the ecosystem not here yet.
-
-
It’s not really that odd, when it fits into the Elm model of the world: I suggest listening to this podcast, which goes over why things in Elm are the way they are: https://elmtown.audio/99e18f41
-
I think the vision put forth by Evan sounds like a great thing to strive for. However, as he says, these things are going to take years to happen.
I think we are seeing the tension between building out this grand vision were everything has an ideal interface, and people using it to ship features today. It seems that recently, there has been more and more negative chatter about the limitations and issues of the language around this tension.
Not having small patches to fix things like the issue mentioned in the linked post is probably one of larger concerns. Users of the language can make a hotfix and push it to prod in minutes, but issues in language aren’t patched for a year. I know these aren’t the same thing, and actually doing things are never as easy as they sound, but this seems to be where the creator and user are at odds.
-
I think we are seeing the tension between building out this grand vision were everything has an ideal interface, and people using it to ship features today. It seems that recently, there has been more and more negative chatter about the limitations and issues of the language around this tension.
I think it’s OK, and even a good thing, if the power users of a language or library or whatever are persistently frustrated by the thing, if it means a stronger and more consistent story for new and intermediate users. They’re by far the larger and more important demographic. I don’t know a lot about Elm but I get the sense that this is the case.
-
Oh, certainly. Even having the userbase around to have these frustrations is a good thing.
It seems there are some growing pains going from a toy language no one really uses, to one that companies are built on. I guess we have yet to see how these concerns are handled.
-
-
-
-
-
We’re considering introducing this in at work, because apparently maintaining docs and client libs is too difficult for today’s engineers. Am curious what other lobsters have had as experiences.
My experiences have been pretty positive. At the very least, it’s way better than what most organizations use instead (i.e. nothing).
My first time using it, I was grafting it onto an existing API and was pleasantly surprised to see that it was expressive enough to bend to the existing functionality. All the stuff it enables is great – automated conformance testing being the big one, in my book.
Ah, neat. I already had been running boring documentation and updates (wiki ops, wheee), and am resistant to change if something works.
But, if it’s been working well for other folks, it’s worth investigating.
Have you thought about gRPC, or twirp at all? If the use-case is internal-facing systems then I think what a lot of people really want is RPC. Swagger seems great for external-facing systems, though.
(Disclaimer: I haven’t used any of the tools I just mentioned :D)
We have also used it quite a bit at work, getting the most benefit from automatic documentation of endpoints. The automatic client lib generation didn’t work very well for us, and hand written clients were our approach.
Depending on what your API is written in, you may have quite good support for generating pretty detailed docs.
Also, this opens the door for some kind of automated testing against the API, based on the Swagger definition, but, I never got around to doing that.
We use https://www.apibuilder.io/