1. 16

According to you what are the requirements for a language to be ready to go to production?

I gathered the following requirements:

  • Editor and IDE support,
  • Package manager (pip, yarn, cabal, quicklisp, akku, …),
  • Package index (e.g. pypi, cpan, …),
  • Test framework with coverage and profiling,
  • Step debugger and inspector,
  • Logging system and integration with existing monitoring systems (syslog, statsd, prometheus, ELK, sentry, rollbar),

Outside “an army of developer” what makes a programming language viable for production?

  1. 11

    I like Go’s version of this: they declared it 1.0 when they were ready to guarantee backwards compatibility and really work for it. They didn’t have a lot of things on your list, and it clearly wasn’t a problem.

    What Go had was that compatibility guarantee and features people wanted.

    1. 3

      I think this is key. Dependency management years or decades down the line is a much bigger concern in production systems than any fleeting technical problem (it’s always possible to roll your own solution, in any language, for any problem the language doesn’t solve for you) & the biggest factor in dependency management is whether or not new code and old code can coexist. Fears about old code getting broken by upgrades is why a lot of big companies are still running linux 2.4 kernels, standardizing on python 1.x, or maintaining OS/360 machines decades after nobody in their right minds would use that tech for new projects.

      Where I work, there was a push for experiments in new features to be done in julia because julia was a lot better suited to our problems (doing simple statistics on large data sets in close to real time, where plenty of hardware was potentially available) than the languages we were using (a mix of java and perl). When julia announced that they were about to decide on a 1.0 standard, this was very exciting, because it meant we could write production code in julia that wasn’t tied to a particular minor version of the language & theoretically there could be independent implementations of the compiler that adhere to the spec.

      On that subject – number of independent implementations is sometimes a concern. Occasionally, with a language where there’s only one usable implementation, the developers will make a change that makes existing code infeasible (either broken or too slow for your use case) and you’ll need to decide between rewriting your code & keeping an old version of the language (which, over enough time, eventually becomes maintaining a fork of the old version, as builds eventually break against newer versions of dependency libraries and such). When there are multiple independent implementations, it’s less likely that they will all break your code in the same way at the same time, so you have the additional option of switching to a different implementation. This is less common than one would hope, though – there aren’t even very many serious C compilers anymore, there never were very many serious fully-independent implementations of javascript or perl, the attempts at alternative impementations of C# and Java have fallen out of date with the flagship implementations, and in a strange twist of fate, python leads the pack here (with the odd company of prolog, smalltalk, and apl in tow)!

      1. 1

        Yeah I’m pretty sure Rust was the same way. They declared 1.0 when they felt like they weren’t going to break anything. I’m pretty sure they knew at the time that major features like async/await would be added after 1.0.

        I think Go had:

        • editor support but no IDE spuport.
        • no package manager. Did the “go” tool even exist at 1.0?
        • no package index
        • good testing tools
        • no debugger
        • some integration with Google monitoring tools but probably nothing external

        And very importantly they had good docs.

        I think a good test of 1.0 is you can write good docs with a straight face. Explaining a language helps debug the corners.

        Despite all those missing things, people started using it anyway. So there are two different questions: 1.0 and “production ready”. But I would say there will be early adopters who use a 1.0 in production (and some even before that!)

      2. 5

        If it works for you, it works for you, but… I like the “Boring Technology”, not about tunnel-drilling but software development, and a good piece of advice floating around was to try and avoid languages under a decade or so old. Which personally has alwasy seemed a solid piece of advice, stay on the safe side.

        1. 4

          One important meta-point: the bar for new languages is only going to rise over time.

          I see at least two responses pointing to C/C++ not having package managers. But those languages came into existence a long time ago, found a big niche, and have momentum. The fact that they don’t have package managers doesn’t mean a new language can get momentum without one, any more than JavaScript’s prominence means you’ll get a warm reception if your language is full of strange implicit coercions.

          1. 1

            Programming language package managers are actively harmful. They promote the kind of absurdity you see wherever they exist. Look at Cargo and NPM. Hundreds or thousands of dependencies for very simple programs.

          2. 4

            Most of the decades old languages fail one or even most of those criteria. They’ve still been used in production.

            Many years ago I wrote Java with Notepad.exe - it worked. Test frameworks are also a bit overrated, imho - you can get very far with a few asserts and a bit ouf your own glue code/mini testing “framework”.

            C and C++ are still widely used without a package manager.

            Debuggers are helpful, but printf debugging still works for some people.

            That said, I’d say your list is a good starting point of what a modern language should strive to provide :)

            But in the end, nothing of this really matters. The code must be able to run bug-free and you need a team able to fix bugs and security stuff in short time. If you compile it, the binary must be fit for production, if you interpret, your interpreter must work (no memory leaks, no crashes, etc.pp) Those are my hard criteria, the tooling is just a bonus. Important, but not mandatory.

            1. 3

              Few of the things mentioned here actually pertain to the language itself, and most are ecosystem related.

              Assuming the following are met for me, I could build an ecosystem around it as needed to support a production system:

              • Are language features stable and documented? Does the language team have enough funding and contributors to be around for the foreseeable future?
              • Can we generate binaries for all target platforms? For interpreted languages, does its interpreter run on all target platforms? Does the compiler or interpreter generate reasonable error messages?
              • Can I interface it with other languages? In particular, calling C with a FFI. If I can write code which calls C, I can do everything realistically that I need to do.
              • If I’m writing a library, can I allow other languages to call my code?
              1. 3

                A language is viable for production as soon as someone is crazy enough to put it there, and commit to keeping it there.

                A lot depends on where “production” is. Is it something you put on your home server? An important piece of infrastructure at home, but if anything breaks or goes down, nothing really serious happens. It’s still “production”, though. Putting something on thousands of on-premise devices that are never going to be updated is another end of the production spectrum, with very different requirements.

                Mind you, I’ve put immature languages onto both, with great success.

                1. 3

                  I don’t think this is a binary decision, I think it’s a spectrum of risks. Some teams and some kinds of projects will be more tolerant of risk while others will be risk-averse and only jump on board once there are people with operational experience available to guide.

                  1. 3

                    Too big a question to have a general answer. Note that some very large and popular languages still don’t have some of the listed requirements. I’m not sure why you would call out logging systems specifically at this level either - there are hundreds of features at this level that most would consider desirable for production software.

                    I’m sure a bunch of companies have created DSLs for various purposes that are probably in production, and solve a problem for them, despite having none of those, and barely even being a real language at all.

                    Meanwhile, I don’t think C++ has a package manager or index, and well that’s huge. And what does “IDE Support” mean? Any made-up language can be opened up in Sublime Text or something. If it means useful auto-complete, most dynamic languages, including Javascript, Python, Ruby, etc, still don’t really have that and pretty much fundamentally can’t.

                    1. 3

                      Outside “an army of developer” what makes a programming language viable for production

                      Viable for production or ready for production? There are probably a lot of languages that are ready for production, but not really viable. Language ecosystems are viable if income minus cost is larger than other language ecosystems. Eg. Java may be boring, but for a lot of business logic it is the most viable language for production, because there are a lot of programmers available, which drives cost down. Also, onboarding of new developers is relatively inexpensive.

                      Betting on less mainstream languages can be useful from this perspective. If you can be more productive in some specific domain with a language that is not mainstream, that can be a competitive advantage. Even though the cost may be higher, being at an advantage could also increase income. If you can be five times more productive, because the language fits the domain, who cares that there is no IDE support yet or no package index?

                      1. 2

                        What is production? :)

                        A package manager would be largely irrelevant for a language that targets embedded platforms. OR it would have different requirements than “normal”, e.g. support for managing multiple cross-versions of the same library in a sane way.

                        Step debugger in the usual sense is not applicable to logic programming.

                        1. 2

                          One factor in this equation is that most of the “standard” languages seem to have recently started evolving much more rapidly than they ever have in the past. We seem to be going through a bit of a paradigm shift in (at least popular) language design, and the “safe”, “boring” languages are keen to this.

                          This doesn’t make off the beaten path languages worse, but it does mean that the difference between your favorite pet language, and say, Java 13, is not as large.

                          1. 1

                            None of those things are necessary except debugger support. Some of them are actively harmful, like IDE support and package management.

                            1. 2

                              Huh, why is IDE support actively harmful?

                              1. 4

                                IDE support encourages people to take an approach to programming where they don’t really know what’s going on and they don’t read any documentation. People that use IDEs tend to be the same people that demand ‘self-documenting APIs’. And by ‘self-documenting APIs’ they mean that if they roll their face on their keyboard and press ‘tab’ a few times they expect their auto-completing IDE to write correct code for them.

                                If by ‘IDE support’ you mean syntax highlighting support in the most common text editors, then that’s obviously completely fine. If you mean automatic refactoring tools, code generation, automatic importing, etc. then it’s not.

                                You shouldn’t need a program other than the compiler to generate code for you in any programming language. If you do, that indicates an issue with the language that should be fixed through additional syntactic sugar, compile time code generation facilities, macros, etc.

                                1. 3

                                  I still don’t see why anything you mentioned is actively harmful. Why would auto-completion or refactoring tools be harmful to anything? Do you really think it makes developers dumber?

                                  1. 0

                                    No, I don’t think it makes individual developers dumber. I think it allows already dumb people to become developers.

                            2. 1

                              For me, none of those things matter. A language is ready for production when the language is ready. Frequently it’s language features, language performance, language bugs, language warnings/errors, documentation, interop, targets that drive my decision. Editor support is nice, debugging is nice, everything else is bells and whistles imho.

                              1. 1

                                I’d say that none of these are actually required.

                                • C and C++ were in production long before package managers existed (and they still don’t have a major one).
                                • Dynamic languages usually have a poor IDE story, and yet are used in prod.
                                • If it has print, it has debugging and logging ;)

                                Major requirement may be trust that the language is going to last, it’s going to be supported, it’s going to have developers interested in it in 3/5/10/20 years time.

                                1. 1

                                  For me, an HTTP client is needed. something beyond sockets. Even if its only HTTP 1.1 with no HTTPS, it needs something. Alternatively cURL bindings.