Re:Why Developers Never Use State Machines (2011)
by oblio on Tuesday February 27, 2018 @06:08AM
(#16472493)
> It's less about a language per se but rather about availability of libraries and how mature / well-built their API is.
In the real world, those matter just as much as the language. They usually matter even more :)
Look at what Rust is doing - I think at least half of their effort is spent towards building up a large collection of high quality, well maintained (i.e. feature requests implemented, bugs fixed quickly) and well documented libraries.
Re:Why Developers Never Use State Machines (2011)
by vbezhenar on Tuesday February 27, 2018 @07:46AM
(#16472900)
I agree. For me what matters most is language implementation (compiler/VM quality, GC quality, etc) and important libraries (and whether they are good). Language itself is not very important. I can write boilerplate, but I can't write GC implementation. So while I don't like Go language, for example, its implementation is very good and I can live with it.
Re:Why Developers Never Use State Machines (2011)
by perlgeek on Tuesday February 27, 2018 @07:04AM
(#16472715)
> Haskell code for that looks quite nice as well - however, it's less about a language per se but rather about availability of libraries and how mature / well-built their API is.
That might be the case, but you simply never see tutorials for writing a CRUD-like web application in Haskell. Maybe they exist, but they don't seem to show up very often here or on reddit or whatever.
Re:Why Developers Never Use State Machines (2011)
by dllthomas on Tuesday February 27, 2018 @09:39AM
(#16473641)
For quite a few FP languages the ecosystem is there and you can do all these problem domains nicely, they just tend to be skipped in tutorials as they rely on non-core third party libraries (sometimes with multiple nice but very different alternatives). Perhaps a "batteries-included" stance of Ruby(+Rails) and Python would simplify that, but it's more of a political issue.