Fair enough, it might be my own view on what I'd use Julia in a production environment clouding my interpretation of the scope of the text, especially as the au

Fair enough, it might be my own view on what I'd use Julia in a production environment clouding my interpretation of the scope of the text, especially as the author defines this as his area at the start and says how it's what Julia shines at. Julia being an acceptable ("production-ready") language means that whenever my problem hit the areas that Julia shines, it becomes a valid candidate to evaluate considering all pros and cons. And while right now I wouldn't recommend Julia for that web domain unless you also need it's number crunching features (which is more than just scientific computing, I work with large finance systems and there is definitely a lot of that stuff), I do think it's more of a library/community problem than a language problem. The language is well equipped to handle it (easy to use from a scripting perspective, easy parallelism, fast after warm-up, allows for clean abstractions to create sophisticated web frameworks, the mentioned easy FFI), what it lacks is the coverage and maturity of the tools and support (so I don't feel like I'm at a risk at any point that I need to do some integration, such as integrating with Kafka or any other systems, without having to write my own solution or integrating multiple languages at every step). That's different from systems programming, embedded, game development and even GUI development (at least until smaller binaries with less warm-up) right now. Even with good library it will not be competitive with the languages that already claim those domains. Julia is a general purpose language already and more than a matlab substitute, it does not need to be good at everything (and it shouldn't try), but I don't think it should restrict the scope too much either.