22 ms·

What will be the legacy of Go?

101 points by clessg 11y ago

threeseed 11y ago
I think Go will ultimately be remembered for reaffirming the importance of single binary deployments. The world of deployments e.g. build scripts, containers, extravagant tools are all unnecessary with Go. And I suspect future languages will learn from this. The language itself not much. It doesn't offer anything new that Java 1.0 with Quasar doesn't already have.
- farrisbris 11y ago
  I think the single most important 'thing' go offers is his third point. The removal of the thread. The ability to very easily run multiple concurrent pieces of code cannot be understated. I have my grievances with go as i do with every other language, but what makes me more or less automatically start most new projects in go is that i know that at some point i will probably be sending the same http request to N servers or some variation of a similar task, and even if it can be made to work in any other language, the ease of which it is done in go keeps me coming back. As an aside i think the composition over inheritance argument deserves a mention. The io.Reader and io.Writer interfaces () and their close friends io.ReadCloser, io.ReadWriter etc) have completely transformed how i approach tasks that involve shifting data through a number of whatevers.
  - stingraycharles 11y ago
    It would be quite unfair to have the "removal of the thread" be a legacy of Go, given that this is not something Go invented.
    - sigzero 11y ago
      Well, to be fair, Go doesn't bring anything "new" to the table either.
      - eropple 11y ago
        Precisely this. While we're talking about what it popularizes, there's also the sense of epistemic closure that I've never seen to the extent that I do in the Go community. You're right in that it doesn't bring anything new to the table; that's its developers' intent, but its fans have tried to turn it into some kind of revelation. Which it's not, of course, it's Java 1.1 with a somewhat nicer syntax. And that's not a crime, it's not unforgivable--but it's also nothing special, and by god am I so very tired of its partisans holding it up as the best thing since sliced bread because they don't know what the rest of the world looks like. (This expressly acknowledges the--rather few, IMO--Go fans who do understand the rest of the world and use it for their own reasons; I think they're hurting themselves, but I respect the choice.)
  - ridiculous_fish 11y ago
    What do you mean by "removal of the thread?" Go is multithreaded and is vulnerable to classic thread-safety issues, like races and reentrancy.
    - gtremper 11y ago
      He's referring to interacting with goroutines rather than system threads directly.
      - eropple 11y ago
        Which Go neither invented nor seriously popularized, unless we are to rewrite history to ignore the actor systems in common use on both the CLR and the JVM (to say nothing of Erlang et al, but "popularized" rather rules that out) well before Go's public release. Unless the qualifier is "popularized among Ruby and Python people," and, well, sure, but the number of Prometheuses to bring fire to those folks is large and ever growing.
        hacknat 11y ago
        Go didn't invent co-routines, but the primitives of channels and the select statement that go along with them, while not ground breaking, amazingly simplify a lot of concurrency patterns that can get overly bloated and/or difficult to reason about in other languages. I have simply never seen another language that makes it as easy as Go does to reason about parallelism/concurrency (maybe Erlang).
        kasey_junk 11y ago
        This is an attitude I've encountered before & can't really get my head around. Channels are a really bad implementation of a queued message concurrency pattern that has been standard in other languages for years. The select pattern maps directly to any number of interupt style programming abstractions that are available in every language I've programmed in the last 15 years. Quite simply I find the go concurrency story primitive to the point of painful. I'd love to figure out why my opinion on that is so far outside the common refrain
- aikah 11y ago
  > The world of deployments e.g. build scripts, containers, extravagant tools are all unnecessary with Go. I'm not arguing that Go makes deployment easier but it doesn't make all these things unnecessary ,as a server is only one component of an app among many others. I'd like to see more languages supporting some sort of web-app packaging though( I know I can do something like this with python , i.e. bundle everything in a single executable). I think it is an elegant solution.
  - 0942v8653 11y ago
    https://github.com/GeertJohan/go.rice/ https://github.com/GeertJohan/go.rice/ lets you bundle resources into the executable. It's not part of the language but I don't think Python's is either (?)
    - pjmlp 11y ago
      Windows has been doing that since it exists. Also UNIX systems like Aix have support for it.
- throwa990323249 11y ago
  >The language itself not much. It doesn't offer anything new that Java 1.0 with Quasar doesn't already have. It offers lots of abstractions Java didn't/doesn't: Lots of concurrency features, Ad hoc interfaces, Closures, Stack resizing, Type switches, Multiple returned values, Slices.
