What will be the legacy of Go?
dave.cheney.net
dave.cheney.net
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.
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.
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.
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?
As pjmp said, article rewrites history by falsely claiming it was first HLL and that it was designed for portability. Neither were true. Additionally, competing languages (even on PDP-11!) had better maintainability, safety/security, and ability to code in the large. Many were portable with a few performing as well. BCPL was whatever could compile on a 1960's computer: nothing more. C was BCPL w/ structs and byte-orientation.
So, should we start with one of the better languages that resemble good languages of today to define attributes for systems programming? Or should we start with a semi-language that had no design, tons of problems, and all so it could compile on a 1960's machine? I think the former is the obvious choice. That those supporting the latter lie about C's origin, design, competition at the time, and so on to push it instead is... more disturbing.
Hence, me countering it readily.
"Aside from NASA or JPL, who would even start a new project in any of those languages, because of one important paradigm?"
There were repeatedly languages from that time available. The best for modern 3GL users were Wirth's line: industrial Pascal's, Modula-2, Modula-3 (especially), Oberon's. All were used to write OS's on minimal hardware with more readability and safety than C. Ada was rougher but safer and did the job too. LISP and ML derived languages only got better and better over time with Racket & Ocaml being the best today. I've even seen Ocaml used with an 8-bit runtime (!). There were also macro-assemblers that focused on semi-HLL's for ultra-efficiency and optimization. LLVM comes to mind. ;)
This stuff didn't fade into obscurity or only for obscure platforms. Good versions stayed around in industrial form for decades with little adoption while people tried building on something that wasn't designed for all its uses. Just compiling on an EDSAC in 1960's.
It's not an academic paper or even anything like.
It's. Notes. From. A. Presentation.
It's not the entire history of compiler languages and the lineages and branchings thereof which make Game of Thrones look like Jane and Dick.
If you're going to spend four sentences speaking about a core language, that is still in active use, that the audience will have heard of then C is a far better goto language than any of the ones listed above.
> All were used to write OS's on minimal hardware with more readability and safety than C.
Awesome. That decade abended years ago. They are no longer germane to a discussion at a conference in 2015, unless you're deep diving in language lineage.
Which the author clearly wasn't.
Edit: my bad. It was seven sentences.
"Before C there was assembly language...."
Is clearly a misinformation given to the audience.
Just because it wasn't a scientific paper doesn't make it less wrong.
The presenter has clearly driven all in the audience that don't know better, that C was the first high level systems information programming language.
Had he said that C was the systems programming language that won the hearts of the systems programmers we wouldn't be discussing this.
This misinformation has been happening since the mid-90.
That there were other languages between those two isn't important in the context of creating an example in one presentation and it for-sure is not factually wrong.
Just so we're absolutely crystal-clear here, how, exactly, would you have phrased the paragraph about C, without wandering off into the endless maze of computer language lineages, but keeping the same general intent, in the context of the remainder of the presentation?
One such example is the Burroughs B5000 system with Algol in 1961. This is just one example from many, available to anyone that cares to a little research.
I would have phrase it like this:
"Before C there were other systems programming languages, but for various reasons they lost to C and now it is widespread through the industry as we know it."
Followed by his note on how all computers in the room have their OSes coded in C.
However telling the truth is worthless, lost time and doesn't contribute to the learning of younger audiences.
Please excuse me, I have some books to burn.
That's totally wrong. The C philosophy and structure were almost 100% due to BCPL with minor changes. BCPL was portable by accident due to its simplicity. They just got rid of every good feature of a systems language to the point that the remainder, barely a language, could be put on about anything.
Thompson tweaked BCPL into B to make it work on his terrible PDP-7. That wouldn't work on a PDP-11 so more tweaks by Ritchie into C. That couldn't even handle UNIX alpha so that added structs. That's C 1.0. A year later, people started porting it because it was barely a language & could fit in their hardware. All that was in my link about its history from documents and people that made it.
"Before C there was assembly language"
Also wrong and contradicting his claim about HLL's before C. As pjmlp listed, there were numerous systems languages in production before C was designed. It's not like we made a huge leap of faith into structured HLL with C. We actually cut out maintenance, reliability, readability, integration, etc capabilities of existing languages (esp CPL) to iterate into C. And, later on with good hardware, people started adding many of those back because C was garbage that led to all kinds of problems.
We can certainly accept a need to learn C language and tooling for working with existing OS or app code. That's called legacy system effect. However, we should never push false justifications for that which detract from superior language design that would've enabled more robust, maintainable, productive development. We can accept both the what and the why of C at the same time.
As a side effect, more people might explore features of C alternatives to build the next, best, systems language. Wirth has been doing that for years. Ada still gets updated with one version able to prove absence of many, runtime errors at compile time. Clojure is showing LISP's advantages and it was once used for OS's w/ incredible flexibility + robustness. So on and so forth. Gotta counter the C disinformation and misinformation so enough people know why they should do the opposite of it so some [more] eventually will.
Note: There's also the value of removing inaccuracies in historical writings that have negative effects. Mere editing and revision. I hear that's important to some people, too.
Then, from that point, almost everything the author says about C's history, purpose, and effect were wrong. The only thing correct is everything in the room at the time was written in C [probably]. Which is actually meaningless given it's a historical accident far as the language itself goes.
So C's legacy is that most, mainstream OS's are written in C. The reason? Thompson and Ritchie used C for UNIX plus shared it with lots of people with poor hardware. That's it. It wasn't designed, it wasn't intentionally portable, it wasn't better than anything then or now... nothing really about C itself justified it sticking around. Purveying such myths makes people think it's technically superior and that we should keep investing into it and similar languages for system use. Very damaging myth. So, I counter it everywhere I see it.
"If you're going to spend four sentences speaking about a core language, that is still in active use, that the audience will have heard of then C is a far better goto language than any of the ones listed above."
I can bring up C without lying about it's history, portability, and so on. The author was probably mislead by others rather than intentionally doing it, though. Hence the need for these comments.
"That decade abended years ago. They are no longer germane to a discussion at a conference in 2015, unless you're deep diving in language lineage."
Many are still around, in commercial use, and some updated. Still better than C at robust, systems programming. I agree the author doesn't really need to go into them nor did I ask that in original comment. Just that any statements are accurate in a post about history and legacy. This is why I didn't gripe about "C++ also codified the ideas of zero-cost abstractions," which existed before C++. Yet, C++ brought them to widespread attention. Probably the author's intent and so no gripe from me.
Didn't you consider the fact that I left the rest of the write-up alone in my comment? That it might be for a reason I had lazer-like focus on the inaccuracies in the C entry rather than attacking the presentation as a whole. I get what the article is about and that's why it should maintain historical accuracy more than most.
Maybe we should totally ignore what the Greeks, Romans and Egyptians among other civilizations brought to mankind, because we weren't born in those days.
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.
"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?
The compiler backend may be viewed as a smaller component that needs to be trusted. General code lies on top of it, and there is a big difference due to code volume.
This is what concerns me: I wished Rust's "unsafe" blocks could have been exclusively confined to some things in the reference language compiler and standard library. Unfortunately, it seems like many reasonable systems applications still need access to unsafe blocks for reasons of performance, low level access, etc and such needs are not uncommon given the target systems audience.
> I wished Rust's "unsafe" blocks could have been
> exclusively confined to some things in the reference
> language compiler and standard library.
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.
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. :)
Regarding the wrappers behind unsafe behavior, in addition to some of your ideas, a lot can be done even in C, see e.g netstrings http://cr.yp.to/proto/netstrings.txt, and other safer interfaces. It requires thought, but such thought needs to be devoted in designing other languages. Unfortunately, the C/C++ standards committee rarely accepts such slower, safer extensions, forcing clients down the dark road of third party libraries and the endless choices available there, some of which are horrible and actually worse than the stdlib. I believe a lot of the problem is that there is heavy disagreement as to what interface is best, see e.g strlcpy and its adoption. Getting a large committee on board with solving something is a monumental problem, even if all acknowledge that the current situation is terrible :).
"Best results" is a very loaded term, and I tend to avoid it due to the large number of dimensions to it, the most common being the classic performance and security axes. Nevertheless, we mostly agree on the key points, with some differences in the details.
TL;DR: I have not found something representing a Pareto improvement over C. All improvements tradeoff some aspects, and it is thus sometimes not clear that there is a better alternative to C. My stronger claim is that the above is true even if one ignores legacy issues.
"What astonishes me is how something which seems a crude plagiarism became the mainstream of low-level and fast for so long. Even UNIX ..."
Richard Gabriel explained that well in his Worse is Better essays. Hence why you see me mention it a lot. Has much to do with ease of participation, economics, and group dynamics. Things like C, UNIX, and early OSS made it easy to get started to gain a critical momentum. Past that, it's basically all momentum and its effects. One usually can't counter momentum so much as create an alternate momentum or divert flows off the existing momentum. Hence, co-development of radical approaches like SAFE or JX OS's plus legacy-supporting approaches like Nizza Security Architecture or Cambridge CHERI processor & CHERIBSD. Yet, the full momentum of UNIX and C remain as more gets piled onto them despite the cost.
https://www.dreamsongs.com/WorseIsBetter.html
Note: Ignore his emotional rants tied to specific tech to focus on the effects of the New Jersey approach on market take-up. Truthfully, I think he discovered the time-to-market effect of technology and a method of achieving it before it became a common thing people wrote about. Then again, I haven't studied the history of that enough to be sure.
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.
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.
numCPU := runtime.NumCPU()
ret := runtime.GOMAXPROCS(numCPU)
From 1.5 the process the default value of MAXPROCS is total CPUs on the machine.
So its not 'reduced parallelism compared to C/C++' rather the concurrency infrastructure (channels etc) makes it transparent to the programmer. I don't have to worry about creating a threadpool myself like C/C++ and Java. So overall there is a net gain, in my understanding. Am I wrong any where in this?
Your statement holds only if GOMAXPROCS is 1, which granted used to be the default, but was always able to be increased, and the default now is the number of cores on the machine.
So, things changed since that time. OK, nice to see Go evolves. Interesting, how many code in production got broken during upgrade to Go 1.5 due to this backwards-incompatible change. Overall situation seemed totally reasonable to me at that time: Go is a language for average programmer, so it should prefer safely over runtime performance; and coding cowboys who are comfortable with mutexes, interlocked instructions, memory barrier instructions, and lock-free data structures will use C/C++ anyway.
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.
I have simply never seen another language that makes it as easy as Go does to reason about parallelism/concurrency (maybe Erlang).
Go's channels are effectively a locking message queue (Java's had one of these since at least Java 5) plus a (usually global) thread pool. Not too long ago I implemented the moral equivalent in C++11, using only the standard library and in a unit-testable format, in forty-eight lines. Selecting across them is nice syntactic sugar, but is likewise able to be mimicked in plenty of other languages. Or, alternatively, I can use way more pleasant abstractions like Akka or Celluloid in not-Go languages (sending up Erlang when Akka provides a very similar experience in Scala or Kotlin--even Java, if you're using Java 8--is...curious).
I guess you can make an argument for TOOWTDI, but I don't find that to be persuasive when the OW in question is middling.
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
Having Java's concurrent stuff is nice, don't get me wrong, but I can understand it not being the biggest priority in the world to go rebuild that later. As I've mentioned elsewhere in this thread, there are much bigger beefs.
You are implicitly casting as something to be praised one of the greater missteps of Go.
You could perhaps compare it to Python, where async functionality has a solid and well established userland implementation in Twisted, but where asyncio still made a big splash around the community. Language constructs matter.
"Misstep" was the kindest phrasing I had for the kind of trainwreckish design decisions and institutional reification of developer mediocrity that get you to what you're defending.
Your chosen tools have contempt for you, and it mystifies me as to why you would defend them for their failures.
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.)
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.
lets you bundle resources into the executable. It's not part of the language but I don't think Python's is either (?)
Also UNIX systems like Aix have support for it.
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.
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.
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.
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.
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.
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.
It was one of the most powerful Windows (GUI) programming tool back then, and easy to create beautiful UI components and had great third-party components market. Plus it has incredible compilation speed.
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.
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.
> I don't get what you are speaking about JavaFX
From context you know I meant JavaFX Script, discontinued by Oracle in 2010.
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.)
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.
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.
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.
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
Not every company is the same.
Since when does Apple have server frameworks for Objective-C?
WebObjects was re-written in Java.
My current customer uses everything native, with web apps just for small CRUD maintenance tasks of a few DB systems.
> Visual Studio is C++
Visual Studio is a mix of C++ and .NET code, its UI infrastructure was completely rewritten in VS 2010.
> Even the Win10 startmenu is still a C++ application for performance reasons.
Have you seen the code? How sure are you that it isn't .NET Native?
> Even the Win8/10 calculator app has a loading splash screen,
Anyone that knows WP dev, knows those splash screens are optional.
> the FirefoxOS calc app starts faster.
Which is behind WP and BlackBerry in sales.
Go took away subtypes? News to me.
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.
As a comparison Rust has no runtime, has no garbage collector, and is a pure systems language, and also helps developers be truly safe. Based on my experience with Go, I still don't understand where it fits, it's a compiled language, but has a runtime and a GC. So it's somewhere between C++ and Java, it's less verbose and faster to program in, but if that's the desire, than perhaps the better choice will be Kotlin in the long run.
In another post [1], the author of the article claims that Go will not "tolerate unsafe memory access".
A reference to a variable could be sent across a channel and nil'd from the sending goroutine before being dereferenced in the recipient goroutine, causing a crash. Doesn't this invalidate the "safe memory" claims, or are concurrency-related memory issues not considered when making that claim?
[1] http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-co...
Unsafe memory accesses refers to things like accessing an array out-of-bounds, or reading from a pointer that has already been freed. (I suspect a data race could actually cause an array to be accessed out of bounds in Go, but I'm not sure.)
I'll tweak my view. Go is a pragmatic systems language.
It's design and tooling is better than scripting languages for systems glue.
There will be many places where it's not suitable vs C or Rust.
OT but my guess is that we'll move towards deploying applications as part of a unikernel instead of running them inside operating systems designed for multi-user usage. Multiple applications may be run on physical hardware using some sort of hypervisor, but I don't see the point in having all this overhead just to wall your application off of with Docker.
With that said, I do use Docker, but only because it's a step up from what I've previously used. Long term I'm looking towards deploying my applications with a unikernel.