Slashdot Mirror

← Back to Stories (view on slashdot.org)

Five Years of the Go Programming Language

Posted by timothy on from the going-strong dept.

omar.sahal writes Go celebrates five years of its existence with this blog post recapping a little history, future and some philosophy. "Five years ago we launched the Go project. It seems like only yesterday that we were preparing the initial public release: our website was a lovely shade of yellow, we were calling Go a 'systems language,' and you had to terminate statements with a semicolon and write Makefiles to build your code. We had no idea how Go would be received. Would people share our vision and goals? Would people find Go useful?" The Go programming language has grown to find its own niche in the cloud computing word, having been used to code Docker and the Kubernetes projects. The developers also announced details of further projects to be released, such as a new low-latency garbage collector and support for running Go on mobile devices.

49 of 82 comments (clear)

  1. Call the HR department by istartedi · · Score: 5, Funny

    Call HR. The candidates are not liars anymore.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
    1. Re:Call the HR department by __aaclcg7560 · · Score: 1

      HR will change the requirements from five years to ten years of experience in Go programming.

    2. Re:Call the HR department by aaaaaaargh! · · Score: 1

      5 years of Go versus 30 years of Common Lisp and 50 years of Lisp. :)

  2. For those interested... by Dimwit · · Score: 4, Informative

    Go was developed in large part by Rob Pike who has a long history of concucrrency programming going back to Plan 9 from Bell Labs and earlier.

    Some of his more interesting papers about concurrency are:

    http://swtch.com/~rsc/thread/n... (The Newsqueak Programming Language)
    http://swtch.com/~rsc/thread/n... (Newsqueak Implementation)
    https://www.usenix.org/legacy/... (A Concurrent Window System)

    You can even see some hints of what was to come in his paper outlining the design of the Blit terminal for Unix:
    http://doc.cat-v.org/bell_labs...

    --
    ...but it's being eaten...by some...Linux or something...
    1. Re:For those interested... by TheCarp · · Score: 4, Informative

      Interesting. I have been kicking around go on one of my side projects for a while now and I have come to REALLY LIKE the language. I never thought I would be happy to see typed variables again, but now, I like it so much, I get a bit annoyed at languages that don't have typed variables.

      It doesn't surprise me that the lead developer has so much history, because the language feels like someone said "Ok what have we learned since C came out" and then reverted all the way back to there and built something new and clean from the lessons learned.

      It reminds me a lot of the perl philosophy of "make it easy to do common things", no more fumbling around with memory allocation, it doesn't entirely do it for you, but it provides a very clean interface that makes sense for allocating what you need when you need it.

      --
      "I opened my eyes, and everything went dark again"
    2. Re:For those interested... by ThePhilips · · Score: 1

      Quirky syntax - which unlike Perl in places is mandatory in Go! - killed my interest in it pretty early.

      --
      All hope abandon ye who enter here.
    3. Re:For those interested... by Anonymous Coward · · Score: 3, Informative

      The language itself is basically Oberon, with concurrency from Occam, all with a thin coat of C syntax to make it seem more familiar. The runtime library is very different from Oberon though. And the language is moderately more complicated than Oberon, though maybe not - they added Occam/CSP to the language ,but deleted the wacky and nearly useless bitset support, so it may be a wash in the end.

      I'm a big fan of Modula-2 and its successor Oberon and always though it was a major tragedy that they were ignored in favor of C, C++, and Java, so seeing some of the original guys that inflicted C on the world finally recognize the brilliance of Oberon it and push it this way has been extremely encouraging.

      I can remember doing concurrent programming in 1985 on my Apple-2 in UCSD Modula-2. I'm kind of surprised Modula-2 hasn't seen a renaissance for use with the little Arduino boards, Modula-2 has language-level support for doing things like interrupt handlers and memory-mapped I/O.

    4. Re:For those interested... by serviscope_minor · · Score: 5, Interesting

      Go was developed in large part by Rob Pike

      Indeed, and I find it surprising. He seems to think that the reason C++ programmers haven't switched over to go is because it's just too awesome and C++ programmers are too stuck in their ways.

      http://commandcenter.blogspot....

      I do find it disappointing that someone with such an excellent track record would say something so astonishingly ignorant. But I suppose in his mind the cause for not getting C++ programmers must be the fault of C++ programmers, not Go.

      Don't get me wrong: Go seems excellent for doing the things it was designed to do, which is having large groups write internet servers of some sort or another. But it is entirely inadequate for all sorts of other application domains.

      In the two sorts of things I do, namely deep embedded (the Arduino environment rnus C++) and scientific computing, C++ is pretty much the best language out there. In the first case Go simply cannot do that. In the second case, the lack of generics or good builtin containers for vectors, matrices and images makes Go just plain horrible to use.

      Also we C++ programmers have got used to not having to type extra code (like those funny defer lines) or wading through morasses of error checking on the main flow control path.

      --
      SJW n. One who posts facts.
    5. Re:For those interested... by Dutch+Gun · · Score: 4, Insightful

      From someone who knows little about the Go language (I just read up on Wikipedia a bit just now), could someone fill me in on what particular niche Go fills? Is it essentially a haven for people who dislike C++ (apparently the view of the language authors) but think C is too dangerous / archaic? What does it do that D doesn't, for example. Or maybe it's better to ask what it does better than D?

      Also, now that C++ is moving forward much faster with language evolution (C++11/14 have modernized the language significantly with many advanced features), is Go still as relevant as it was five years ago? For instance, you say "no more fumbling around with memory allocation", but that describes my experience with C++ for years now, since smart pointers have been standardized. Then again, in C++, you need to discipline yourself to use the language appropriately, because you can do many awful things that are perfectly legal, language-wise.

      Programmers love inventing languages (it's like a rite of passage, I think), but achieving significant and sustained adoption of your new language is always the tricky part. It's not just good enough to be better than language x. You have to provide so much more value that it overcomes existing inertia, which is pretty substantial in the world of C and C++.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    6. Re:For those interested... by DuckDodgers · · Score: 2

      I think D is spectacular and I'm sorry it hasn't seen more adoption.

    7. Re:For those interested... by interval1066 · · Score: 1

      I'm kind of surprised Modula-2 hasn't seen a renaissance for use with the little Arduino boards...

      Agreed, a high-level language for embedded systems would be great.

      --
      Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
    8. Re:For those interested... by Waffle+Iron · · Score: 3, Informative

      Due to the inherent design of C/C++ header files and their "compile units", building any large project in C++ takes almost forever. The work to build grows significantly more than linearly with the number of source files.

      Many things in C++ feel very "brittle" largely due to the limitations of its type system and generics.

      C++ reference counting is better than fully manual memory management, but still often requires careful attention to "ownership" issues, leaving a risk of leaks or segfaults.

      Most recommedations from the experts advise against using most of the actual features of C++ because they are so poorly conceived, poorly supported, or cause safety or compatibility problems. Best to stick with a bare-bones subset that's not very satisfying.

      Many of these problems were addressed by languages such as Java and C#. However those both require a heavyweght "virtual machine" runtime. The nice thing about Go is that it creates self-contained executables that run without needing to install anything special on the target machines (at the cost of the executables being larger than most people are used to).

    9. Re:For those interested... by CurryCamel · · Score: 1

      The front page makes no mention of embedded software. Instead it talks about "commanding robots" and shows an example of connecting from a linux desktop over a serial cable.
      This is not "embedded".

    10. Re:For those interested... by Necroman · · Score: 4, Interesting

      Go is a very opinionated language - IE: the language designers decided a lot of things for you, so you just code in the style that they have outlined. This leads to most code following similar styles and patterns. This improves readability of code from other people greatly.

      The bar for adding specific features to the language itself is extremely high, so the overall language is simple at its core.

      Rob Pike has a good writeup about it from 2 years ago: http://commandcenter.blogspot....

      --
      Its not what it is, its something else.
    11. Re:For those interested... by ogdenk · · Score: 1

      namely deep embedded (the Arduino environment rnus C++)

      You do this for a living? The fact you said "deep embedded" and Arduino in the same sentence kinda made me giggle. With 8-bit AVR's you're probably better off with assembly. With the 32-bit ARM variant, straight ANSI C is probably where it's really at. I really don't know anyone using C++ for microcontroller programming.

      "Deep Embedded" would be more like VHDL or CUPL programming.

       

      scientific computing, C++ is pretty much the best language out there.

      Yep, that's why there's still so much FORTRAN code getting written.

    12. Re:For those interested... by dasacc22 · · Score: 1

      The OP mentioned Arduino. The front page provides an arduino sample and further down demonstrates uploading the firmware. This works with the beefier platforms. See also http://embd.kidoman.io/

      But if you're talking about something running with 256kb of ram, then Go's current runtime isn't suitable. I've seen new runtime implementations for working with such systems though I don't recall the name of the project or links but there's nothing inherently preventative of Go for use on such systems given an appropriate runtime.

    13. Re:For those interested... by serviscope_minor · · Score: 1

      You do this for a living?

      partly.

      The fact you said "deep embedded" and Arduino in the same sentence kinda made me giggle.

      An 8 bit integrated MCU pretty much qualifies as deep embedded. An Arduino is just an ATMega on a breakout board with a boot loader. That's no different from an 8 bit MCU soldered to any other board.

      With 8-bit AVR's you're probably better off with assembly.

      I write ASM on 12F series of PICS. Arduino support C++ just fine, and it's sufficiently useful that there are a group of people keeping GCC up to date on them. I would much rather write complex control software in C++ and drop to ASM only whe nI have to than write the whole lot in ASM.

      With the 32-bit ARM variant, straight ANSI C is probably where it's really at.

      Or C++ because it uses precisely as many resources (sometimes even fewer!) is every bit as fast (idiomatic C++ is often faster!) and is far more expressive.

      I really don't know anyone using C++ for microcontroller programming.

      Whether you liek Arduinos or not, they are microtcontrollers and you've just ignored a large number of microcontroller programmers. It might not be the "proper" (only true Scotsmen program microcontrollers, amirite) thing you're used to but it's a large community and doig a lot of stuff.

      "Deep Embedded" would be more like VHDL or CUPL programming.

      Nope, that's FPGA or even custom silicon stuff. A tiny micro hidden on a board somewhere is deep embedded.

      Yep, that's why there's still so much FORTRAN code getting written.

      Turns out the OTHER thing I do for a living is scientific computing. It's split. FORTRAN is a bit faster, C++ is more flexible. I've never met a single image processing or computer vision person who uses C++. The last supercomputer group I worked wit htended to prefer C++ unless they were porting old FORTRAN codes.

      C++ is way more expressive than FORTRAN and it makes it a better language for general scientific programming, unless you need the absolute top performance.

      --
      SJW n. One who posts facts.
    14. Re:For those interested... by serviscope_minor · · Score: 1

      But if you're talking about something running with 256kb of ram, then Go's current runtime isn't suitable. I've seen new runtime implementations for working with such systems though I don't recall the name of the project or links but there's nothing inherently preventative of Go for use on such systems given an appropriate runtime.

      256K of RAM is doable. The ATMega's go down to 4K of RAM, which is getting awfully tight. Fundementally, a language relying on GC isn't very suitable for something with that little RAM. C++ works because you can use a mix of static and stack allocation.

      --
      SJW n. One who posts facts.
    15. Re:For those interested... by rdnetto · · Score: 1

      I think D is spectacular and I'm sorry it hasn't seen more adoption.

      I'll second that. It seems to be purely a matter of corporate backing - Go and Rust have received a significant amount of funding from Google and Mozilla, but D hasn't gotten much more than a few conferences sponsored by Facebook.

      --
      Most human behaviour can be explained in terms of identity.
  3. Burning question by TangoMargarine · · Score: 2

    Do they explain why their mascot is a flying, startled, anthropomorphic burrito?

    --
    Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    1. Re: Burning question by Anonymous Coward · · Score: 1

      It is the plan9 logo, re stylized.

    2. Re:Burning question by Rinikusu · · Score: 1

      It's cute! So is the Plan 9 mascot.

      --
      If you were me, you'd be good lookin'. - six string samurai
  4. Fun fact by Anonymous Coward · · Score: 1

    The Japanese word for 5 is "go".

    1. Re:Fun fact by Anonymous Coward · · Score: 1

      And what's fun about that?

  5. Re:So no one has used it yet? by ledow · · Score: 2

    Can anyone name a large (non-Google) project written in Go?

  6. Re:So no one has used it yet? by chuckymonkey · · Score: 4, Informative

    It says right in the summary. Docker is one of them. Here's a few others: Doozer(Heroku) DropBox backend services CloudFlare SoundCloud BBC uses it pretty extensively etc....etc

    --
    "Some books contain the machinery required to create and sustain universes."-Tycho
  7. Re: So no one has used it yet? by LeadSongDog · · Score: 1

    What's that in English?

    --
    Oh, I'm sorry sir, I thought you were referring to me, Mr. Wensleydale.
  8. Re:So no one has used it yet? by Ian+Lance+Taylor · · Score: 1

    Docker? (http://www.docker.com)

  9. Re:So no one has used it yet? by ledow · · Score: 1

    So that's one, then, from several replies. And pretty much the only project suggested.

    Not a great endorsement.

    Next question: Could someone have written Docker in other languages just as easily?

  10. Language bindings still broken on Mac OS by tlambert · · Score: 2

    Language bindings still broken on Mac OS.

    It's not that surprising, since they implement their own system call stubs, rather than linking the Go runtime against the system C language bindings.

    The definition of the system call boundary on Mac OS X is "at the top of libSystem", *NOT* at the user/kernel boundary.

    As a consequence, the language bindings used by Go omit information and parameters needed by the actual system calls.

    For example, the "kill" system call on Mac OS X takes 3 parameters, while the "kill" libSystem routine is POSIX compliant, and takes two parameters. The third parameter is used to provide a behavioural hint to the OS as to whether you want traditional Mac OS X behaviour, or whether you want strict POSIX behaviour. One of these places is where a signal is sent to a process group of which the sender is a member (done by using a negative PID to indicate via the sign bit that the PID is actually a PGROUP).

    What that means is that whatever the hell happens to be in the third parameter register determines whether sending a kill to your own PGROUP also sends the kill to yourself (POSIX) or you sit around on your thumb waiting for a kill that's never going to come, because you wrote to the POSIX behaviour, but selected the traditional Mac OS X behaviour instead.

    There are about 40 of these "gotcha's" in the Go use of direct system call bindings that the Go developers failed to take into account on Mac OS X; I can only believe that there are similar issues on other platforms (mostly because I know of two of those issues on BSD platforms).

    It's pretty much a given that composite APIS that use descriptors to avoid changing the user visible implementation underlying the upper level code (based on a contract change between the C library and the kernel, without a contract change between the C library and the application) also fall into that category. This includes most of the pthread_attr_t using/providing APIs, posix_spawn, POSIX semaphores, and so on.

    I have a great deal of respect for Rob Pike as a language designer, but I have to say, the way language bindings have been handled in Go is pretty abysmal.

    1. Re:Language bindings still broken on Mac OS by Ian+Lance+Taylor · · Score: 1

      Please file bug reports at http://golang.org/issue .

      Several of the main Go developers use Mac OS X every day, so it can't be that bad.

    2. Re:Language bindings still broken on Mac OS by frank_adrian314159 · · Score: 1

      Several developers in the world work around bugs each day, so they can't be that bad.

      If this is the normal viewpoint of Go developers/users, then I can see why few people actually use it.

      --
      That is all.
    3. Re:Language bindings still broken on Mac OS by Ian+Lance+Taylor · · Score: 1

      Several developers in the world work around bugs each day, so they can't be that bad.

      If this is the normal viewpoint of Go developers/users, then I can see why few people actually use it.

      I'm sorry, you have misunderstood. Some of the main Go developers work on Mac OS without any trouble. They aren't working around anything. They are just using the language.

      I don't know what problems tlambert is encountering, and I hope that he or she will be willing to report them to the issue tracker so that they can be fixed.

    4. Re:Language bindings still broken on Mac OS by tlambert · · Score: 1

      Several developers in the world work around bugs each day, so they can't be that bad.

      If this is the normal viewpoint of Go developers/users, then I can see why few people actually use it.

      I'm sorry, you have misunderstood. Some of the main Go developers work on Mac OS without any trouble. They aren't working around anything. They are just using the language.

      I don't know what problems tlambert is encountering, and I hope that he or she will be willing to report them to the issue tracker so that they can be fixed.

      Hi Ian.

      When I was working at Google, I walked over and talked to the developers in person.

      They didn't see it as a big problem, and preferred to be able to do static linking, which Apple (where I worked prior to working for Google) prefers you don't do (prefer as in intentionally make it impossible by leaving the necessary bits out of their development tools). It was more or less "irreconcilable difference" territory, even when I offered to do all the necessary dyld/dyle glue code for them (I wrote the kernel exec code on Mac OS X, so I am very familiar with the C runtime code up in user space).

      This is a case of a problem they are were unwilling to fix at the time; they may be willing now, but find themselves unable (the code for the runtime interaction with the dynamic binding required for libSystem for a new language binding is pretty dense).

      The bottom line is that it's practically useless for the kind of user space code I'd like to be able to write with the language.

    5. Re:Language bindings still broken on Mac OS by Ian+Lance+Taylor · · Score: 2

      When I was working at Google, I walked over and talked to the developers in person.

      They didn't see it as a big problem, and preferred to be able to do static linking, which Apple (where I worked prior to working for Google) prefers you don't do (prefer as in intentionally make it impossible by leaving the necessary bits out of their development tools). It was more or less "irreconcilable difference" territory, even when I offered to do all the necessary dyld/dyle glue code for them (I wrote the kernel exec code on Mac OS X, so I am very familiar with the C runtime code up in user space).

      This is a case of a problem they are were unwilling to fix at the time; they may be willing now, but find themselves unable (the code for the runtime interaction with the dynamic binding required for libSystem for a new language binding is pretty dense).

      The bottom line is that it's practically useless for the kind of user space code I'd like to be able to write with the language.

      I'm on the Go team myself.

      You are of course correct that Go has chosen to make system calls directly, in a way that Mac OS X explicitly does not support. But there is a difference between "not supported" and "not working." What I'm wondering about is when Go's approach causes actual problems, rather than theoretical ones. You cited specific problems in your original post above. Please file issues for the actual problems, so that we can fix them. Thanks.

    6. Re:Language bindings still broken on Mac OS by tlambert · · Score: 1

      I'm on the Go team myself.

      You are of course correct that Go has chosen to make system calls directly, in a way that Mac OS X explicitly does not support. But there is a difference between "not supported" and "not working." What I'm wondering about is when Go's approach causes actual problems, rather than theoretical ones. You cited specific problems in your original post above. Please file issues for the actual problems, so that we can fix them. Thanks.

      I'll consider filing bug reports for them, although I feel that it's probably more of a job for a QA person being paid by Google to do the work, rather than my job, seeing as I am not currently with Google. At present, none of the projects where I had considered using Go have used Go because of these deficiencies, so I have no real incentive to do the legwork for free, if it's going to take me away from other work.

      Here's a partial list of interfaces that are implemented in the Libc portion of Libsystem, rather than directly as system calls, and are therefore unavailable to call from Go:

      bsd_signal, confstr, creat, crypt, encrypt, ftw, gethostid, gettimeofday, getwd, killpg, nftw, semctl, setpgrp, setregid, setreuid, shmctl, sigsetmask, sigblock, sigpause, sighold, sigrelse, sigignore, statvfs, tcgetsid, uname, utmpx
      etc., including all 32 POSIX1e ACL related commands, almost all pty related code, much of termios.

      Here's a partial list of system calls which use an additional parameter/error checking/descriptors at the user/kernel boundary, and therefore randomly exhibit POSIX non-compliant behaviour when called from Go programs:

      posix_spawn, posix_spawnp, pthread_create, pthread_mutex_lock, pthread_mutex_unlock, fork, kill, sigaction, sigvec, etc. ...like I said, a job for a QA person to identify them all.

      Ideally, what would happen, is that The Open Group VSU, VSX, VSTH, and VSRT tests, at a minimum, would be converted to Go, and verified that they get the same results as their C language counterparts when run against any UNIX or UNIX-like platform. Barring that (due to licensing expense), the Open Source LSB-FHS, LSB-VSX, and LSB-OS tests would be used instead.

    7. Re:Language bindings still broken on Mac OS by Ian+Lance+Taylor · · Score: 1

      Since you worked at Google, you know of course that the Go team is a small team working on a free software project. There are no paid QA people.

      Thanks for the list of system calls. It's hard to associate that back to Go. As you know the Go library is not the C library. There is no support in Go for direct calls to functions like posix_spawn, pthread_create, pthread_mutex_lock, etc. These make no sense in the Go context. Go has its own facilities that provide similar functionality. Similarly for signal handling, process control, etc. Any programs that call the functions you list have to use C, not Go, on any platform--and Go supports calling C functions in Darwin, and those C functions will use the usual library interface.

      So it's still not clear to me that there is an actual problem.

  11. What really does it bring to the table? by kervin · · Score: 1

    On the client side, we really need a bytecode standard that will allow developers to choose from multiple language "frontends". That would take the major browser makers coming together on this like they did for HTML5.

    On the backend, we have dozens of VMs to choose from. What does Go bring that Java and JVM target languages, Ruby, Python, etc does not already give us?

    1. Re:What really does it bring to the table? by aaaaaaargh! · · Score: 1

      - It's faster than Python and, I suppose, Ruby.

      - It has a faster executable startup time than Java and other languages that depend on the clunky JVM.

      - It's not as OO-perverted as Java, or at least, allows you to write your OO-perverted code with less keystrokes than Java.

      - It has many features that the Algol68 language has, too.

      - It lacks many features that Common Lisp has and will never have them. (Whether you think that's good or not, depends a bit on the length of your beard and weather you primarily live off coke and chinese food and pizza or not.)

      - It has built-in concurrency like Ada has, only that it is much less safe than Ada and also much slower.

      - It is slower than C and Fortran, so if you do number crunching it will give you an additional coffee break.

      - It provides endless opportunities and fun with fiddling around with glue code for interfacing to C and C++ libraries - like all new language!

      - Its somewhat easier to learn and use than Forth, but less easier to use than Python (which is good, because we don't want it to be too easy now, do we)

      Please notice that I'm not in any way affiliated with Google, so this not some hidden advertising/slashvertisement.

    2. Re:What really does it bring to the table? by znrt · · Score: 1

      Its somewhat easier to learn and use than Forth,

      i don't think so. in forth the awkward syntax actually accounts for a different paradigm. in go it just seems whimsical (speaking as someone who just did some go tuts, i find it has actually some pretty cool features ... i'd like to use in c!)

  12. Re:So no one has used it yet? by Ian+Lance+Taylor · · Score: 3, Informative

    Docker was the obvious suggestion, since it's right there in the article.

    Here is a list of some projects written in Go: http://code.google.com/p/go-wi... . A few are Google projects. Most are not.

    > Could someone have written Docker in other languages just as easily?

    I don't know, you'll have to ask the Docker authors. You could start at http://www.slideshare.net/jpet... .

  13. Re:So no one has used it yet? by dasacc22 · · Score: 1
    There's so many

    and the list goes on and on with startups (http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html) and big names (https://github.com/dropbox/godropbox https://github.com/facebookgo) alike. Just google for more or explore github.

  14. Re:So no one has used it yet? by interval1066 · · Score: 1

    Tons. I don't really need to trot out some project names for you, do I? But what I can point to: do google search on variations of "google code", "google projects", "google api", search for various apis on github, and you may be startled by the number of those projects that are written, some times in part but often whoally, in C++.

    --
    Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
  15. Re:Isn't Go 11 years old? by jfbilodeau · · Score: 1

    There's Go! and there's Go

    Seems pretty obvious to me :P.

    --
    Goodbye Slashdot. You've changed.
  16. Re:Parametric polyforphism by fisted · · Score: 1

    polyforphism? seriously?

    --
    CLI paste? paste.pr0.tips!
  17. Re:Isn't Go 11 years old? by stephenmac7 · · Score: 1

    Go, not to be confused with Go!

    --
    "No man's life, liberty, or property are safe while the legislature is in session." -- Judge Gideon J. Tucker
  18. Re:Was ok till I read this: by NoOneInParticular · · Score: 1

    If that's your point, you might want to get off your operating system as well. That thing is doing all kinds of stuff while running your program that you didn't tell it to do, leading to all kinds of unexpected behavior.

  19. Re:Parametric polyforphism by darenw · · Score: 1

    I am so old, over the hill! So out of it! Completely fell off the wagon when it comes to shiny new things.

    I don't even know about monoforphism!

  20. Re: Was ok till I read this: by LoRdTAW · · Score: 1

    Rust? No GC with safety.