vorg 11y ago
> Go is still young, with a long productive life ahead of it [...] compared to the number of people who will use Go during its lifetime, we are but a tiny fraction An assumption lurking in the last paragraph. Remember JavaFX and Dart, both languages backed by large corps who then pulled their support. Go could be at the peak of its popularity, about to tank. We don't know.
- JulianMorrison 11y ago
  I'm thinking of Turbo Pascal for DOS. It was very popular, and then it sank to obscurity almost overnight, basically because it didn't have any answer to "how do I write a Windows program in this?" Its niche had been eliminated. I don't think Go will vanish unless "network servers that run in text mode on unix" somehow stop being a thing. There is no Google product whose change of strategy could strand Go (unlike the others you name). If somehow all computing moves to phones and tablets, it could be stranded, but I can't imagine that happening.
  - nnutter 11y ago
    Go on Android http://talks.golang.org/2014/gothamgo-android.slide#1 http://talks.golang.org/2014/gothamgo-android.slide#1
    - pjmlp 11y ago
      Not supported by the Android team, so don't expect to see it here: http://developer.android.com/index.html http://developer.android.com/index.html http://developer.android.com/ndk/index.html http://developer.android.com/ndk/index.html
      - frik 11y ago
        It's still in its early days though from Google: https://github.com/golang/mobile https://github.com/golang/mobile https://github.com/golang/go/wiki/Mobile https://github.com/golang/go/wiki/Mobile
lechuga 11y ago
Minor nit re: Rails legacy. IMO a major reason it was so popular was because of Ruby. It's certainly not the right hammer for every nail but the syntax is one of the best to work with ever. Whenever I can find a project where writing a little Ruby makes sense I use it. Because I enjoy it :) While it's useful to me and dominates what I code in atm, I don't necessarily like writing Go. Better than C/C++, sure, but I wouldn't go so far as to say I enjoy it.
- vinceguidry 11y ago
  Have you tried Crystal? I used to think I loved Ruby for its syntax, until I tried Crystal, then I found out that Ruby's dynamic typing and the sublime object model are just as important, if not more important, than the syntax.
forrestthewoods 11y ago
I'm not sure Go will have a legacy in 50 years. If you gave me even odds I'd go with none.
- johnmaguire2013 11y ago
  Care to explain why? This comment doesn't really say anything without an explanation.
  - forrestthewoods 11y ago
    Most programming languages don't have a legacy. They're just forgotten. That's the default. So far I've not seen anything from Go to make me think it will be more than a footnote.
    - nzoschke 11y ago
      How about Docker and other tools in the container space? Go is a great systems language. The stdlib is through and handling IO and pipes is safe and fast. Amazon is using as the mission critical ecs-agent that orchestrates their container service. Perhaps containers will be forgotten too. But my guess is that we will be seeing some go binaries controlling very important parts of Linux and distributed systems in the far future.
      - Retra 11y ago
        Probably the most important feature of a systems language is the ability to predict and manage resource usage, and even though garbage collection is pretty good these days, it's still a feature that will turn a good number of people off from considering Go to be their go-to systems language. Some might not even consider it a systems language for having it, let alone a great one. It is mostly a feature of convenience, after all.
        jwatte 11y ago
        Not to mention the all too common bug to include a "defer" in a loop body. (Which often happens through "innocuous" refactoring.)
Recoveringhobo 11y ago
The legacy of Go will be a movement by many developers to statically typed, compiled languages after spending many years with Python, Ruby, and Javascript. Although it is not groundbreaking, it will continue to be used because it takes the ease of dynamically typed languages and gives you fast compilation.
petke 11y ago
"I mean, who doesn’t want to be simple ? And what better way to frame a debate as simple; good, complexity; obviously bad. Could we say then that simplicity will be Go’s lasting legacy ?" I think this misses the point. Complexity isn't bad. Only Incidental complexity is bad. Inherent complexity exists in the domain itself and is unavoidable. If this inherent complexity is not expressible by abstractions in the core language itself. Then it must be expressed in libraries, or user code, or in the way end-users configure and use the program. Go is interesting because it created abstractions for concurrency in the core language itself. Go is a more complex language because of it, but concurrent programs user code is less complex because of it. (On a side note C++17 is getting a more abstract version of go-routines. Thanks Go.)
- pjmlp 11y ago
  Co-routines go back to Modula-2 (1978) and first COBOL optimizing compilers, Go didn't invent anything there.
  - frik 11y ago
    More recent inspirations: Win16/32 API has "Fibers" (used in WinWord), Lua has coroutines.
