wait. We should speak the same kind of comparisons. if we do a comparison to languages like haskell, idris, coq i m not sure we are targeting the hearth of the industry. They do not represent solarge% of code written code everyday that GO is made to replace.
My understanding is that go would like to be at the point of junction of those two worlds, academic / enterprise. In that regards, we should compare it to java / php / ruby / python / d / c / c++. For those which are language designers, comparing the language to such things like haskell is made in an attempt to make the best language design (small ego trip here ?), not the most practical, effective IRL language. IRL, we need both, a good language design to serve an efficient programming experience. But, as everything, too much this or that, this is not good. I don t think it s appropriate to compare GO to Js in browser, but this is very personal taste related. Also, JS as a backend language has been overused, imho, it serves great purpose for stuff like p2p/cli (i m still waiting to see a 100% go project like this one https://github.com/mafintosh/hypervision), but it sounds unreasonable for a large web app backend, in so many ways. I like to think JS/GO complete each other. What i think more interesting in your post is that quote, > Go is an extremely innovative language I would not say that, stricktly speaking about the language, not the environment it provides (test, compile ect). I d rather say, Go was designed to implement for real some/lots of innovations, since then, I would say it is stuck in its compatibility promise. Don t you feel this way ? Note, im not criticizing, its a fact which i think does not help its innovative designers to innovate =) On that topic js has been able to find its way to test/try/evict|keep with projects like babel. Not claiming here that babel is 100% perfect, just saying, in practice they made that and it was useful to the language changes. Anyways, IRL, i simply think we don t read often enough that *the language is great*, but its so easy to find threads of 100 messages about such proven-useless-thing like semicolons. you know, like a person, it needs to be told it is great from time to time, it participates to its well being, in my very humble opinion. On Friday, March 17, 2017 at 12:21:46 AM UTC+1, Jesper Louis Andersen wrote: > > I think this is too premature to make this call. Javascript is a language > with no type system and it is relying a lot on runtime behavior. Yet, it > was a "language of the future" when it was created and I don't think it was > envisioned to become as big as it got. Attempts are replacing it are going > slowly because a language has momentum. > > Go is an extremely innovative language. The designers made a choice: keep > the language rather simple and conservative, but innovate in other areas of > language design: fast compilation speeds, fast linking, tooling, loose > coupling, and so on. Every language feature runs the danger of becoming a > long term liability, so adding those requires a lot of careful thought. > Keeping a language small also requires innovation and lots of hard > cost/benefit trade-offs. > > I think Go was right in requiring a garbage collector, rather than going > the C/C++ way of manually managing memory, the Swift way of using ARC, or > the Rust way of using ownership, borrowing and lifetimes. Concurrency > demands a sacrifice---in this case that you have to free yourself from > thinking about freeing of memory. > > Haskell is a language which is far smaller than Go. But it allows so many > combinations of its feature set that the learning curve is rather steep. It > is not a priori clear that such a language is more destined to be one for > the future, save for perhaps a fact that functional programs tend to be > easier to formally verify. > > A language such as Idris has dependent types, which essentially means that > the world of types and the world of terms (programs) get merged into one > and you program both at the same time. Yet, there are some real hard > problems which are only being overcome now for these kinds of languages. > Many of the ideas toy with restricting turing completeness in different > ways, often by limiting oneself to programs which are provably terminating. > Perhaps they are the languages of the future? > > Coq is a proof assistant. Not only can you write mathematics in such a > system, but you can write programs which you can then prove have certain > desirable properties. A good example is that you can prove the invariants > of a Red-Black search tree are maintained for your operations. The machine > is able to help you with your proof as you work through it (therein > "assistant"). But once the program is written, Coq can *extract* that > program to OCaml, Haskell, and so on. This has been used in a > tour-de-force, the CompCert project: Take the C specification. Formalize a > CPU. Now write a compiler, in Coq, from C to that CPU (backends are x86-64, > PPC, etc). This compiler is formally verified: the assembly is proven to > run with the same semantics as the input C code. If on the receiving end of > medical equipment, I know what compiler I would prefer were used! > > My intuition is that politics and social structure is likely to guide what > becomes the language of the future. Self-driving cars could spike political > interest in software liability. IoT (which I often jokingly call the > Internet of Terror) and the lack of security could drive stricter rules for > what we are allowed to connect to the internet. If we start demanding more > correctness in our programs, systems more amenable to formal methods are > likely to win. But if the current trend continues, such change is unlikely. > There is a monster in the closet called Machine Learning. The program > doesn't have to be perfect. It simply has to beat the average human. If > that can be done with a set of very large matrices and a simple piecewise > linear "simulation" of a neuron, then the language of the future isn't > symbolic at all, perhaps. > > > On Thu, Mar 16, 2017 at 11:05 PM <prade...@gmail.com <javascript:>> wrote: > >> A language with such a "simple" type system, which rely that much on >> runtime behavior is hardly a language of the future. But Go might be a blue >> print for what language of the futures will have to provide in terms of >> developer experience. Go is too divisive to get widely adopted or to >> replace any "enterprise" language. >> >> >> Le jeudi 16 mars 2017 20:27:24 UTC+1, mhh...@gmail.com a écrit : >>> >>> Did not need such analysis to claim such assertion, >>> A language that does not bloat its users with semi colon (one for you >>> https://groups.google.com/forum/#!topic/golang-nuts/rzLzp_Z74ik%5B1-25%5D), >>> >>> parenthesis where useless, >>> with automatic formatting, >>> tries to solve "les querelles de clocher", >>> is cross compiling by default >>> ect ect ect ect (we could add 100 more like this) >>> >>> definitely is a language of the future. >>> >>> I feel so bad returning to older languages. >>> >>> Simply said, GO ROCKS >>> >>> On Thursday, March 16, 2017 at 3:14:15 PM UTC+1, Art Mellor wrote: >>>> >>>> Interesting/fun article where Erik Bernhardsson analyzes data about >>>> moving from one programming language to another >>>> >>>> https://erikbern.com/2017/03/15/the-eigenvector-of-why-we-moved-from-language-x-to-language-y.html >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
