Totally agree. Go is a superb systems language. But I wouldn't use it for a CRUD web app, nor for quasi-exploratory data pipelines, which is where IMO such generic functional combinators are clutch. It is however awesome when you've nailed down the data pipeline and you want to get a big speed improvement in a fraction of the time required to build out in C/C++.
What makes Go a good "systems language"? Is it because it's fast? What about Java, Scala, Clojure, Haskell, C#, F#, Scheme, Ocaml, etc, which all have performance (speed of execution) similar to Go, are they good "systems languages" as well?
If it's not speed of execution then what makes Go a good systems language? The ability to fiddle bits? A small runtime?
I would use it for a CRUD app and I wish it had features that would support that. As an open-language, this input should be considered (alongside the input of the maintainers and other users of the language). I believe the top-comment here was saying that this conversation shouldn't be side-lined.
Comments
Totally agree. Go is a superb systems language. But I wouldn't use it for a CRUD web app, nor for quasi-exploratory data pipelines, which is where IMO such generic functional combinators are clutch. It is however awesome when you've nailed down the data pipeline and you want to get a big speed improvement in a fraction of the time required to build out in C/C++.
What makes Go a good "systems language"? Is it because it's fast? What about Java, Scala, Clojure, Haskell, C#, F#, Scheme, Ocaml, etc, which all have performance (speed of execution) similar to Go, are they good "systems languages" as well?
If it's not speed of execution then what makes Go a good systems language? The ability to fiddle bits? A small runtime?
One thing is gochannels and the lightweight concurrency primitives.
Java, Scala, Clojure, Haskell, C#, F#, Scheme (do Rackets Places count?) all have their equivalents.
I would use it for a CRUD app and I wish it had features that would support that. As an open-language, this input should be considered (alongside the input of the maintainers and other users of the language). I believe the top-comment here was saying that this conversation shouldn't be side-lined.