xiaoma 11y ago
Perl: the language that showed us brevity. Despite all its various layers of madness, it made a generation of programmers more productive than they'd known was possible. Tasks that used to be major undertakings often boiled down to simple scripts. Python, Ruby and many other languages since have borrowed from and built upon the brevity that Perl first showed us and it's unlikely that people will ever go back to the verbosity that used to be common for text processing and sys admin tasks.
nickpsecurity 11y ago
The C section is so wrong it's unbelievable. Or why I created the Pastebin below. There were plenty of good languages before C, not just asm. C wasn't designed: a tweaked BCPL and B to work with PDP-11. C wasn't even meant to be portable. http://pastebin.com/UAQaWuWG http://pastebin.com/UAQaWuWG Helps to understand what it is exactly and then the rest (like ditching it) becomes more obvious. P-code was probably the first portable, assembly language with good results. Or LISP from the functional side.
- gajjanag 11y ago
  Thanks for the illuminating link. Nevertheless, I unfortunately do not see an easy solution in the near future that avoids C/C++ much as I would love to ditch them. Let us leave aside the question of legacy code and focus on future systems projects. General issue: C and C++ have an advantage in the sense that we understand their many problems well due to their long history, and they have formal specs that are far more carefully written than most others, where documentation is spotty and formal specs are often lacking. Example: I have not studied Rust closely, but it seems to me that there are sections that essentially must be placed under "unsafe" for performance or low level access. The oft-repeated claim is that it minimizes the surface, since it localizes the unsafe sections. I have not seen any hard, formal guarantees in either the spec or implementation as to what is precisely meant by this. I am very interested to know how I can reason that the unsafe section has zero side effects outside of it. Such a statement in general must be false, since the unsafe block clearly communicates with the rest of the program, else it is dead code. And if the interface is sandboxed (an imperfect solution), then it implies some kind of performance penalty across the barrier, implying additional cognitive load for a developer since he/she has to reason about the possible performance impacts for such things, among others like array bounds checks. Lastly, if the guarantee regarding the extent of the "unsafe" block is as complicated as I suspect it to be, the load is increased further. Of course, the load comment is really relevant to Rust vs C and not Rust vs C++. Specifics: 1. Go - garbage collector, large runtime/binary sizes, portability issues (AIX: https://groups.google.com/forum/#!topic/golang-nuts/IBi9wqn__FY https://groups.google.com/forum/#!topic/golang-nuts/IBi9wqn_...). 2. Rust - too new, general points above. 3. D - lacks the same energy as the above projects, so likely fares worse than the above. Furthermore, due to its closer ties to C++, its rather incremental nature resulted in a significant loss when C++11/C++14 came around. 4. Others - too many to list, focused on above due to their frequency on Hacker News.
jwatte 11y ago
As a slightly improved perl that really didn't change anything about languages.
catnaroek 11y ago
> I think a strong contender could be a lack of inheritance; Go took away subtypes. [emphasis mine] Go took away subtypes? News to me.
Animats 11y ago
Go was written to solve an internal problem at Google. Google needed efficient server side applications. Python was too slow, and C++ was too hard to write, too buggy, and a pain for string work. Google then developed good-quality libraries for all the things one needs for such applications. That made it an excellent language for server side work. As a language in general, Go is practical and mediocre. This may be a strength. Go lacks generics, and thus has to over-use introspection. In practice, while "interface{}" implies extra run-time work, it tends not to end up in compute bound code. (Two notable exceptions: sorting and database access.) So that turned out to be less of a hassle than expected. Also, from Google's internal perspective, they're mostly using their own data structures, and type-specific code may not be a big problem. Go's approach to concurrency hand-waves too much on the data sharing issue, and has soundness problems, but at least the language talks about concurrency and has some reasonable primitives. C and C++ don't even provide syntax for talking about concurrency.
frik 11y ago
C, C++ and Go are going strong. All operating system kernels we currently use are in C, as well as most low level drivers and libraries. Most PC client applications are in C++ including most video games. Common web servers are in C. They will be around for many more decades. Go already replaces Java and dotNet as a leaner more suitable server language in some companies. Nodejs and Go apps (+ JS in the web browser) replace older CRUD web apps written in Ruby/Python/Perl. Most languages will stay around for a long time, although a less popular for beginners. Java and dotNet will have a harder stand. On the one hand dynamic typed languages like Lua, Javascript and Hack/PHP with their JIT compilers are already (almost) as fast and allow developers to be more productive while still offering optional typing when/where speed matters. On the other hand new static compiled languages get more approachable (Go, Rust, Swift), are faster and use less memory. Paradigm shifts surfaced exotic languages and trends. So Erland/Elixir, Go, Nodejs and others are very popular for todays web services.
- pjmlp 11y ago
  Java and .NET have AOT compilers so compilation to native code is not a point. They have support for generics and FP like programming that Go will never get. Go will never have the access to the system resources on Windows and Windows Store like .NET does. Go will never had access to Android frameworks like Java does. Go doesn't have a UI toolkit like JavaFX and XAML. All companies selling IoT SDKs are paring Java with C stacks. Go doesn't have the IDE tooling support that Java and .NET enjoy. Java and .NET having a hard time? Only if one is living in a bubble.
  - frik 11y ago
    Some of your info is a bit outdated. Speaking of Go, it's appearently commonly used for server side services/apps. Well the same can be said for Java and C#/F#/VBNet. All applications we all use on the client side are C/C++/ObjectC/web apps. (exceptions are maybe Eclipse/IntelliJ, mind that Visual Studio is C++). Java on Android is an exception for legacy reasons (Google bought the Android company; and we pay the price buy using 2x-4x as powerful hardware (CPU cores & memory) comparing to iPhone to get similar UX & latency). Even the Win10 startmenu is still a C++ application for performance reasons. AOT is helpful for certain execution paths like JIT and isn't magic. Even the Win8/10 calculator app has a loading splash screen, the FirefoxOS calc app starts faster. XML based UI languages work, but aren't that great (e.g. resizing the Win10 startmenu isn't what I would call responsive design in comparision what we known from HTML5&CSS3). Beside that you wrote a good comment above: https://news.ycombinator.com/item?id=10568915 https://news.ycombinator.com/item?id=10568915
