What will be the legacy of Go?

http://dave.cheney.net/2015/11/15/the-legacy-of-go

by clessg • 11 years ago

101 107 11 years ago

dave.cheney.net

threeseed• 11 years 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• 11 years 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• 11 years 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.

ridiculous_fish• 11 years 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.

aikah• 11 years 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• 11 years ago

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 (?)

throwa990323249• 11 years 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.

vorg2• 11 years 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• 11 years 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.

nnutter2• 11 years ago

Go on Android http://talks.golang.org/2014/gothamgo-android.slide#1

pcunite• 11 years ago

Was it not reborn as Delphi? It was always Pascal. But I do agree, a non-visual service lang is probably a thing.

pjmlp13• 11 years ago

"how do I write a Windows program in this?"

Turbo Pascal for Windows, it had two releases 1.0 and 1.5, introduced the Object Windows Library later adopted by Turbo and Borland C++ for Windows.

It was replaced by Delphi with its Visual Control Library afterwards.

The problem was Borland management going nuts and no having a proper version for UNIX systems, which were gaining market share back then.

x0x0• 11 years ago

I think Go was google's alternative to buying Java, and/or Sun. As such, and given the recent concerns about Oracle's investments in the jvm (they laid off some java evangelists, and it's not at all clear to me why Oracle will be willing to fund jvm development), I think Go is going to be with us a very long time.

nnutter2• 11 years ago

Seems like FUD. 549 contributors according to GitHub. Open Source. Fork it. https://github.com/golang/go

xienze• 11 years ago

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.

Ehh... to be fair, I don't ever recall JavaFX and Dart getting so much organic "love" from developers. Go has at least made it past the point where said corporation is trying to make it a "thing", which is more than you can say about JavaFX and Dart.

pjmlp13• 11 years ago

I don't get what you are speaking about JavaFX.

It has replaced Swing as the official Java UI framework, all new UI features since Java 7 is being done in JavaFX.

Swing joined AWT as legacy code and bug fixes only.

skybrian• 11 years ago

Dart won't be built into Chrome, but dart2js works fine and usage at Google is increasing. Saying that Google "pulled support" isn't accurate.

lechuga• 11 years 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• 11 years 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.

forrestthewoods2• 11 years ago

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

radlad• 11 years ago

Care to explain why? This comment doesn't really say anything without an explanation.

forrestthewoods2• 11 years 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.

Recoveringhobo• 11 years 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• 11 years 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.)

pjmlp13• 11 years ago

Co-routines go back to Modula-2 (1978) and first COBOL optimizing compilers, Go didn't invent anything there.

frik4• 11 years ago

More recent inspirations: Win16/32 API has "Fibers" (used in WinWord), Lua has coroutines.

xiaoma• 11 years 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.

nickpsecurity8• 11 years 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

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.

gajjanag4• 11 years 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_...). 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.

Manishearth• 11 years ago

I can reason that the unsafe section has zero side effects outside of it

There are basically a core set of invariants that `unsafe` code must hold, and you can reason about it in those terms.

http://doc.rust-lang.org/nightly/nomicon/ talks a lot about this.

pcwalton2• 11 years ago

Focusing on Rust "unsafe" as some sort of way to ding its safety drives me crazy.

"unsafe" blocks in Rust is designed to be just like the compiler backend. We could have built things like Vec::new and vector indexing into the code generator, like Go or Java did. Then we wouldn't need the "unsafe" construct in the language (except to interface with kernel32.dll and/or syscalls). But that would make our lives harder for absolutely no extra safety gain. It's precisely the same thing as implementing things in the compiler backend, but it's safer than doing that, because we get to write code in a stronger type system than that of raw LLVM.

More succinctly: What makes the compiler backend safe while unsafe blocks are not? Can you name one thing that makes the compiler backend safer than code written in unsafe blocks?

nickpsecurity8• 11 years ago

"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. "

See, even that is misleading. The C specs have a ridiculous amount of undefined behavior and dark corners that can mess up developers. C++ probably does too more than I know. Their specs are actually so hard to formalize that people got Master's degrees, etc for pulling off part of that after decades of people trying. Whereas, many LISP's, ML's, and Wirth languages (eg Oberon/Modula lines) were described quite succinctly and including code. C & C++ specs are so horrible you can't even be sure what your code will do even if you write it to spec. !?