anentropic 11y ago
Docker

101 points by clessg 11y ago

I think Go will ultimately be remembered for reaffirming the importance of single binary deployments. The world of deployments e.g. build scripts, containers, extravagant tools are all unnecessary with Go. And I suspect future languages will learn from this. The language itself not much. It doesn't offer anything new that Java 1.0 with Quasar doesn't already have.

farrisbris 11y ago
I think the single most important 'thing' go offers is his third point. The removal of the thread. The ability to very easily run multiple concurrent pieces of code cannot be understated. I have my grievances with go as i do with every other language, but what makes me more or less automatically start most new projects in go is that i know that at some point i will probably be sending the same http request to N servers or some variation of a similar task, and even if it can be made to work in any other language, the ease of which it is done in go keeps me coming back. As an aside i think the composition over inheritance argument deserves a mention. The io.Reader and io.Writer interfaces () and their close friends io.ReadCloser, io.ReadWriter etc) have completely transformed how i approach tasks that involve shifting data through a number of whatevers.
- stingraycharles 11y ago
  It would be quite unfair to have the "removal of the thread" be a legacy of Go, given that this is not something Go invented.
  - sigzero 11y ago
    Well, to be fair, Go doesn't bring anything "new" to the table either.
    - eropple 11y ago
      Precisely this. While we're talking about what it popularizes, there's also the sense of epistemic closure that I've never seen to the extent that I do in the Go community. You're right in that it doesn't bring anything new to the table; that's its developers' intent, but its fans have tried to turn it into some kind of revelation. Which it's not, of course, it's Java 1.1 with a somewhat nicer syntax. And that's not a crime, it's not unforgivable--but it's also nothing special, and by god am I so very tired of its partisans holding it up as the best thing since sliced bread because they don't know what the rest of the world looks like. (This expressly acknowledges the--rather few, IMO--Go fans who do understand the rest of the world and use it for their own reasons; I think they're hurting themselves, but I respect the choice.)
- ridiculous_fish 11y ago
  What do you mean by "removal of the thread?" Go is multithreaded and is vulnerable to classic thread-safety issues, like races and reentrancy.
  - gtremper 11y ago
    He's referring to interacting with goroutines rather than system threads directly.
    - eropple 11y ago
      Which Go neither invented nor seriously popularized, unless we are to rewrite history to ignore the actor systems in common use on both the CLR and the JVM (to say nothing of Erlang et al, but "popularized" rather rules that out) well before Go's public release. Unless the qualifier is "popularized among Ruby and Python people," and, well, sure, but the number of Prometheuses to bring fire to those folks is large and ever growing.
      - hacknat 11y ago
        Go didn't invent co-routines, but the primitives of channels and the select statement that go along with them, while not ground breaking, amazingly simplify a lot of concurrency patterns that can get overly bloated and/or difficult to reason about in other languages. I have simply never seen another language that makes it as easy as Go does to reason about parallelism/concurrency (maybe Erlang).
        kasey_junk 11y ago
        This is an attitude I've encountered before & can't really get my head around. Channels are a really bad implementation of a queued message concurrency pattern that has been standard in other languages for years. The select pattern maps directly to any number of interupt style programming abstractions that are available in every language I've programmed in the last 15 years. Quite simply I find the go concurrency story primitive to the point of painful. I'd love to figure out why my opinion on that is so far outside the common refrain
aikah 11y ago
> The world of deployments e.g. build scripts, containers, extravagant tools are all unnecessary with Go. I'm not arguing that Go makes deployment easier but it doesn't make all these things unnecessary ,as a server is only one component of an app among many others. I'd like to see more languages supporting some sort of web-app packaging though( I know I can do something like this with python , i.e. bundle everything in a single executable). I think it is an elegant solution.
- 0942v8653 11y ago
  https://github.com/GeertJohan/go.rice/ https://github.com/GeertJohan/go.rice/ lets you bundle resources into the executable. It's not part of the language but I don't think Python's is either (?)
  - pjmlp 11y ago
    Windows has been doing that since it exists. Also UNIX systems like Aix have support for it.
throwa990323249 11y ago
>The language itself not much. It doesn't offer anything new that Java 1.0 with Quasar doesn't already have. It offers lots of abstractions Java didn't/doesn't: Lots of concurrency features, Ad hoc interfaces, Closures, Stack resizing, Type switches, Multiple returned values, Slices.

vorg 11y ago

> Go is still young, with a long productive life ahead of it [...] compared to the number of people who will use Go during its lifetime, we are but a tiny fraction An assumption lurking in the last paragraph. Remember JavaFX and Dart, both languages backed by large corps who then pulled their support. Go could be at the peak of its popularity, about to tank. We don't know.

JulianMorrison 11y ago
I'm thinking of Turbo Pascal for DOS. It was very popular, and then it sank to obscurity almost overnight, basically because it didn't have any answer to "how do I write a Windows program in this?" Its niche had been eliminated. I don't think Go will vanish unless "network servers that run in text mode on unix" somehow stop being a thing. There is no Google product whose change of strategy could strand Go (unlike the others you name). If somehow all computing moves to phones and tablets, it could be stranded, but I can't imagine that happening.
- nnutter 11y ago
  Go on Android http://talks.golang.org/2014/gothamgo-android.slide#1 http://talks.golang.org/2014/gothamgo-android.slide#1
  - pjmlp 11y ago
    Not supported by the Android team, so don't expect to see it here: http://developer.android.com/index.html http://developer.android.com/index.html http://developer.android.com/ndk/index.html http://developer.android.com/ndk/index.html
    - frik 11y ago
      It's still in its early days though from Google: https://github.com/golang/mobile https://github.com/golang/mobile https://github.com/golang/go/wiki/Mobile https://github.com/golang/go/wiki/Mobile

lechuga 11y ago

Minor nit re: Rails legacy. IMO a major reason it was so popular was because of Ruby. It's certainly not the right hammer for every nail but the syntax is one of the best to work with ever. Whenever I can find a project where writing a little Ruby makes sense I use it. Because I enjoy it :) While it's useful to me and dominates what I code in atm, I don't necessarily like writing Go. Better than C/C++, sure, but I wouldn't go so far as to say I enjoy it.

vinceguidry 11y ago
Have you tried Crystal? I used to think I loved Ruby for its syntax, until I tried Crystal, then I found out that Ruby's dynamic typing and the sublime object model are just as important, if not more important, than the syntax.

forrestthewoods 11y ago