"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."

Others are addressing the point about Rust, which I'm ignorant about. What I can say is the generic rule on this issue. Most safe-by-default type languages wrap unsafe behavior behind function calls which still have type/interface checks. If that code behaves correctly, you get to leverage type system of safer language to make sure it works with the rest correctly. If it behaves incorrectly, one of two things happen: local damage where an incorrect result is obtained; application crash or hack. You wouldn't be using the unsafe code unless you thought it was necessary. So, doing safe + a little unsafe adds no risk vs going all unsafe in C, etc. Yet, it counters many risks. So, it's a good tradeoff even if unsafe code can have unpredictable effects on the rest.

Note that one can attempt to further mitigate without sandboxing by writing that unsafe code in a way amendable to static analysis or through testing of what it does. One can use something like Frama-C or SPARK Ada to model that one part to make it as bulletproof as possible. Only then include that algorithm into the otherwise safe program. And again wrapped with interface safety to counter even more risk.

C and C++ will always have an advantage over sheer momentum. However, there's always alternatives available that lack the problems of the above. They don't have to have the GC, portability, and size issues as Ada and Wirth's languages always showed. I mean, Wirth's Pascal/P was safer than C, efficient (although not max), and more portable given backend was simple, stack-machine anyone could implement. It was ported to 70+ architectures that differed a lot. The ports of Oberon compiler and OS to each new hardware took 1-2 undergrads under 2 years each time due to good design, modularity, and simplicity. What kind of effort have the UNIX's and C compilers took to put on each new architecture? ;)

Anyway, I agree if you want max contributions by existing programmers that C is likely best choice for OS development. Or at least the kernel of something like JX Operating System or VerveOS where rest is done safely. If you want best results, then avoiding C and using safer alternatives is best. You'll get so much more done w/ higher robustness in the time you save debugging. :)

pjmlp13• 11 years ago

Yeah, here is some additional info:

This is the typical C fanboism that sells C as the AD of systems programming.

Here are some other languages, for those that don't want to go through the article, about well known systems programming languages before C had any relevance outside AT&T.

- Algol on B5000 (1961)

- PL/I on System 360 (1964)

- PL/M on CP/M and AS/400 firmware (1972)

- Mesa on Xerox PARC Alto (1970)

- XPL on Sytem/360 (1971)

- HAL/S on AP-101 (1970)

- JOVIAL on 465L (1970)

- CPL on Titan and Atlas (1963)

- BCPL on IBM 7094 (1970)

But lets pretend C (1972) was the first one.

Interesting enough, just like they did with Go, C dropped most of the features used by the other systems programming languages of the day.

drivingmenuts3• 11 years ago

Most of those languages are as close to dead and buried as can be, except maybe on an academic's or aging hobbyist's bookshelf, or perhaps running on a ghost machine in a forgotten room at a large corporation or government office. The majority of people who programmed in those languages in their heydays have long since retired.

Sure, there were languages before C that did Important Things, but C works as a starting point of discussion because most programmers today have at least heard of it, even if they never use it.

Aside from NASA or JPL, who would even start a new project in any of those languages, because of one important paradigm?

nickpsecurity8• 11 years ago

Appreciate the list. I'll incorporate this into my links in future somehow. You should leave off CPL in the future as it was designed but never implemented. The inability of EDSAC to compile it was very reason BCPL and later C existed.

agumonkey3• 11 years ago

Very much appreciated Olve Maudal talk about C origins. Thanks a flot !

nickpsecurity8• 11 years ago

Very welcome and good to see the info getting well-received. Can't get rid of support for this monstrosity (C) until people see exactly what and why it is.

jwatte2• 11 years ago

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

catnaroek• 11 years 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• 11 years 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.

frik4• 11 years 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.

pjmlp13• 11 years 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.

frik4• 11 years 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

estava• 11 years ago

One advantage of Go is that more code is dependent on the network which is where Go shines at. Go looks like a hammer when the network looks like a nail. For example, Go was one of the first to start adding HTTP2 support. If Go is always there for network tools, it will creep into areas that perhaps many would not have foreseen like security systems that were previously done in C and C++.

anentropic• 11 years ago

Docker

What will be the legacy of Go?

Related Stories