I'm not sure Go will have a legacy in 50 years. If you gave me even odds I'd go with none.

johnmaguire2013 11y ago
Care to explain why? This comment doesn't really say anything without an explanation.
- forrestthewoods 11y ago
  Most programming languages don't have a legacy. They're just forgotten. That's the default. So far I've not seen anything from Go to make me think it will be more than a footnote.
  - nzoschke 11y ago
    How about Docker and other tools in the container space? Go is a great systems language. The stdlib is through and handling IO and pipes is safe and fast. Amazon is using as the mission critical ecs-agent that orchestrates their container service. Perhaps containers will be forgotten too. But my guess is that we will be seeing some go binaries controlling very important parts of Linux and distributed systems in the far future.
    - Retra 11y ago
      Probably the most important feature of a systems language is the ability to predict and manage resource usage, and even though garbage collection is pretty good these days, it's still a feature that will turn a good number of people off from considering Go to be their go-to systems language. Some might not even consider it a systems language for having it, let alone a great one. It is mostly a feature of convenience, after all.
      - jwatte 11y ago
        Not to mention the all too common bug to include a "defer" in a loop body. (Which often happens through "innocuous" refactoring.)

Recoveringhobo 11y ago

The legacy of Go will be a movement by many developers to statically typed, compiled languages after spending many years with Python, Ruby, and Javascript. Although it is not groundbreaking, it will continue to be used because it takes the ease of dynamically typed languages and gives you fast compilation.

petke 11y ago

"I mean, who doesn’t want to be simple ? And what better way to frame a debate as simple; good, complexity; obviously bad. Could we say then that simplicity will be Go’s lasting legacy ?" I think this misses the point. Complexity isn't bad. Only Incidental complexity is bad. Inherent complexity exists in the domain itself and is unavoidable. If this inherent complexity is not expressible by abstractions in the core language itself. Then it must be expressed in libraries, or user code, or in the way end-users configure and use the program. Go is interesting because it created abstractions for concurrency in the core language itself. Go is a more complex language because of it, but concurrent programs user code is less complex because of it. (On a side note C++17 is getting a more abstract version of go-routines. Thanks Go.)

pjmlp 11y ago
Co-routines go back to Modula-2 (1978) and first COBOL optimizing compilers, Go didn't invent anything there.
- frik 11y ago
  More recent inspirations: Win16/32 API has "Fibers" (used in WinWord), Lua has coroutines.

xiaoma 11y ago

Perl: the language that showed us brevity. Despite all its various layers of madness, it made a generation of programmers more productive than they'd known was possible. Tasks that used to be major undertakings often boiled down to simple scripts. Python, Ruby and many other languages since have borrowed from and built upon the brevity that Perl first showed us and it's unlikely that people will ever go back to the verbosity that used to be common for text processing and sys admin tasks.

nickpsecurity 11y ago

The C section is so wrong it's unbelievable. Or why I created the Pastebin below. There were plenty of good languages before C, not just asm. C wasn't designed: a tweaked BCPL and B to work with PDP-11. C wasn't even meant to be portable. http://pastebin.com/UAQaWuWG http://pastebin.com/UAQaWuWG Helps to understand what it is exactly and then the rest (like ditching it) becomes more obvious. P-code was probably the first portable, assembly language with good results. Or LISP from the functional side.

gajjanag 11y ago
Thanks for the illuminating link. Nevertheless, I unfortunately do not see an easy solution in the near future that avoids C/C++ much as I would love to ditch them. Let us leave aside the question of legacy code and focus on future systems projects. General issue: C and C++ have an advantage in the sense that we understand their many problems well due to their long history, and they have formal specs that are far more carefully written than most others, where documentation is spotty and formal specs are often lacking. Example: I have not studied Rust closely, but it seems to me that there are sections that essentially must be placed under "unsafe" for performance or low level access. The oft-repeated claim is that it minimizes the surface, since it localizes the unsafe sections. I have not seen any hard, formal guarantees in either the spec or implementation as to what is precisely meant by this. I am very interested to know how I can reason that the unsafe section has zero side effects outside of it. Such a statement in general must be false, since the unsafe block clearly communicates with the rest of the program, else it is dead code. And if the interface is sandboxed (an imperfect solution), then it implies some kind of performance penalty across the barrier, implying additional cognitive load for a developer since he/she has to reason about the possible performance impacts for such things, among others like array bounds checks. Lastly, if the guarantee regarding the extent of the "unsafe" block is as complicated as I suspect it to be, the load is increased further. Of course, the load comment is really relevant to Rust vs C and not Rust vs C++. Specifics: 1. Go - garbage collector, large runtime/binary sizes, portability issues (AIX: https://groups.google.com/forum/#!topic/golang-nuts/IBi9wqn__FY https://groups.google.com/forum/#!topic/golang-nuts/IBi9wqn_...). 2. Rust - too new, general points above. 3. D - lacks the same energy as the above projects, so likely fares worse than the above. Furthermore, due to its closer ties to C++, its rather incremental nature resulted in a significant loss when C++11/C++14 came around. 4. Others - too many to list, focused on above due to their frequency on Hacker News.

jwatte 11y ago

As a slightly improved perl that really didn't change anything about languages.

catnaroek 11y ago

> I think a strong contender could be a lack of inheritance; Go took away subtypes. [emphasis mine] Go took away subtypes? News to me.

Animats 11y ago

Go was written to solve an internal problem at Google. Google needed efficient server side applications. Python was too slow, and C++ was too hard to write, too buggy, and a pain for string work. Google then developed good-quality libraries for all the things one needs for such applications. That made it an excellent language for server side work. As a language in general, Go is practical and mediocre. This may be a strength. Go lacks generics, and thus has to over-use introspection. In practice, while "interface{}" implies extra run-time work, it tends not to end up in compute bound code. (Two notable exceptions: sorting and database access.) So that turned out to be less of a hassle than expected. Also, from Google's internal perspective, they're mostly using their own data structures, and type-specific code may not be a big problem. Go's approach to concurrency hand-waves too much on the data sharing issue, and has soundness problems, but at least the language talks about concurrency and has some reasonable primitives. C and C++ don't even provide syntax for talking about concurrency.

frik 11y ago

C, C++ and Go are going strong. All operating system kernels we currently use are in C, as well as most low level drivers and libraries. Most PC client applications are in C++ including most video games. Common web servers are in C. They will be around for many more decades. Go already replaces Java and dotNet as a leaner more suitable server language in some companies. Nodejs and Go apps (+ JS in the web browser) replace older CRUD web apps written in Ruby/Python/Perl. Most languages will stay around for a long time, although a less popular for beginners. Java and dotNet will have a harder stand. On the one hand dynamic typed languages like Lua, Javascript and Hack/PHP with their JIT compilers are already (almost) as fast and allow developers to be more productive while still offering optional typing when/where speed matters. On the other hand new static compiled languages get more approachable (Go, Rust, Swift), are faster and use less memory. Paradigm shifts surfaced exotic languages and trends. So Erland/Elixir, Go, Nodejs and others are very popular for todays web services.

pjmlp 11y ago
Java and .NET have AOT compilers so compilation to native code is not a point. They have support for generics and FP like programming that Go will never get. Go will never have the access to the system resources on Windows and Windows Store like .NET does. Go will never had access to Android frameworks like Java does. Go doesn't have a UI toolkit like JavaFX and XAML. All companies selling IoT SDKs are paring Java with C stacks. Go doesn't have the IDE tooling support that Java and .NET enjoy. Java and .NET having a hard time? Only if one is living in a bubble.
- frik 11y ago
  Some of your info is a bit outdated. Speaking of Go, it's appearently commonly used for server side services/apps. Well the same can be said for Java and C#/F#/VBNet. All applications we all use on the client side are C/C++/ObjectC/web apps. (exceptions are maybe Eclipse/IntelliJ, mind that Visual Studio is C++). Java on Android is an exception for legacy reasons (Google bought the Android company; and we pay the price buy using 2x-4x as powerful hardware (CPU cores & memory) comparing to iPhone to get similar UX & latency). Even the Win10 startmenu is still a C++ application for performance reasons. AOT is helpful for certain execution paths like JIT and isn't magic. Even the Win8/10 calculator app has a loading splash screen, the FirefoxOS calc app starts faster. XML based UI languages work, but aren't that great (e.g. resizing the Win10 startmenu isn't what I would call responsive design in comparision what we known from HTML5&CSS3). Beside that you wrote a good comment above: https://news.ycombinator.com/item?id=10568915 https://news.ycombinator.com/item?id=10568915

anentropic 11y ago

Docker