Slashdot Mirror

An anonymous reader writes: Ruby developers have announced the official release of Ruby 2.3.0. This release introduces a frozen string literal pragma, which is "a new magic comment and command line option to freeze all string literals in the source files." It also adds a safe navigation operator &. similar to what exists in C#, Groovy, and Swift. Ruby 2.3.0 also has many performance improvements. For more details, see the news file and the full changelog.

An anonymous reader writes: Ruby developers have announced the official release of Ruby 2.3.0. This release introduces a frozen string literal pragma, which is "a new magic comment and command line option to freeze all string literals in the source files." It also adds a safe navigation operator &. similar to what exists in C#, Groovy, and Swift. Ruby 2.3.0 also has many performance improvements. For more details, see the news file and the full changelog.

An anonymous reader writes: SuperTux, the free software game inspired by Nintendo's Super Mario Brothers, has put out its first stable release in a decade. SuperTux 0.4 rewrites the game engine to make use of OpenGL, SDL2, and other modern open-source game tech. SuperTux 0.4 additionally features a lot of new in-game content, an in-game download manager, and support for translations. SuperTux 0.4 can be downloaded for Linux, Windows and Mac via GitHub.

An anonymous reader writes: Last month 188 entries turned up on GitHub in an event challenging programmers to write computer code to generate 50,000-word novels. "The 'novel' is defined however you want," wrote the organizer for National Novel-Generating Month. "It could be 50,000 repetitions of the word 'meow.' It could literally grab a random novel from Project Gutenberg. It doesn't matter, as long as it's 50k+ words." Novels were submitted as Issues on the event's GitHub repository, and this year saw intriguing titles like "The Hero with Arbitrarily-Many Faces," "THE CYBERWHALE – a cyberpunk version of Moby Dick," and "Terms and Conditions – a Legal Thriller."

New submitter schklerg writes: Like many, I am tired of being the product of the corporate "cloud" overlords. To that end, I've got my own Linux server running Tiny Tiny RSS (RSS — Feedly replacement), OwnCloud (Storage / phone backup / Keepass sync / notes — Google Drive replacement), Coppermine Gallery (picture library), Dokuwiki (quick reference), and Shaarli (bookmarks manager — Foxmarks / Sync replacement). Crashplan lets me pick the keys for my backups, and the only thing Google Drive ever sees is a pgp encrypted file of various items. Next up is moving from gmail with iRedMail. Yes, the NSA may have it all anyway, but being under less corporate control is a nice feeling. What have you done to maintain control of your own data?

subh_arya writes: Researchers from NYU, UToronto and MIT have come up with a technique that captures human learning abilities for a large class of simple visual concepts to recognize handwritten characters from World's Alphabet. Their computational model (abstract) represents concepts as simple programs that best explain observed examples under a Bayesian criterion. Unlike recent deep learning approaches that require thousands of examples to train an efficient model, their model can achieve human-level performance with only one example. Additionally, the authors present several "visual Turing tests" probing the model's creative generalization abilities, which in many cases are indistinguishable from human behavior.

An anonymous reader writes: Mozilla today launched an iOS content blocker called Focus by Firefox. It's a "content blocker" because although Focus is capable of blocking some ads, this latest project from the non-profit is aimed at stopping trackers. The free app is made possible thanks to iOS 9's content-blocking feature, which requires some setting up. Like with any content blocker, after you download Focus, you'll have to activate Focus' content-blocking features within your system-wide iOS settings (launching the app will provide a guide to finish configuration). It's worth noting that Focus only works with Safari. Mozilla says, "This was not our choice—Apple has chosen to make content blocking unavailable to third party browsers on iOS." Here is the Focus GitHub repo and its feedback tool.

An anonymous reader writes: Automated license plate readers have become a serious point of contention between law enforcement and privacy-minded citizens. But the advance of technology might make it a moot point — with some open source software and a cheap webcam, anyone can now start cataloging the cars visiting their street. A two-man team developed OpenALPR and started distributing it for free, along with the source code. Law enforcement and the agencies that build their plate scanners have argued in favor of the legality of such data collection, so it's not like they can suddenly start cracking down on private citizens doing the same. "An enterprising person could even use a car-mounted camera and create a mobile plate hunting device along the lines of what many police agencies already use." Is this particular privacy fight one that's still winnable?

jcr writes with the news that Apple's Swift has gone open source: From Apple's press release: "We are excited by this new chapter in the story of Swift. After Apple unveiled the Swift programming language, it quickly became one of the fastest growing languages in history. Swift makes it easy to write software that is incredibly fast and safe by design. Now that Swift is open source, you can help make the best general purpose programming language available everywhere." It's listed at Apple's GitHub repository, too. (Hat tip to Jono Bacon.)

An anonymous reader writes: After a long wait web developers can finally start migrating their code to PHP 7. The new version comes with minimal syntax modifications, and is more focused on improving performance and upgrading PHP's core interpreter. Softpedia reports: "As mentioned above, PHP 7 is focused on speed, and benchmarks carried out over the past few months, have shown it to be almost twice as fast as older PHP 5.x releases, and neck in neck with Facebook's HHVM project, a Just-In-Time compiler for PHP code." A full list of new features is available here.

This conversation was generated by a post Eric S. Raymond published on his "Armed and Dangerous" blog that said, "...if you are any kind of open-source leader or senior figure who is male, do not be alone with any female, ever, at a technical conference. Try to avoid even being alone, ever, because there is a chance that a 'women in tech' advocacy group is going to try to collect your scalp." Eric later wrote a post about how Social Justice Warriors may be more of a problem than the problems they complain about.

Whoa! Predatory women in tech trying to entrap people like (and including) Linus Torvalds the way an old-time private eye got the goods on an errant husband as part of a divorce case? Scary! And worrying about thoughtcrime, too? Oh my! But Liz Bennett is an actual software engineer who works at Loggly in San Francisco. She writes for her company's blog when she's not writing Java code, has a (not very active) GitHub account, and plays bassoon. And her attitude is similar to the one espoused by ESR in the second post (above): write great code -- and if you do, they (for any value of they) have no right to be negative about you, period. And, she says, before you take a job you should be sure the company is a good "fit" for you and doesn't harbor people who will work to bring you down -- which is great advice for anyone, in any field of endeavor.

An anonymous reader writes: British programmer and writer John Graham-Cumming has spotted what appears to be a 'code-protest' in the next generation of the hypertext protocol. Each new connection forged by the HTTP/2.0 protocol spells out the word 'PRISM' obliquely, though the word itself is obscured to the casual observer by coded returns and line-breaks. Work on the hidden message in HTTP/2.0 seems to date back to nine days after the Snowden revelations broke, with the final commit completed by July of 2013. In July 2013 one of the protocol's architects appealed to the development group to reconsider design principles in the light of the revelations about the NSA's worldwide surveillance program.

An anonymous reader writes: Computer scientists at the University of Lincoln have invented a reliable, low-cost system which replicates in robots the pheromone-based communication behind insect swarms. Using off-the-shelf equipment including an LCD screen and a USB camera, the team has proposed what they call COS-phi, or Communication System via Pheromone. The artificial pheromone trails are traced visually onto the screen. As soon as a bot picks up on the path, it is forced to follow the leader.

A few weeks ago you had the chance to ask Alan Donovan and Brian Kernighan about programming and their upcoming book, The Go Programming Language (available as an eBook Friday the 20th). Below you'll find their answers to your questions.
Donovan/Kernighan: Thanks to all the Slashdot readers who posed such thoughtful and provoking questions; we’re sorry that space limitations prevent us from answering more of them. Neither of us is part of the core Go team, so we can’t give authoritative answers for some of the questions that deal with future plans for the language or tools.



OpenGL and LockOSThread
by Anonymous Coward

Hi, I've stopped using Go when I saw the hacky stuff I need to do to get libraries like OpenGL to behave correctly. Are there any plans to fix this?

Donovan: The crux of the problem is that many C libraries such as OpenGL implicitly use the identity of the calling thread to store context information. In some cases, this is because the API was designed before multithreading was the norm, when global variables could be safely used to store context information. In other cases, this design is merely a matter of convenience, since it saves passing an extra parameter to every call.

The designers of Go rejected thread-local storage (TLS) because of its tendency to cause "action at a distance": it makes programs slightly shorter but much harder to read. (See p.282 of our book.) Since the lack of TLS in Go is considered a feature, there are no plans to "fix" it, but it may be possible to make TLS-heavy C libraries work better with Go. My colleague David Crawshaw just gave a talk at DotGo 2015 in Paris about this very issue as it concerns OpenGL.



Why was package versioning left out?
by genocitizen

Why was package versioning left out? And are you guys still fond of this decision? As I use Go more and more I see this to be the weak spot; software has been around for many decades, and we all know that it is continuous evolution. Go's import system does not allow specifying or hinting a version, nor does the `go get` command (although it supports major VCSes), and that's how hacks like gopkg.in have been conceived. And it's not like package managers for other languages haven't already solved in a more or less elegant way the problem already...

Donovan: Go is designed for large programs, and versioning is notoriously hard in that context. About ten years ago, there was an experiment to introduce versioning into Google's build system (which was designed by Rob Pike and others). It failed because of the "diamond dependency" problem, which I'm sure many of you have heard of---it's the classic problem of version numbering. Consider four packages A, B, C, D, where A depends on B and C, and B and C both depend on D. This is a diamond dependency. If the author of B decides that only version 1 of D will do, and the author of C requires at least version 2 of D, you have an impossible set of constraints. If you're lucky, you might be able to build A with both the old and the new versions of D, but in general this doesn't work. Since that experiment, Google hasn't touched automated versioning again. The way we do versioning is simple but manual: we treat each version of a package as a separate entity with a distinct name (for example, "D1", "D2"), and work hard to limit the number of versions of each package---ideally to one. That’s why versioning hasn’t been a priority for us at Google. However, this August, the prolific Dave Cheney proposed a scheme for Go package version numbering, so perhaps we’ll see development of this idea in the near future.



Error Handling in Go
by JPyObjC Dude

Go language differs from many other languages in how it handles Errors. Can you summarize the benefits and drawbacks to the Go language error handling approach when compared to Java for large scale applications.

Kernighan: In general, Go strongly encourages being explicit about errors. The standard library functions almost all return an error status along with the function value and your code must do something with that error status; you can’t just ignore errors. In this respect, Go is similar to Java, where you have to either catch or throw errors; you can't just do nothing. This is a nuisance in small one-off programs, but it's a life-saver in larger ones. So both languages are doing "the right thing".

Where they differ is primarily in the use of exceptions. Go does not have an exception mechanism, so there's no direct way to handle all the errors in a single block as there is with Java's try/catch, though the defer statement can help to consolidate error handling. This means that Java code might be somewhat more compact (in this respect only!), but perhaps at the price of not providing as much precise information about what went wrong.

Our Go book spends quite a bit of time on the topic of error handling, and in most of the examples we've tried to show how to deal with errors properly rather than ignoring them, even though this can make the example programs a bit longer.

Donovan: I’ve written a fair amount of Java code and, in my experience, good error handling is about equally hard in both languages. However, Go reduces the syntactic cost of augmenting an error message as you propagate it, because you have to write more or less the same code whether or not you augment the error with new information. Java, by contrast, makes it so tempting to avoid writing try/catch/throw blocks that, too often, programmers propagate exceptions without thinking. It’s interesting that you can never divine such subtle pragmatic differences between languages merely from reading their specs.



Usage
by Behrooz Amoozad

For what scenarios and projects do You recommend it and for which you recommend against using Go?

Kernighan: Go is a very good general purpose language, and we would have no hesitation about using it for any new task. It seems especially well-suited for programs that involve networking or other concurrent tasks; goroutines are very convenient and efficient, and there is also good support for more traditional shared-memory approaches. Empirically, people who write new networking code tend to like Go. I personally would use it for anything where in the past I might have used C or Java or C++.

Go has also gotten some traction as a scripting language, a potential replacement for large Python scripts. This may seem a bit surprising, since scripting languages are very convenient for cobbling something together in a hurry. The problems come later, when the cobbled-together code starts to crash with type errors or other faults that could have been detected much earlier with a statically typed language. Go won't replace Awk for one-liners, nor is it likely to replace Python or Perl or Ruby for 10- or even 100-line programs, but after a while, the combination of type safety and efficiency is worth the somewhat higher up-front cost.



Why should I use Go?
by aaaaaaargh!

For someone like me who likes garbage collection, multiple dispatch, and extreme abstraction capabilities in high level languages like Common Lisp, and safety, compile-time error detection, readability, and speed in low level languages like Ada or Haskell, what are the benefits of using Go in comparison to these two different types of languages? What new useful features does Go bring?

Kernighan: Ada and (especially) Haskell don't seem like low-level languages and Haskell is inscrutable to newcomers, but those are quibbles. Go has everything you mention in both of your lists of desirable attributes (depending perhaps on what you mean by "extreme abstraction"), but it also provides concurrency in a convenient and efficient form; that's a big win for some kinds of applications.

Donovan: Go seems very plain when compared with languages like Common Lisp, C++, Java, or Python. It has no macros, no templates, no classloaders, no metaclasses. Features such as these are often the first things I, being a PL geek, rush to play with when writing toy programs in a new language, but they are not usually the things that matter the most when programming in the large. I can recall without fondness many days spent debugging overly clever uses of the C++ STL or non-hygienic Lisp macros or the Python __call__ method. The design of Go recognizes that simplicity, homogeneity, and familiarity of a large code base are more valuable to the team as a whole than the benefits to each individual of using their favorite (obscure) language features for each task.



Go’s potential
by Qbertino

What serious long-term real-world potential do you see for Go? How do you see the potential of Go replacing existing open source webstacks such as Apache and PHP, Python or Ruby? Was Go built with a technology update of existing approaches in mind? How feasible is it in your opinion to try and replace the existing complex stacks with pure Go runtimes?

Kernighan: The reason it took God only six days to create the universe is that he didn't have to deal with the embedded base. Realistically, no programming language is likely to completely replace major existing code bases; it's just too much work. Go is often a good choice for new projects or where one is planning to rewrite an existing system anyway, and it can provide a good interface to existing code through foreign function interfaces, particularly to C libraries. But wholesale replacements seem unlikely.

Donovan: I agree with Brian that Go isn’t likely to eliminate any other language or library, but that is not its goal. Go provides an attractive alternative. A good part of Go’s popularity comes from the ease with which you can build useful web servers and other distributed systems using little more than the components of the standard library. The library was produced recently, and thus with the benefit of hindsight, by systems experts, and it often makes third-party servers like Apache or frameworks like Rails unnecessary for the first steps---although of course similar frameworks do exist for Go too.



Official Go IDE?
by Qbertino

Is there an official cross-platform Go IDE in the works? Experience shows that adoption is accelerated by offering a solid toolkit that is easy to pick up and get started with - such as the formidable Android Studio IDE Google offers to developers. Are there any plans similar to this for Go? I would like to see it take the place of C++ in the development of performant end-user applications with GUIs - are there any officially sanctioned projects that aim to provide a serious GUI toolkit and stack based on Go?

Donovan: We agree that good IDE support is important for attracting new users to Go, though my colleagues and I came to this realization rather slowly as, perhaps unsurprisingly, most of us use very traditional editors like Vim, Emacs, SublimeText, and even Acme, which are not what most people think of as IDEs. This year, JetBrains have created a team to develop a Go plugin for IntelliJ so that IntelliJ IDEA users can build, test, debug, and refactor programs written in Go as easily as in any other language.

As for cross-platform GUI toolkits, there’s no canonical solution yet, though there have been some interesting experiments such as GXUI and Shiny.



Should Go replace Java?
by Martinjnh

Should Go replace Java as development platform/language for android?

Donovan: The Go team at Google is working hard to make it possible to use Go to write mobile applications on Android and iOS; see Hana Kim's GopherCon 2015 talk, for example. But for now this is just an experiment and, as Brian wrote above, it's not Go's goal to replace major existing code bases.



Safe Performance
by snadrus

Reimplementing the Gnu+Linux toolchain in GoLang could provide safety that decades of eyes on C could not (thinking about the recent BASH bugs & OpenSSL overruns). Even a small portion would add security to Android. Performance is close & 1.5's library loading should keep executables light. Is there interest in rebuilding Linux's base userland?

Donovan: Go is a good fit for these kinds of tools because the language has good runtime safety and a straightforward system call interface, and it compiles to static executables that start quickly and run efficiently. Portability might be a concern: while Go programs themselves are highly portable, Go's runtime currently targets only a handful of major architectures, far fewer than gcc and glibc support. I'm not aware of any rebuilding projects.



tEoPS
by M. D. Nahas

There many books on "how to program" but few on "how to program well". Brian, your book "The Elements of Programming Style" is a wonderful and a classic, but my students have a hard time reading the examples (Fortran 66 and PL/I). Is there any hope for an update? Is there any similar modern-language book that you recommend?
Michael Nahas (son of Joe Nahas)

P.S. I totally stole as much as I could from you when writing my tutorial for the language Coq. Sorry/Thanks!

Kernighan: The languages that Bill Plauger and I used in "The Elements of Programming Style" are either long gone (PL/1) or very much evolved (Fortran), so the code is indeed hard to read today, though most of the rules of good style are still valid. Bill and I once started a version in C but didn't get very far. One problem was that the original book relied almost exclusively on code fragments from textbooks. Modern textbooks are far better than they were 40 years ago; most code is syntactically correct and mostly works. So it was hard for us to find textbook examples to illustrate our rules. Another problem is that real programs are a lot bigger and more complicated than they were, and it's hard to find excerpts that would work in a book. So an update of EOPS isn't likely, much as it would be nice to have one.

As to other books, Josh Bloch and Scott Meyers have written excellent books on how to write good Java and C++ respectively. More broadly, I have always liked Steve McConnell's "Code Complete", and I take a fresh look at Fred Brooks's classic "The Mythical Man Month" every few years. There are plenty of other books about how to program well in various languages and environments; it's well worth reading some of them to see how other authors approach the topic.



C's current place in the world
by MountainLogic

As the legend has it, C was created to support operating system development. As time has gone by C++ has slipped into OS development on larger platforms. It seems that much of the current core use of mother C is centering on embedded processors (all the way down to 8 bit micros with 256 bytes of RAM) and drivers in larger systems. For current use what design choices in C do you see as wise and what would you change given the current usage of C. (P.S. Thank you for co-authoring the most wonderful, perfect, clear and concise technology document ever.)

Kernighan: Bear in mind that C is Dennis Ritchie's work; I can only claim to have written a book with him. Dennis was a great writer as well as a great programmer and language designer, and the book was very much a joint effort.

That said, C is indeed still popular for embedded systems and drivers, where efficiency and the ability to get right down to the hardware matters. I think that changing C today would be counter-productive; one of C's strengths is that it is quite stable. Indeed, I suspect (though without having data to prove it) that except for minor features like // comments most programmers use C as it was after the 1988 ISO standard; the C99 and C11 standards did not change much of programming practice.



Motivation for writing the book
by jameshwang

I was curious out of all the Golang books that currently exists, how does this book, "The Go Programming Language," differ from the rest and fit into the landscape of Golang? I've read some of the other books like "Go Programming Blueprints" and "Go in Action." Specifically with "Go in Action," the table of contents seems similar to your book.

I guess what was your motivation to write this book and how will it be different from all the rest? Brian, are you hoping this book becomes what "The C Programming Language" became but for Golang?

Kernighan: As it says in Ecclesiastes 12:12, "of making many books there is no end", which suggests that your question about whether another book is needed is an old one.

When one writes a book, there is always the belief or at least hope that one can do it "better" than others, not in any negative sense but just that new organization, examples, explanations, and writing will all combine in a way that readers will find helpful. Certainly that has been what Alan and I have tried to achieve with "The Go Programming Language". It would of course be wonderful if the Go book was as helpful to programmers as the C book seems to have been.

I have looked at only a couple of the many Go books that have already been written (and not the ones you mention), and in fact Alan and I quite consciously stopped even looking at titles once we started thinking about our own book, since we didn't want to inadvertently borrow from other authors.

Donovan: For me, one motivation was to write the book I wished I had been able to read when I started learning Go---a comprehensive book that covers not just the language and its library, but one that motivates the design choices, explores advanced features, flags the pitfalls, and conveys the style and aesthetics of the language.

Although comparisons with K&R are inevitable (and flattering), I don't think any technical book can ever be as influential as that one. It was not just a tutorial for the most important language of a (pre-Internet) generation, but also its reference manual and de facto spec. Today, of course, you can browse The Go Tour, Godoc, and The Go Language Specification from your cellphone. Libraries are larger and tooling is more important. A modern book must have a different emphasis. We've tried to show how all the parts fit together.

A few weeks ago you had the chance to ask Alan Donovan and Brian Kernighan about programming and their upcoming book, The Go Programming Language (available as an eBook Friday the 20th). Below you'll find their answers to your questions.
Donovan/Kernighan: Thanks to all the Slashdot readers who posed such thoughtful and provoking questions; we’re sorry that space limitations prevent us from answering more of them. Neither of us is part of the core Go team, so we can’t give authoritative answers for some of the questions that deal with future plans for the language or tools.



OpenGL and LockOSThread
by Anonymous Coward

Hi, I've stopped using Go when I saw the hacky stuff I need to do to get libraries like OpenGL to behave correctly. Are there any plans to fix this?

Donovan: The crux of the problem is that many C libraries such as OpenGL implicitly use the identity of the calling thread to store context information. In some cases, this is because the API was designed before multithreading was the norm, when global variables could be safely used to store context information. In other cases, this design is merely a matter of convenience, since it saves passing an extra parameter to every call.

The designers of Go rejected thread-local storage (TLS) because of its tendency to cause "action at a distance": it makes programs slightly shorter but much harder to read. (See p.282 of our book.) Since the lack of TLS in Go is considered a feature, there are no plans to "fix" it, but it may be possible to make TLS-heavy C libraries work better with Go. My colleague David Crawshaw just gave a talk at DotGo 2015 in Paris about this very issue as it concerns OpenGL.



Why was package versioning left out?
by genocitizen

Why was package versioning left out? And are you guys still fond of this decision? As I use Go more and more I see this to be the weak spot; software has been around for many decades, and we all know that it is continuous evolution. Go's import system does not allow specifying or hinting a version, nor does the `go get` command (although it supports major VCSes), and that's how hacks like gopkg.in have been conceived. And it's not like package managers for other languages haven't already solved in a more or less elegant way the problem already...

Donovan: Go is designed for large programs, and versioning is notoriously hard in that context. About ten years ago, there was an experiment to introduce versioning into Google's build system (which was designed by Rob Pike and others). It failed because of the "diamond dependency" problem, which I'm sure many of you have heard of---it's the classic problem of version numbering. Consider four packages A, B, C, D, where A depends on B and C, and B and C both depend on D. This is a diamond dependency. If the author of B decides that only version 1 of D will do, and the author of C requires at least version 2 of D, you have an impossible set of constraints. If you're lucky, you might be able to build A with both the old and the new versions of D, but in general this doesn't work. Since that experiment, Google hasn't touched automated versioning again. The way we do versioning is simple but manual: we treat each version of a package as a separate entity with a distinct name (for example, "D1", "D2"), and work hard to limit the number of versions of each package---ideally to one. That’s why versioning hasn’t been a priority for us at Google. However, this August, the prolific Dave Cheney proposed a scheme for Go package version numbering, so perhaps we’ll see development of this idea in the near future.



Error Handling in Go
by JPyObjC Dude

Go language differs from many other languages in how it handles Errors. Can you summarize the benefits and drawbacks to the Go language error handling approach when compared to Java for large scale applications.

Kernighan: In general, Go strongly encourages being explicit about errors. The standard library functions almost all return an error status along with the function value and your code must do something with that error status; you can’t just ignore errors. In this respect, Go is similar to Java, where you have to either catch or throw errors; you can't just do nothing. This is a nuisance in small one-off programs, but it's a life-saver in larger ones. So both languages are doing "the right thing".

Where they differ is primarily in the use of exceptions. Go does not have an exception mechanism, so there's no direct way to handle all the errors in a single block as there is with Java's try/catch, though the defer statement can help to consolidate error handling. This means that Java code might be somewhat more compact (in this respect only!), but perhaps at the price of not providing as much precise information about what went wrong.

Our Go book spends quite a bit of time on the topic of error handling, and in most of the examples we've tried to show how to deal with errors properly rather than ignoring them, even though this can make the example programs a bit longer.

Donovan: I’ve written a fair amount of Java code and, in my experience, good error handling is about equally hard in both languages. However, Go reduces the syntactic cost of augmenting an error message as you propagate it, because you have to write more or less the same code whether or not you augment the error with new information. Java, by contrast, makes it so tempting to avoid writing try/catch/throw blocks that, too often, programmers propagate exceptions without thinking. It’s interesting that you can never divine such subtle pragmatic differences between languages merely from reading their specs.



Usage
by Behrooz Amoozad

For what scenarios and projects do You recommend it and for which you recommend against using Go?

Kernighan: Go is a very good general purpose language, and we would have no hesitation about using it for any new task. It seems especially well-suited for programs that involve networking or other concurrent tasks; goroutines are very convenient and efficient, and there is also good support for more traditional shared-memory approaches. Empirically, people who write new networking code tend to like Go. I personally would use it for anything where in the past I might have used C or Java or C++.

Go has also gotten some traction as a scripting language, a potential replacement for large Python scripts. This may seem a bit surprising, since scripting languages are very convenient for cobbling something together in a hurry. The problems come later, when the cobbled-together code starts to crash with type errors or other faults that could have been detected much earlier with a statically typed language. Go won't replace Awk for one-liners, nor is it likely to replace Python or Perl or Ruby for 10- or even 100-line programs, but after a while, the combination of type safety and efficiency is worth the somewhat higher up-front cost.



Why should I use Go?
by aaaaaaargh!

For someone like me who likes garbage collection, multiple dispatch, and extreme abstraction capabilities in high level languages like Common Lisp, and safety, compile-time error detection, readability, and speed in low level languages like Ada or Haskell, what are the benefits of using Go in comparison to these two different types of languages? What new useful features does Go bring?

Kernighan: Ada and (especially) Haskell don't seem like low-level languages and Haskell is inscrutable to newcomers, but those are quibbles. Go has everything you mention in both of your lists of desirable attributes (depending perhaps on what you mean by "extreme abstraction"), but it also provides concurrency in a convenient and efficient form; that's a big win for some kinds of applications.

Donovan: Go seems very plain when compared with languages like Common Lisp, C++, Java, or Python. It has no macros, no templates, no classloaders, no metaclasses. Features such as these are often the first things I, being a PL geek, rush to play with when writing toy programs in a new language, but they are not usually the things that matter the most when programming in the large. I can recall without fondness many days spent debugging overly clever uses of the C++ STL or non-hygienic Lisp macros or the Python __call__ method. The design of Go recognizes that simplicity, homogeneity, and familiarity of a large code base are more valuable to the team as a whole than the benefits to each individual of using their favorite (obscure) language features for each task.



Go’s potential
by Qbertino

What serious long-term real-world potential do you see for Go? How do you see the potential of Go replacing existing open source webstacks such as Apache and PHP, Python or Ruby? Was Go built with a technology update of existing approaches in mind? How feasible is it in your opinion to try and replace the existing complex stacks with pure Go runtimes?

Kernighan: The reason it took God only six days to create the universe is that he didn't have to deal with the embedded base. Realistically, no programming language is likely to completely replace major existing code bases; it's just too much work. Go is often a good choice for new projects or where one is planning to rewrite an existing system anyway, and it can provide a good interface to existing code through foreign function interfaces, particularly to C libraries. But wholesale replacements seem unlikely.

Donovan: I agree with Brian that Go isn’t likely to eliminate any other language or library, but that is not its goal. Go provides an attractive alternative. A good part of Go’s popularity comes from the ease with which you can build useful web servers and other distributed systems using little more than the components of the standard library. The library was produced recently, and thus with the benefit of hindsight, by systems experts, and it often makes third-party servers like Apache or frameworks like Rails unnecessary for the first steps---although of course similar frameworks do exist for Go too.



Official Go IDE?
by Qbertino

Is there an official cross-platform Go IDE in the works? Experience shows that adoption is accelerated by offering a solid toolkit that is easy to pick up and get started with - such as the formidable Android Studio IDE Google offers to developers. Are there any plans similar to this for Go? I would like to see it take the place of C++ in the development of performant end-user applications with GUIs - are there any officially sanctioned projects that aim to provide a serious GUI toolkit and stack based on Go?

Donovan: We agree that good IDE support is important for attracting new users to Go, though my colleagues and I came to this realization rather slowly as, perhaps unsurprisingly, most of us use very traditional editors like Vim, Emacs, SublimeText, and even Acme, which are not what most people think of as IDEs. This year, JetBrains have created a team to develop a Go plugin for IntelliJ so that IntelliJ IDEA users can build, test, debug, and refactor programs written in Go as easily as in any other language.

As for cross-platform GUI toolkits, there’s no canonical solution yet, though there have been some interesting experiments such as GXUI and Shiny.



Should Go replace Java?
by Martinjnh

Should Go replace Java as development platform/language for android?

Donovan: The Go team at Google is working hard to make it possible to use Go to write mobile applications on Android and iOS; see Hana Kim's GopherCon 2015 talk, for example. But for now this is just an experiment and, as Brian wrote above, it's not Go's goal to replace major existing code bases.



Safe Performance
by snadrus

Reimplementing the Gnu+Linux toolchain in GoLang could provide safety that decades of eyes on C could not (thinking about the recent BASH bugs & OpenSSL overruns). Even a small portion would add security to Android. Performance is close & 1.5's library loading should keep executables light. Is there interest in rebuilding Linux's base userland?

Donovan: Go is a good fit for these kinds of tools because the language has good runtime safety and a straightforward system call interface, and it compiles to static executables that start quickly and run efficiently. Portability might be a concern: while Go programs themselves are highly portable, Go's runtime currently targets only a handful of major architectures, far fewer than gcc and glibc support. I'm not aware of any rebuilding projects.



tEoPS
by M. D. Nahas

There many books on "how to program" but few on "how to program well". Brian, your book "The Elements of Programming Style" is a wonderful and a classic, but my students have a hard time reading the examples (Fortran 66 and PL/I). Is there any hope for an update? Is there any similar modern-language book that you recommend?
Michael Nahas (son of Joe Nahas)

P.S. I totally stole as much as I could from you when writing my tutorial for the language Coq. Sorry/Thanks!

Kernighan: The languages that Bill Plauger and I used in "The Elements of Programming Style" are either long gone (PL/1) or very much evolved (Fortran), so the code is indeed hard to read today, though most of the rules of good style are still valid. Bill and I once started a version in C but didn't get very far. One problem was that the original book relied almost exclusively on code fragments from textbooks. Modern textbooks are far better than they were 40 years ago; most code is syntactically correct and mostly works. So it was hard for us to find textbook examples to illustrate our rules. Another problem is that real programs are a lot bigger and more complicated than they were, and it's hard to find excerpts that would work in a book. So an update of EOPS isn't likely, much as it would be nice to have one.

As to other books, Josh Bloch and Scott Meyers have written excellent books on how to write good Java and C++ respectively. More broadly, I have always liked Steve McConnell's "Code Complete", and I take a fresh look at Fred Brooks's classic "The Mythical Man Month" every few years. There are plenty of other books about how to program well in various languages and environments; it's well worth reading some of them to see how other authors approach the topic.



C's current place in the world
by MountainLogic

As the legend has it, C was created to support operating system development. As time has gone by C++ has slipped into OS development on larger platforms. It seems that much of the current core use of mother C is centering on embedded processors (all the way down to 8 bit micros with 256 bytes of RAM) and drivers in larger systems. For current use what design choices in C do you see as wise and what would you change given the current usage of C. (P.S. Thank you for co-authoring the most wonderful, perfect, clear and concise technology document ever.)

Kernighan: Bear in mind that C is Dennis Ritchie's work; I can only claim to have written a book with him. Dennis was a great writer as well as a great programmer and language designer, and the book was very much a joint effort.

That said, C is indeed still popular for embedded systems and drivers, where efficiency and the ability to get right down to the hardware matters. I think that changing C today would be counter-productive; one of C's strengths is that it is quite stable. Indeed, I suspect (though without having data to prove it) that except for minor features like // comments most programmers use C as it was after the 1988 ISO standard; the C99 and C11 standards did not change much of programming practice.



Motivation for writing the book
by jameshwang

I was curious out of all the Golang books that currently exists, how does this book, "The Go Programming Language," differ from the rest and fit into the landscape of Golang? I've read some of the other books like "Go Programming Blueprints" and "Go in Action." Specifically with "Go in Action," the table of contents seems similar to your book.

I guess what was your motivation to write this book and how will it be different from all the rest? Brian, are you hoping this book becomes what "The C Programming Language" became but for Golang?

Kernighan: As it says in Ecclesiastes 12:12, "of making many books there is no end", which suggests that your question about whether another book is needed is an old one.

When one writes a book, there is always the belief or at least hope that one can do it "better" than others, not in any negative sense but just that new organization, examples, explanations, and writing will all combine in a way that readers will find helpful. Certainly that has been what Alan and I have tried to achieve with "The Go Programming Language". It would of course be wonderful if the Go book was as helpful to programmers as the C book seems to have been.

I have looked at only a couple of the many Go books that have already been written (and not the ones you mention), and in fact Alan and I quite consciously stopped even looking at titles once we started thinking about our own book, since we didn't want to inadvertently borrow from other authors.

Donovan: For me, one motivation was to write the book I wished I had been able to read when I started learning Go---a comprehensive book that covers not just the language and its library, but one that motivates the design choices, explores advanced features, flags the pitfalls, and conveys the style and aesthetics of the language.

Although comparisons with K&R are inevitable (and flattering), I don't think any technical book can ever be as influential as that one. It was not just a tutorial for the most important language of a (pre-Internet) generation, but also its reference manual and de facto spec. Today, of course, you can browse The Go Tour, Godoc, and The Go Language Specification from your cellphone. Libraries are larger and tooling is more important. A modern book must have a different emphasis. We've tried to show how all the parts fit together.

A few weeks ago you had the chance to ask Alan Donovan and Brian Kernighan about programming and their upcoming book, The Go Programming Language (available as an eBook Friday the 20th). Below you'll find their answers to your questions.
Donovan/Kernighan: Thanks to all the Slashdot readers who posed such thoughtful and provoking questions; we’re sorry that space limitations prevent us from answering more of them. Neither of us is part of the core Go team, so we can’t give authoritative answers for some of the questions that deal with future plans for the language or tools.



OpenGL and LockOSThread
by Anonymous Coward

Hi, I've stopped using Go when I saw the hacky stuff I need to do to get libraries like OpenGL to behave correctly. Are there any plans to fix this?

Donovan: The crux of the problem is that many C libraries such as OpenGL implicitly use the identity of the calling thread to store context information. In some cases, this is because the API was designed before multithreading was the norm, when global variables could be safely used to store context information. In other cases, this design is merely a matter of convenience, since it saves passing an extra parameter to every call.

The designers of Go rejected thread-local storage (TLS) because of its tendency to cause "action at a distance": it makes programs slightly shorter but much harder to read. (See p.282 of our book.) Since the lack of TLS in Go is considered a feature, there are no plans to "fix" it, but it may be possible to make TLS-heavy C libraries work better with Go. My colleague David Crawshaw just gave a talk at DotGo 2015 in Paris about this very issue as it concerns OpenGL.



Why was package versioning left out?
by genocitizen

Why was package versioning left out? And are you guys still fond of this decision? As I use Go more and more I see this to be the weak spot; software has been around for many decades, and we all know that it is continuous evolution. Go's import system does not allow specifying or hinting a version, nor does the `go get` command (although it supports major VCSes), and that's how hacks like gopkg.in have been conceived. And it's not like package managers for other languages haven't already solved in a more or less elegant way the problem already...

Donovan: Go is designed for large programs, and versioning is notoriously hard in that context. About ten years ago, there was an experiment to introduce versioning into Google's build system (which was designed by Rob Pike and others). It failed because of the "diamond dependency" problem, which I'm sure many of you have heard of---it's the classic problem of version numbering. Consider four packages A, B, C, D, where A depends on B and C, and B and C both depend on D. This is a diamond dependency. If the author of B decides that only version 1 of D will do, and the author of C requires at least version 2 of D, you have an impossible set of constraints. If you're lucky, you might be able to build A with both the old and the new versions of D, but in general this doesn't work. Since that experiment, Google hasn't touched automated versioning again. The way we do versioning is simple but manual: we treat each version of a package as a separate entity with a distinct name (for example, "D1", "D2"), and work hard to limit the number of versions of each package---ideally to one. That’s why versioning hasn’t been a priority for us at Google. However, this August, the prolific Dave Cheney proposed a scheme for Go package version numbering, so perhaps we’ll see development of this idea in the near future.



Error Handling in Go
by JPyObjC Dude

Go language differs from many other languages in how it handles Errors. Can you summarize the benefits and drawbacks to the Go language error handling approach when compared to Java for large scale applications.

Kernighan: In general, Go strongly encourages being explicit about errors. The standard library functions almost all return an error status along with the function value and your code must do something with that error status; you can’t just ignore errors. In this respect, Go is similar to Java, where you have to either catch or throw errors; you can't just do nothing. This is a nuisance in small one-off programs, but it's a life-saver in larger ones. So both languages are doing "the right thing".

Where they differ is primarily in the use of exceptions. Go does not have an exception mechanism, so there's no direct way to handle all the errors in a single block as there is with Java's try/catch, though the defer statement can help to consolidate error handling. This means that Java code might be somewhat more compact (in this respect only!), but perhaps at the price of not providing as much precise information about what went wrong.

Our Go book spends quite a bit of time on the topic of error handling, and in most of the examples we've tried to show how to deal with errors properly rather than ignoring them, even though this can make the example programs a bit longer.

Donovan: I’ve written a fair amount of Java code and, in my experience, good error handling is about equally hard in both languages. However, Go reduces the syntactic cost of augmenting an error message as you propagate it, because you have to write more or less the same code whether or not you augment the error with new information. Java, by contrast, makes it so tempting to avoid writing try/catch/throw blocks that, too often, programmers propagate exceptions without thinking. It’s interesting that you can never divine such subtle pragmatic differences between languages merely from reading their specs.



Usage
by Behrooz Amoozad

For what scenarios and projects do You recommend it and for which you recommend against using Go?

Kernighan: Go is a very good general purpose language, and we would have no hesitation about using it for any new task. It seems especially well-suited for programs that involve networking or other concurrent tasks; goroutines are very convenient and efficient, and there is also good support for more traditional shared-memory approaches. Empirically, people who write new networking code tend to like Go. I personally would use it for anything where in the past I might have used C or Java or C++.

Go has also gotten some traction as a scripting language, a potential replacement for large Python scripts. This may seem a bit surprising, since scripting languages are very convenient for cobbling something together in a hurry. The problems come later, when the cobbled-together code starts to crash with type errors or other faults that could have been detected much earlier with a statically typed language. Go won't replace Awk for one-liners, nor is it likely to replace Python or Perl or Ruby for 10- or even 100-line programs, but after a while, the combination of type safety and efficiency is worth the somewhat higher up-front cost.



Why should I use Go?
by aaaaaaargh!

For someone like me who likes garbage collection, multiple dispatch, and extreme abstraction capabilities in high level languages like Common Lisp, and safety, compile-time error detection, readability, and speed in low level languages like Ada or Haskell, what are the benefits of using Go in comparison to these two different types of languages? What new useful features does Go bring?

Kernighan: Ada and (especially) Haskell don't seem like low-level languages and Haskell is inscrutable to newcomers, but those are quibbles. Go has everything you mention in both of your lists of desirable attributes (depending perhaps on what you mean by "extreme abstraction"), but it also provides concurrency in a convenient and efficient form; that's a big win for some kinds of applications.

Donovan: Go seems very plain when compared with languages like Common Lisp, C++, Java, or Python. It has no macros, no templates, no classloaders, no metaclasses. Features such as these are often the first things I, being a PL geek, rush to play with when writing toy programs in a new language, but they are not usually the things that matter the most when programming in the large. I can recall without fondness many days spent debugging overly clever uses of the C++ STL or non-hygienic Lisp macros or the Python __call__ method. The design of Go recognizes that simplicity, homogeneity, and familiarity of a large code base are more valuable to the team as a whole than the benefits to each individual of using their favorite (obscure) language features for each task.



Go’s potential
by Qbertino

What serious long-term real-world potential do you see for Go? How do you see the potential of Go replacing existing open source webstacks such as Apache and PHP, Python or Ruby? Was Go built with a technology update of existing approaches in mind? How feasible is it in your opinion to try and replace the existing complex stacks with pure Go runtimes?

Kernighan: The reason it took God only six days to create the universe is that he didn't have to deal with the embedded base. Realistically, no programming language is likely to completely replace major existing code bases; it's just too much work. Go is often a good choice for new projects or where one is planning to rewrite an existing system anyway, and it can provide a good interface to existing code through foreign function interfaces, particularly to C libraries. But wholesale replacements seem unlikely.

Donovan: I agree with Brian that Go isn’t likely to eliminate any other language or library, but that is not its goal. Go provides an attractive alternative. A good part of Go’s popularity comes from the ease with which you can build useful web servers and other distributed systems using little more than the components of the standard library. The library was produced recently, and thus with the benefit of hindsight, by systems experts, and it often makes third-party servers like Apache or frameworks like Rails unnecessary for the first steps---although of course similar frameworks do exist for Go too.



Official Go IDE?
by Qbertino

Is there an official cross-platform Go IDE in the works? Experience shows that adoption is accelerated by offering a solid toolkit that is easy to pick up and get started with - such as the formidable Android Studio IDE Google offers to developers. Are there any plans similar to this for Go? I would like to see it take the place of C++ in the development of performant end-user applications with GUIs - are there any officially sanctioned projects that aim to provide a serious GUI toolkit and stack based on Go?

Donovan: We agree that good IDE support is important for attracting new users to Go, though my colleagues and I came to this realization rather slowly as, perhaps unsurprisingly, most of us use very traditional editors like Vim, Emacs, SublimeText, and even Acme, which are not what most people think of as IDEs. This year, JetBrains have created a team to develop a Go plugin for IntelliJ so that IntelliJ IDEA users can build, test, debug, and refactor programs written in Go as easily as in any other language.

As for cross-platform GUI toolkits, there’s no canonical solution yet, though there have been some interesting experiments such as GXUI and Shiny.



Should Go replace Java?
by Martinjnh

Should Go replace Java as development platform/language for android?

Donovan: The Go team at Google is working hard to make it possible to use Go to write mobile applications on Android and iOS; see Hana Kim's GopherCon 2015 talk, for example. But for now this is just an experiment and, as Brian wrote above, it's not Go's goal to replace major existing code bases.



Safe Performance
by snadrus

Reimplementing the Gnu+Linux toolchain in GoLang could provide safety that decades of eyes on C could not (thinking about the recent BASH bugs & OpenSSL overruns). Even a small portion would add security to Android. Performance is close & 1.5's library loading should keep executables light. Is there interest in rebuilding Linux's base userland?

Donovan: Go is a good fit for these kinds of tools because the language has good runtime safety and a straightforward system call interface, and it compiles to static executables that start quickly and run efficiently. Portability might be a concern: while Go programs themselves are highly portable, Go's runtime currently targets only a handful of major architectures, far fewer than gcc and glibc support. I'm not aware of any rebuilding projects.



tEoPS
by M. D. Nahas

There many books on "how to program" but few on "how to program well". Brian, your book "The Elements of Programming Style" is a wonderful and a classic, but my students have a hard time reading the examples (Fortran 66 and PL/I). Is there any hope for an update? Is there any similar modern-language book that you recommend?
Michael Nahas (son of Joe Nahas)

P.S. I totally stole as much as I could from you when writing my tutorial for the language Coq. Sorry/Thanks!

Kernighan: The languages that Bill Plauger and I used in "The Elements of Programming Style" are either long gone (PL/1) or very much evolved (Fortran), so the code is indeed hard to read today, though most of the rules of good style are still valid. Bill and I once started a version in C but didn't get very far. One problem was that the original book relied almost exclusively on code fragments from textbooks. Modern textbooks are far better than they were 40 years ago; most code is syntactically correct and mostly works. So it was hard for us to find textbook examples to illustrate our rules. Another problem is that real programs are a lot bigger and more complicated than they were, and it's hard to find excerpts that would work in a book. So an update of EOPS isn't likely, much as it would be nice to have one.

As to other books, Josh Bloch and Scott Meyers have written excellent books on how to write good Java and C++ respectively. More broadly, I have always liked Steve McConnell's "Code Complete", and I take a fresh look at Fred Brooks's classic "The Mythical Man Month" every few years. There are plenty of other books about how to program well in various languages and environments; it's well worth reading some of them to see how other authors approach the topic.



C's current place in the world
by MountainLogic

As the legend has it, C was created to support operating system development. As time has gone by C++ has slipped into OS development on larger platforms. It seems that much of the current core use of mother C is centering on embedded processors (all the way down to 8 bit micros with 256 bytes of RAM) and drivers in larger systems. For current use what design choices in C do you see as wise and what would you change given the current usage of C. (P.S. Thank you for co-authoring the most wonderful, perfect, clear and concise technology document ever.)

Kernighan: Bear in mind that C is Dennis Ritchie's work; I can only claim to have written a book with him. Dennis was a great writer as well as a great programmer and language designer, and the book was very much a joint effort.

That said, C is indeed still popular for embedded systems and drivers, where efficiency and the ability to get right down to the hardware matters. I think that changing C today would be counter-productive; one of C's strengths is that it is quite stable. Indeed, I suspect (though without having data to prove it) that except for minor features like // comments most programmers use C as it was after the 1988 ISO standard; the C99 and C11 standards did not change much of programming practice.



Motivation for writing the book
by jameshwang

I was curious out of all the Golang books that currently exists, how does this book, "The Go Programming Language," differ from the rest and fit into the landscape of Golang? I've read some of the other books like "Go Programming Blueprints" and "Go in Action." Specifically with "Go in Action," the table of contents seems similar to your book.

I guess what was your motivation to write this book and how will it be different from all the rest? Brian, are you hoping this book becomes what "The C Programming Language" became but for Golang?

Kernighan: As it says in Ecclesiastes 12:12, "of making many books there is no end", which suggests that your question about whether another book is needed is an old one.

When one writes a book, there is always the belief or at least hope that one can do it "better" than others, not in any negative sense but just that new organization, examples, explanations, and writing will all combine in a way that readers will find helpful. Certainly that has been what Alan and I have tried to achieve with "The Go Programming Language". It would of course be wonderful if the Go book was as helpful to programmers as the C book seems to have been.

I have looked at only a couple of the many Go books that have already been written (and not the ones you mention), and in fact Alan and I quite consciously stopped even looking at titles once we started thinking about our own book, since we didn't want to inadvertently borrow from other authors.

Donovan: For me, one motivation was to write the book I wished I had been able to read when I started learning Go---a comprehensive book that covers not just the language and its library, but one that motivates the design choices, explores advanced features, flags the pitfalls, and conveys the style and aesthetics of the language.

Although comparisons with K&R are inevitable (and flattering), I don't think any technical book can ever be as influential as that one. It was not just a tutorial for the most important language of a (pre-Internet) generation, but also its reference manual and de facto spec. Today, of course, you can browse The Go Tour, Godoc, and The Go Language Specification from your cellphone. Libraries are larger and tooling is more important. A modern book must have a different emphasis. We've tried to show how all the parts fit together.

A few weeks ago you had the chance to ask Alan Donovan and Brian Kernighan about programming and their upcoming book, The Go Programming Language (available as an eBook Friday the 20th). Below you'll find their answers to your questions.
Donovan/Kernighan: Thanks to all the Slashdot readers who posed such thoughtful and provoking questions; we’re sorry that space limitations prevent us from answering more of them. Neither of us is part of the core Go team, so we can’t give authoritative answers for some of the questions that deal with future plans for the language or tools.



OpenGL and LockOSThread
by Anonymous Coward

Hi, I've stopped using Go when I saw the hacky stuff I need to do to get libraries like OpenGL to behave correctly. Are there any plans to fix this?

Donovan: The crux of the problem is that many C libraries such as OpenGL implicitly use the identity of the calling thread to store context information. In some cases, this is because the API was designed before multithreading was the norm, when global variables could be safely used to store context information. In other cases, this design is merely a matter of convenience, since it saves passing an extra parameter to every call.

The designers of Go rejected thread-local storage (TLS) because of its tendency to cause "action at a distance": it makes programs slightly shorter but much harder to read. (See p.282 of our book.) Since the lack of TLS in Go is considered a feature, there are no plans to "fix" it, but it may be possible to make TLS-heavy C libraries work better with Go. My colleague David Crawshaw just gave a talk at DotGo 2015 in Paris about this very issue as it concerns OpenGL.



Why was package versioning left out?
by genocitizen

Why was package versioning left out? And are you guys still fond of this decision? As I use Go more and more I see this to be the weak spot; software has been around for many decades, and we all know that it is continuous evolution. Go's import system does not allow specifying or hinting a version, nor does the `go get` command (although it supports major VCSes), and that's how hacks like gopkg.in have been conceived. And it's not like package managers for other languages haven't already solved in a more or less elegant way the problem already...

Donovan: Go is designed for large programs, and versioning is notoriously hard in that context. About ten years ago, there was an experiment to introduce versioning into Google's build system (which was designed by Rob Pike and others). It failed because of the "diamond dependency" problem, which I'm sure many of you have heard of---it's the classic problem of version numbering. Consider four packages A, B, C, D, where A depends on B and C, and B and C both depend on D. This is a diamond dependency. If the author of B decides that only version 1 of D will do, and the author of C requires at least version 2 of D, you have an impossible set of constraints. If you're lucky, you might be able to build A with both the old and the new versions of D, but in general this doesn't work. Since that experiment, Google hasn't touched automated versioning again. The way we do versioning is simple but manual: we treat each version of a package as a separate entity with a distinct name (for example, "D1", "D2"), and work hard to limit the number of versions of each package---ideally to one. That’s why versioning hasn’t been a priority for us at Google. However, this August, the prolific Dave Cheney proposed a scheme for Go package version numbering, so perhaps we’ll see development of this idea in the near future.



Error Handling in Go
by JPyObjC Dude

Go language differs from many other languages in how it handles Errors. Can you summarize the benefits and drawbacks to the Go language error handling approach when compared to Java for large scale applications.

Kernighan: In general, Go strongly encourages being explicit about errors. The standard library functions almost all return an error status along with the function value and your code must do something with that error status; you can’t just ignore errors. In this respect, Go is similar to Java, where you have to either catch or throw errors; you can't just do nothing. This is a nuisance in small one-off programs, but it's a life-saver in larger ones. So both languages are doing "the right thing".

Where they differ is primarily in the use of exceptions. Go does not have an exception mechanism, so there's no direct way to handle all the errors in a single block as there is with Java's try/catch, though the defer statement can help to consolidate error handling. This means that Java code might be somewhat more compact (in this respect only!), but perhaps at the price of not providing as much precise information about what went wrong.

Our Go book spends quite a bit of time on the topic of error handling, and in most of the examples we've tried to show how to deal with errors properly rather than ignoring them, even though this can make the example programs a bit longer.

Donovan: I’ve written a fair amount of Java code and, in my experience, good error handling is about equally hard in both languages. However, Go reduces the syntactic cost of augmenting an error message as you propagate it, because you have to write more or less the same code whether or not you augment the error with new information. Java, by contrast, makes it so tempting to avoid writing try/catch/throw blocks that, too often, programmers propagate exceptions without thinking. It’s interesting that you can never divine such subtle pragmatic differences between languages merely from reading their specs.



Usage
by Behrooz Amoozad

For what scenarios and projects do You recommend it and for which you recommend against using Go?

Kernighan: Go is a very good general purpose language, and we would have no hesitation about using it for any new task. It seems especially well-suited for programs that involve networking or other concurrent tasks; goroutines are very convenient and efficient, and there is also good support for more traditional shared-memory approaches. Empirically, people who write new networking code tend to like Go. I personally would use it for anything where in the past I might have used C or Java or C++.

Go has also gotten some traction as a scripting language, a potential replacement for large Python scripts. This may seem a bit surprising, since scripting languages are very convenient for cobbling something together in a hurry. The problems come later, when the cobbled-together code starts to crash with type errors or other faults that could have been detected much earlier with a statically typed language. Go won't replace Awk for one-liners, nor is it likely to replace Python or Perl or Ruby for 10- or even 100-line programs, but after a while, the combination of type safety and efficiency is worth the somewhat higher up-front cost.



Why should I use Go?
by aaaaaaargh!

For someone like me who likes garbage collection, multiple dispatch, and extreme abstraction capabilities in high level languages like Common Lisp, and safety, compile-time error detection, readability, and speed in low level languages like Ada or Haskell, what are the benefits of using Go in comparison to these two different types of languages? What new useful features does Go bring?

Kernighan: Ada and (especially) Haskell don't seem like low-level languages and Haskell is inscrutable to newcomers, but those are quibbles. Go has everything you mention in both of your lists of desirable attributes (depending perhaps on what you mean by "extreme abstraction"), but it also provides concurrency in a convenient and efficient form; that's a big win for some kinds of applications.

Donovan: Go seems very plain when compared with languages like Common Lisp, C++, Java, or Python. It has no macros, no templates, no classloaders, no metaclasses. Features such as these are often the first things I, being a PL geek, rush to play with when writing toy programs in a new language, but they are not usually the things that matter the most when programming in the large. I can recall without fondness many days spent debugging overly clever uses of the C++ STL or non-hygienic Lisp macros or the Python __call__ method. The design of Go recognizes that simplicity, homogeneity, and familiarity of a large code base are more valuable to the team as a whole than the benefits to each individual of using their favorite (obscure) language features for each task.



Go’s potential
by Qbertino

What serious long-term real-world potential do you see for Go? How do you see the potential of Go replacing existing open source webstacks such as Apache and PHP, Python or Ruby? Was Go built with a technology update of existing approaches in mind? How feasible is it in your opinion to try and replace the existing complex stacks with pure Go runtimes?

Kernighan: The reason it took God only six days to create the universe is that he didn't have to deal with the embedded base. Realistically, no programming language is likely to completely replace major existing code bases; it's just too much work. Go is often a good choice for new projects or where one is planning to rewrite an existing system anyway, and it can provide a good interface to existing code through foreign function interfaces, particularly to C libraries. But wholesale replacements seem unlikely.

Donovan: I agree with Brian that Go isn’t likely to eliminate any other language or library, but that is not its goal. Go provides an attractive alternative. A good part of Go’s popularity comes from the ease with which you can build useful web servers and other distributed systems using little more than the components of the standard library. The library was produced recently, and thus with the benefit of hindsight, by systems experts, and it often makes third-party servers like Apache or frameworks like Rails unnecessary for the first steps---although of course similar frameworks do exist for Go too.



Official Go IDE?
by Qbertino

Is there an official cross-platform Go IDE in the works? Experience shows that adoption is accelerated by offering a solid toolkit that is easy to pick up and get started with - such as the formidable Android Studio IDE Google offers to developers. Are there any plans similar to this for Go? I would like to see it take the place of C++ in the development of performant end-user applications with GUIs - are there any officially sanctioned projects that aim to provide a serious GUI toolkit and stack based on Go?

Donovan: We agree that good IDE support is important for attracting new users to Go, though my colleagues and I came to this realization rather slowly as, perhaps unsurprisingly, most of us use very traditional editors like Vim, Emacs, SublimeText, and even Acme, which are not what most people think of as IDEs. This year, JetBrains have created a team to develop a Go plugin for IntelliJ so that IntelliJ IDEA users can build, test, debug, and refactor programs written in Go as easily as in any other language.

As for cross-platform GUI toolkits, there’s no canonical solution yet, though there have been some interesting experiments such as GXUI and Shiny.



Should Go replace Java?
by Martinjnh

Should Go replace Java as development platform/language for android?

Donovan: The Go team at Google is working hard to make it possible to use Go to write mobile applications on Android and iOS; see Hana Kim's GopherCon 2015 talk, for example. But for now this is just an experiment and, as Brian wrote above, it's not Go's goal to replace major existing code bases.



Safe Performance
by snadrus

Reimplementing the Gnu+Linux toolchain in GoLang could provide safety that decades of eyes on C could not (thinking about the recent BASH bugs & OpenSSL overruns). Even a small portion would add security to Android. Performance is close & 1.5's library loading should keep executables light. Is there interest in rebuilding Linux's base userland?

Donovan: Go is a good fit for these kinds of tools because the language has good runtime safety and a straightforward system call interface, and it compiles to static executables that start quickly and run efficiently. Portability might be a concern: while Go programs themselves are highly portable, Go's runtime currently targets only a handful of major architectures, far fewer than gcc and glibc support. I'm not aware of any rebuilding projects.



tEoPS
by M. D. Nahas

There many books on "how to program" but few on "how to program well". Brian, your book "The Elements of Programming Style" is a wonderful and a classic, but my students have a hard time reading the examples (Fortran 66 and PL/I). Is there any hope for an update? Is there any similar modern-language book that you recommend?
Michael Nahas (son of Joe Nahas)

P.S. I totally stole as much as I could from you when writing my tutorial for the language Coq. Sorry/Thanks!

Kernighan: The languages that Bill Plauger and I used in "The Elements of Programming Style" are either long gone (PL/1) or very much evolved (Fortran), so the code is indeed hard to read today, though most of the rules of good style are still valid. Bill and I once started a version in C but didn't get very far. One problem was that the original book relied almost exclusively on code fragments from textbooks. Modern textbooks are far better than they were 40 years ago; most code is syntactically correct and mostly works. So it was hard for us to find textbook examples to illustrate our rules. Another problem is that real programs are a lot bigger and more complicated than they were, and it's hard to find excerpts that would work in a book. So an update of EOPS isn't likely, much as it would be nice to have one.

As to other books, Josh Bloch and Scott Meyers have written excellent books on how to write good Java and C++ respectively. More broadly, I have always liked Steve McConnell's "Code Complete", and I take a fresh look at Fred Brooks's classic "The Mythical Man Month" every few years. There are plenty of other books about how to program well in various languages and environments; it's well worth reading some of them to see how other authors approach the topic.



C's current place in the world
by MountainLogic

As the legend has it, C was created to support operating system development. As time has gone by C++ has slipped into OS development on larger platforms. It seems that much of the current core use of mother C is centering on embedded processors (all the way down to 8 bit micros with 256 bytes of RAM) and drivers in larger systems. For current use what design choices in C do you see as wise and what would you change given the current usage of C. (P.S. Thank you for co-authoring the most wonderful, perfect, clear and concise technology document ever.)

Kernighan: Bear in mind that C is Dennis Ritchie's work; I can only claim to have written a book with him. Dennis was a great writer as well as a great programmer and language designer, and the book was very much a joint effort.

That said, C is indeed still popular for embedded systems and drivers, where efficiency and the ability to get right down to the hardware matters. I think that changing C today would be counter-productive; one of C's strengths is that it is quite stable. Indeed, I suspect (though without having data to prove it) that except for minor features like // comments most programmers use C as it was after the 1988 ISO standard; the C99 and C11 standards did not change much of programming practice.



Motivation for writing the book
by jameshwang

I was curious out of all the Golang books that currently exists, how does this book, "The Go Programming Language," differ from the rest and fit into the landscape of Golang? I've read some of the other books like "Go Programming Blueprints" and "Go in Action." Specifically with "Go in Action," the table of contents seems similar to your book.

I guess what was your motivation to write this book and how will it be different from all the rest? Brian, are you hoping this book becomes what "The C Programming Language" became but for Golang?

Kernighan: As it says in Ecclesiastes 12:12, "of making many books there is no end", which suggests that your question about whether another book is needed is an old one.

When one writes a book, there is always the belief or at least hope that one can do it "better" than others, not in any negative sense but just that new organization, examples, explanations, and writing will all combine in a way that readers will find helpful. Certainly that has been what Alan and I have tried to achieve with "The Go Programming Language". It would of course be wonderful if the Go book was as helpful to programmers as the C book seems to have been.

I have looked at only a couple of the many Go books that have already been written (and not the ones you mention), and in fact Alan and I quite consciously stopped even looking at titles once we started thinking about our own book, since we didn't want to inadvertently borrow from other authors.

Donovan: For me, one motivation was to write the book I wished I had been able to read when I started learning Go---a comprehensive book that covers not just the language and its library, but one that motivates the design choices, explores advanced features, flags the pitfalls, and conveys the style and aesthetics of the language.

Although comparisons with K&R are inevitable (and flattering), I don't think any technical book can ever be as influential as that one. It was not just a tutorial for the most important language of a (pre-Internet) generation, but also its reference manual and de facto spec. Today, of course, you can browse The Go Tour, Godoc, and The Go Language Specification from your cellphone. Libraries are larger and tooling is more important. A modern book must have a different emphasis. We've tried to show how all the parts fit together.

A few weeks ago you had the chance to ask Alan Donovan and Brian Kernighan about programming and their upcoming book, The Go Programming Language (available as an eBook Friday the 20th). Below you'll find their answers to your questions.
Donovan/Kernighan: Thanks to all the Slashdot readers who posed such thoughtful and provoking questions; we’re sorry that space limitations prevent us from answering more of them. Neither of us is part of the core Go team, so we can’t give authoritative answers for some of the questions that deal with future plans for the language or tools.



OpenGL and LockOSThread
by Anonymous Coward

Hi, I've stopped using Go when I saw the hacky stuff I need to do to get libraries like OpenGL to behave correctly. Are there any plans to fix this?

Donovan: The crux of the problem is that many C libraries such as OpenGL implicitly use the identity of the calling thread to store context information. In some cases, this is because the API was designed before multithreading was the norm, when global variables could be safely used to store context information. In other cases, this design is merely a matter of convenience, since it saves passing an extra parameter to every call.

The designers of Go rejected thread-local storage (TLS) because of its tendency to cause "action at a distance": it makes programs slightly shorter but much harder to read. (See p.282 of our book.) Since the lack of TLS in Go is considered a feature, there are no plans to "fix" it, but it may be possible to make TLS-heavy C libraries work better with Go. My colleague David Crawshaw just gave a talk at DotGo 2015 in Paris about this very issue as it concerns OpenGL.



Why was package versioning left out?
by genocitizen

Why was package versioning left out? And are you guys still fond of this decision? As I use Go more and more I see this to be the weak spot; software has been around for many decades, and we all know that it is continuous evolution. Go's import system does not allow specifying or hinting a version, nor does the `go get` command (although it supports major VCSes), and that's how hacks like gopkg.in have been conceived. And it's not like package managers for other languages haven't already solved in a more or less elegant way the problem already...

Donovan: Go is designed for large programs, and versioning is notoriously hard in that context. About ten years ago, there was an experiment to introduce versioning into Google's build system (which was designed by Rob Pike and others). It failed because of the "diamond dependency" problem, which I'm sure many of you have heard of---it's the classic problem of version numbering. Consider four packages A, B, C, D, where A depends on B and C, and B and C both depend on D. This is a diamond dependency. If the author of B decides that only version 1 of D will do, and the author of C requires at least version 2 of D, you have an impossible set of constraints. If you're lucky, you might be able to build A with both the old and the new versions of D, but in general this doesn't work. Since that experiment, Google hasn't touched automated versioning again. The way we do versioning is simple but manual: we treat each version of a package as a separate entity with a distinct name (for example, "D1", "D2"), and work hard to limit the number of versions of each package---ideally to one. That’s why versioning hasn’t been a priority for us at Google. However, this August, the prolific Dave Cheney proposed a scheme for Go package version numbering, so perhaps we’ll see development of this idea in the near future.



Error Handling in Go
by JPyObjC Dude

Go language differs from many other languages in how it handles Errors. Can you summarize the benefits and drawbacks to the Go language error handling approach when compared to Java for large scale applications.

Kernighan: In general, Go strongly encourages being explicit about errors. The standard library functions almost all return an error status along with the function value and your code must do something with that error status; you can’t just ignore errors. In this respect, Go is similar to Java, where you have to either catch or throw errors; you can't just do nothing. This is a nuisance in small one-off programs, but it's a life-saver in larger ones. So both languages are doing "the right thing".

Where they differ is primarily in the use of exceptions. Go does not have an exception mechanism, so there's no direct way to handle all the errors in a single block as there is with Java's try/catch, though the defer statement can help to consolidate error handling. This means that Java code might be somewhat more compact (in this respect only!), but perhaps at the price of not providing as much precise information about what went wrong.

Our Go book spends quite a bit of time on the topic of error handling, and in most of the examples we've tried to show how to deal with errors properly rather than ignoring them, even though this can make the example programs a bit longer.

Donovan: I’ve written a fair amount of Java code and, in my experience, good error handling is about equally hard in both languages. However, Go reduces the syntactic cost of augmenting an error message as you propagate it, because you have to write more or less the same code whether or not you augment the error with new information. Java, by contrast, makes it so tempting to avoid writing try/catch/throw blocks that, too often, programmers propagate exceptions without thinking. It’s interesting that you can never divine such subtle pragmatic differences between languages merely from reading their specs.



Usage
by Behrooz Amoozad

For what scenarios and projects do You recommend it and for which you recommend against using Go?

Kernighan: Go is a very good general purpose language, and we would have no hesitation about using it for any new task. It seems especially well-suited for programs that involve networking or other concurrent tasks; goroutines are very convenient and efficient, and there is also good support for more traditional shared-memory approaches. Empirically, people who write new networking code tend to like Go. I personally would use it for anything where in the past I might have used C or Java or C++.

Go has also gotten some traction as a scripting language, a potential replacement for large Python scripts. This may seem a bit surprising, since scripting languages are very convenient for cobbling something together in a hurry. The problems come later, when the cobbled-together code starts to crash with type errors or other faults that could have been detected much earlier with a statically typed language. Go won't replace Awk for one-liners, nor is it likely to replace Python or Perl or Ruby for 10- or even 100-line programs, but after a while, the combination of type safety and efficiency is worth the somewhat higher up-front cost.



Why should I use Go?
by aaaaaaargh!

For someone like me who likes garbage collection, multiple dispatch, and extreme abstraction capabilities in high level languages like Common Lisp, and safety, compile-time error detection, readability, and speed in low level languages like Ada or Haskell, what are the benefits of using Go in comparison to these two different types of languages? What new useful features does Go bring?

Kernighan: Ada and (especially) Haskell don't seem like low-level languages and Haskell is inscrutable to newcomers, but those are quibbles. Go has everything you mention in both of your lists of desirable attributes (depending perhaps on what you mean by "extreme abstraction"), but it also provides concurrency in a convenient and efficient form; that's a big win for some kinds of applications.

Donovan: Go seems very plain when compared with languages like Common Lisp, C++, Java, or Python. It has no macros, no templates, no classloaders, no metaclasses. Features such as these are often the first things I, being a PL geek, rush to play with when writing toy programs in a new language, but they are not usually the things that matter the most when programming in the large. I can recall without fondness many days spent debugging overly clever uses of the C++ STL or non-hygienic Lisp macros or the Python __call__ method. The design of Go recognizes that simplicity, homogeneity, and familiarity of a large code base are more valuable to the team as a whole than the benefits to each individual of using their favorite (obscure) language features for each task.



Go’s potential
by Qbertino

What serious long-term real-world potential do you see for Go? How do you see the potential of Go replacing existing open source webstacks such as Apache and PHP, Python or Ruby? Was Go built with a technology update of existing approaches in mind? How feasible is it in your opinion to try and replace the existing complex stacks with pure Go runtimes?

Kernighan: The reason it took God only six days to create the universe is that he didn't have to deal with the embedded base. Realistically, no programming language is likely to completely replace major existing code bases; it's just too much work. Go is often a good choice for new projects or where one is planning to rewrite an existing system anyway, and it can provide a good interface to existing code through foreign function interfaces, particularly to C libraries. But wholesale replacements seem unlikely.

Donovan: I agree with Brian that Go isn’t likely to eliminate any other language or library, but that is not its goal. Go provides an attractive alternative. A good part of Go’s popularity comes from the ease with which you can build useful web servers and other distributed systems using little more than the components of the standard library. The library was produced recently, and thus with the benefit of hindsight, by systems experts, and it often makes third-party servers like Apache or frameworks like Rails unnecessary for the first steps---although of course similar frameworks do exist for Go too.



Official Go IDE?
by Qbertino

Is there an official cross-platform Go IDE in the works? Experience shows that adoption is accelerated by offering a solid toolkit that is easy to pick up and get started with - such as the formidable Android Studio IDE Google offers to developers. Are there any plans similar to this for Go? I would like to see it take the place of C++ in the development of performant end-user applications with GUIs - are there any officially sanctioned projects that aim to provide a serious GUI toolkit and stack based on Go?

Donovan: We agree that good IDE support is important for attracting new users to Go, though my colleagues and I came to this realization rather slowly as, perhaps unsurprisingly, most of us use very traditional editors like Vim, Emacs, SublimeText, and even Acme, which are not what most people think of as IDEs. This year, JetBrains have created a team to develop a Go plugin for IntelliJ so that IntelliJ IDEA users can build, test, debug, and refactor programs written in Go as easily as in any other language.

As for cross-platform GUI toolkits, there’s no canonical solution yet, though there have been some interesting experiments such as GXUI and Shiny.



Should Go replace Java?
by Martinjnh

Should Go replace Java as development platform/language for android?

Donovan: The Go team at Google is working hard to make it possible to use Go to write mobile applications on Android and iOS; see Hana Kim's GopherCon 2015 talk, for example. But for now this is just an experiment and, as Brian wrote above, it's not Go's goal to replace major existing code bases.



Safe Performance
by snadrus

Reimplementing the Gnu+Linux toolchain in GoLang could provide safety that decades of eyes on C could not (thinking about the recent BASH bugs & OpenSSL overruns). Even a small portion would add security to Android. Performance is close & 1.5's library loading should keep executables light. Is there interest in rebuilding Linux's base userland?

Donovan: Go is a good fit for these kinds of tools because the language has good runtime safety and a straightforward system call interface, and it compiles to static executables that start quickly and run efficiently. Portability might be a concern: while Go programs themselves are highly portable, Go's runtime currently targets only a handful of major architectures, far fewer than gcc and glibc support. I'm not aware of any rebuilding projects.



tEoPS
by M. D. Nahas

There many books on "how to program" but few on "how to program well". Brian, your book "The Elements of Programming Style" is a wonderful and a classic, but my students have a hard time reading the examples (Fortran 66 and PL/I). Is there any hope for an update? Is there any similar modern-language book that you recommend?
Michael Nahas (son of Joe Nahas)

P.S. I totally stole as much as I could from you when writing my tutorial for the language Coq. Sorry/Thanks!

Kernighan: The languages that Bill Plauger and I used in "The Elements of Programming Style" are either long gone (PL/1) or very much evolved (Fortran), so the code is indeed hard to read today, though most of the rules of good style are still valid. Bill and I once started a version in C but didn't get very far. One problem was that the original book relied almost exclusively on code fragments from textbooks. Modern textbooks are far better than they were 40 years ago; most code is syntactically correct and mostly works. So it was hard for us to find textbook examples to illustrate our rules. Another problem is that real programs are a lot bigger and more complicated than they were, and it's hard to find excerpts that would work in a book. So an update of EOPS isn't likely, much as it would be nice to have one.

As to other books, Josh Bloch and Scott Meyers have written excellent books on how to write good Java and C++ respectively. More broadly, I have always liked Steve McConnell's "Code Complete", and I take a fresh look at Fred Brooks's classic "The Mythical Man Month" every few years. There are plenty of other books about how to program well in various languages and environments; it's well worth reading some of them to see how other authors approach the topic.



C's current place in the world
by MountainLogic

As the legend has it, C was created to support operating system development. As time has gone by C++ has slipped into OS development on larger platforms. It seems that much of the current core use of mother C is centering on embedded processors (all the way down to 8 bit micros with 256 bytes of RAM) and drivers in larger systems. For current use what design choices in C do you see as wise and what would you change given the current usage of C. (P.S. Thank you for co-authoring the most wonderful, perfect, clear and concise technology document ever.)

Kernighan: Bear in mind that C is Dennis Ritchie's work; I can only claim to have written a book with him. Dennis was a great writer as well as a great programmer and language designer, and the book was very much a joint effort.

That said, C is indeed still popular for embedded systems and drivers, where efficiency and the ability to get right down to the hardware matters. I think that changing C today would be counter-productive; one of C's strengths is that it is quite stable. Indeed, I suspect (though without having data to prove it) that except for minor features like // comments most programmers use C as it was after the 1988 ISO standard; the C99 and C11 standards did not change much of programming practice.



Motivation for writing the book
by jameshwang

I was curious out of all the Golang books that currently exists, how does this book, "The Go Programming Language," differ from the rest and fit into the landscape of Golang? I've read some of the other books like "Go Programming Blueprints" and "Go in Action." Specifically with "Go in Action," the table of contents seems similar to your book.

I guess what was your motivation to write this book and how will it be different from all the rest? Brian, are you hoping this book becomes what "The C Programming Language" became but for Golang?

Kernighan: As it says in Ecclesiastes 12:12, "of making many books there is no end", which suggests that your question about whether another book is needed is an old one.

When one writes a book, there is always the belief or at least hope that one can do it "better" than others, not in any negative sense but just that new organization, examples, explanations, and writing will all combine in a way that readers will find helpful. Certainly that has been what Alan and I have tried to achieve with "The Go Programming Language". It would of course be wonderful if the Go book was as helpful to programmers as the C book seems to have been.

I have looked at only a couple of the many Go books that have already been written (and not the ones you mention), and in fact Alan and I quite consciously stopped even looking at titles once we started thinking about our own book, since we didn't want to inadvertently borrow from other authors.

Donovan: For me, one motivation was to write the book I wished I had been able to read when I started learning Go---a comprehensive book that covers not just the language and its library, but one that motivates the design choices, explores advanced features, flags the pitfalls, and conveys the style and aesthetics of the language.

Although comparisons with K&R are inevitable (and flattering), I don't think any technical book can ever be as influential as that one. It was not just a tutorial for the most important language of a (pre-Internet) generation, but also its reference manual and de facto spec. Today, of course, you can browse The Go Tour, Godoc, and The Go Language Specification from your cellphone. Libraries are larger and tooling is more important. A modern book must have a different emphasis. We've tried to show how all the parts fit together.

An anonymous reader writes: Microsoft today unleashed a torrent of news at its Connect(); 2015 developer event in New York City. The company open-sourced code editing software Visual Studio Code, launched a free Visual Studio Dev Essentials program, pushed out .NET Core 5 and ASP.NET 5 release candidates, unveiled Visual Studio cloud subscriptions, debuted the Visual Studio Marketplace, and a lot more. The source for Visual Studio Code is available at GitHub under the MIT license. They've also released an extension (preview) for Visual Studio that facilitates code debugging on Linux.

smaxp writes: Google has announced the open source release of TensorFlow, its machine learning software library. "TensorFlow has extensive built-in support for deep learning, but is far more general than that -- any computation that you can express as a computational flow graph, you can compute with TensorFlow (see some examples). Any gradient-based machine learning algorithm will benefit from TensorFlow’s auto-differentiation and suite of first-rate optimizers. And it’s easy to express your new ideas in TensorFlow via the flexible Python interface." This comes alongside some dramatic speed increases (PDF). The code is available at GitHub under an Apache 2.0 license. "Deep learning, machine learning, and artificial intelligence are all some of Google's core competencies, where the company leads Apple and Microsoft. If successful, Google's strategy is to maintain this lead by putting its technology out in the open to improve it based on large-scale adoption and code contributions from the community at large.

An anonymous reader writes: Researchers from the Delft University of Technology have developed a self-replicating, mutating Android app which can create on-the-fly mesh networks in the event of an infrastructural disaster, or the enabling of internet kill switches by oppressive regimes. The app's source is available at GitHub, and the app itself requires no root privileges to propagate. It can self-compile while it mutates — for example, from a game to a calculator — in transit from one Android device to another, and compatibility with iOS and Windows phones is anticipated.

theodp writes: At first glance, the proposal for A Code of Conduct for the Go Community (attributed to Google's Andrew Gerrand) seems reasonable enough. How can you argue with the goal of treating everyone with respect and kindness? But the Devil is in the detail, and the proposed Code notes there soon could be consequences for calling someone an "idiot" or saying something is "so simple even my grandma could understand it" (the latter "marginalises women and the elderly by implying that something need be simple for an old woman to understand it"). And the punishment meted out by the Go Code of Conduct Working Group to those who find themselves on the receiving end of an anonymous complaint could be anything from nothing to "a request for a private or public apology, a private reprimand from the working group to the individual(s) involved, a public reprimand, an imposed vacation (for instance, asking someone to 'take a week off' from a mailing list or IRC), or a permanent or temporary ban from some or all Go spaces (mailing lists, IRC, etc.)." And no, this doesn't appear to be a goof. So, might individuals and companies think twice about embracing a programming language whose community's Code of Conduct threatens to ruin reputations and ban people from technical support resources for life? Too late to get this added to the list of questions for Alan Donovan and Brian Kernighan?

JustAnotherOldGuy writes: Mimic implements a devilishly sick idea floated on Twitter by Peter Ritchie: "Replace a semicolon (;) with a Greek question mark (;) in your friend's C# code and watch them pull their hair out over the syntax error." There are quite a few characters in the Unicode character set that look, to some extent or another, like others – homoglyphs. Mimic substitutes common ASCII characters for obscure homoglyphs. Caution: using this script may get you fired and/or beaten to a pulp.

JustAnotherOldGuy writes: Mimic implements a devilishly sick idea floated on Twitter by Peter Ritchie: "Replace a semicolon (;) with a Greek question mark (;) in your friend's C# code and watch them pull their hair out over the syntax error." There are quite a few characters in the Unicode character set that look, to some extent or another, like others – homoglyphs. Mimic substitutes common ASCII characters for obscure homoglyphs. Caution: using this script may get you fired and/or beaten to a pulp.

An anonymous reader writes: The U.S. General Services Administration has a team within it called 18F. They describe themselves as an open source, digital services delivery team. In other words, they create software for use by citizens and other government agencies, and the software they produce is open source. Starting next Monday, October 26, they're trying out an interesting new experiment for procuring open source code. Like any other agency, they have a budget, and they're allowed to contract out work when it makes sense to do so. But there's a difference between big projects and small ones.

If their purchase doesn't exceed $3,500, they have the authority to just do it. Higher than $3,500, and they (not to mention the contractors) have to deal with a bunch of extra red tape. This brings us to their experiment. They're developing a system that will let developers bid on small software projects the GSA needs. It starts at the cap for "micro-purchases," $3,499, and developers can bid it down if they feel it's easier. Once a bid is selected, the developer(s) have 10 working days to send back functioning code with a specific set of acceptance criteria. 18F isn't sure how well it'll work, but it's a cool way to try and make it easier for the open source community to build things for the government.

An anonymous reader writes: Intel is open-sourcing their work on creating a high-performance graphics software rasterizer that originally was developed for scientific visualizations. Intel is planning to integrate this new OpenSWR project with Mesa to deploy it on the Linux desktop as a faster software rasterizer than what's currently available (LLVMpipe). OpenSWR should be ideal for cases where there isn't a discrete GPU available or the drivers fail to function. This software rasterizer implements OpenGL 3.2 on Intel/AMD CPUs supporting AVX(2) (Sandy Bridge / Bulldozer and newer) while being 29~51x faster than LLVMpipe and the code is MIT licensed. The code prior to being integrated in Mesa is offered on GitHub.

An anonymous reader writes: Microsoft has published early source code for its OpenSSH-for-Windows port for developers to pick apart and improve. In a blog post on Monday, Steve Lee – the PowerShell team's principal software engineer manager – said Redmond has finished early work on a Windows port of OpenSSH 7.1, built in a joint-effort with NoMachine. Their rough roadmap from here: 1) Leverage Windows crypto APIs instead of OpenSSL/LibreSSL and run as Windows Service. 2) Address POSIX compatibility concerns. 3) Stabilize the code and address reported issues. 4) Production quality release.

An anonymous reader writes: According to VentureBeat Red Hat Inc is about to buy the company behind the automation and orchestration software Ansible. The move is seen as a good acquisition, since Ansible, other than being almost universally expanding, is also used by Red Hat's own cloud and system platforms. It could probably use some strong backing for the extra services it wishes to offer. The question remains whether this will have consequences in the future direction of the Python-based, open source platform itself (on GitHub). It's one of the most trivial to implement (compared to cfengine, ever-changing puppet or Chef) yet very powerful, and Red Hat may want to optimize it for their own purposes. Update: 10/16 15:39 GMT by S : Red Hat has confirmed the acquisition and explained their reasons for doing so.

An anonymous reader writes: Wayland 1.9 and the reference Weston compositor have been ported to DragonFlyBSD. Significant changes were made to get Wayland/Weston running, and you must either already be running an X.Org Server or be using the Linux-ported Radeon and Intel kernel mode-setting drivers, plus jump through a few setup steps.

theodp writes: Several weeks ago, Google launched Brotli, a new open source compression algorithm for the web. Since then, controversy broke out over the choice of 'bro' as the content encoding type. "We are hoping to establish a file ending .bro for brotli compressed files, a command line tool 'bro' for compressing and uncompressing brotli files, and a accept/content encoding type 'bro'," explained Google software engineer Jyrki Alakuijala. "Can I talk you out of it?," replied Mozilla SW engineer Patrick McManus. "'bro' has a gender problem, even though the dual meaning is unintentional. It comes of[f] misogynistic and unprofessional due to the world it lives in." Despite some pushback from commenters, a GitHub commit made by Google's Zoltan Szabadka shows that there will be no '.bro' in Brotli. "I have asked a feminist friend from the North American culture-sphere, and she advised against bro," explained Alakuijala. "We have found a compromise that satisfies us, so we don't need to discuss this further. Even if we don't understand why people are upset from our cultural standpoint, they would be (unnecessarily) upset and this is enough reason not to use it."

An anonymous reader writes: CloudFlare's content delivery network relies on their ability to shuffle data around. As they've scaled up, they've run into some interesting technical limits on how fast they can manage this. Last month they explained how the unmodified Linux kernel can only handle about 1 million packets per second, when easily-available NICs can manage 10 times that. So, they did what you're supposed to do when you encounter a problem with open source software: they developed a patch for the Netmap project to increase throughput. "Usually, when a network card goes into the Netmap mode, all the RX queues get disconnected from the kernel and are available to the Netmap applications. We don't want that. We want to keep most of the RX queues back in the kernel mode, and enable Netmap mode only on selected RX queues. We call this functionality: 'single RX queue mode.'" With their changes, Netmap was able to receive about 5.8 million packets per second. Their patch is currently awaiting review.

An anonymous reader writes: Dhewm3, one of the leading implementations of the Doom 3 engine built off the open-source id Tech 4 engine, has released a new version of the GPL-licensed engine that takes Doom 3 far beyond where it was left off by id Software. The newest code has full SDL support, OpenAL + OpenAL EFX for audio, 64-bit x86/ARM support, better support for widescreen resolutions, and CMake build system support on Linux/Windows/OSX/FreeBSD. This new open-source code can be downloaded from Dhewm3 on GitHub but continues to depend upon the retail Doom 3 game assets.

An anonymous reader writes: Google has officially taken the wraps off its AMP project — Accelerated Mobile Pages — which aims to speed up the delivery of web content to mobile devices. They say, "We began to experiment with an idea: could we develop a restricted subset of the things we'd use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance?" That subset is now encapsulated in AMP, their proof-of-concept. They've posted the code to GitHub and they're asking for help from the open source community to flesh it out. Their conclusions are familiar to the Slashdot crowd: "One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn't saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts." They're seeing speed boosts anywhere from 15-85%, but they're also looking at pre-rendering options to make some content capable of loading instantaneously. Their FAQ has a few more details.

An anonymous reader writes: Thanks to a recently published open source music editor/sequencer, you can now create music on Texas Instruments graphing calculators. The complexity of the sound is impressive (video) for such a simple device, which does not feature any dedicated sound hardware. HoustonTracker 2 is open source, and is available for the TI-82, 83, 83Plus, and 84Plus.

jones_supa writes: Just like Sarah Sharp, Linux developer Matthew Garrett has gotten fed up with the unprofessional development culture surrounding the kernel. "I remember having to deal with interminable arguments over the naming of an interface because Linus has an undying hatred of BSD securelevel, or having my name forever associated with the deepthroating of Microsoft because Linus couldn't be bothered asking questions about the reasoning behind a design before trashing it," Garrett writes. He has chosen to go his own way, and has forked the Linux kernel and added patches that implement a BSD-style securelevel interface. Over time it is expected to pick up some of the power management code that Garrett is working on, and we shall see where it goes from there.

nickweller sends a link to an informational post about FLIF, the Free, Lossless Image Format. It claims to outperform PNG, lossless WebP, and other popular formats on any kind of image. "On photographs, PNG performs poorly while WebP, BPG and JPEG 2000 compress well (see plot on the left). On medical images, PNG and WebP perform relatively poorly while BPG and JPEG 2000 work well (see middle plot). On geographical maps, BPG and JPEG 2000 perform (extremely) poorly while while PNG and WebP work well (see plot on the right). In each of these three examples, FLIF performs well — even better than any of the others." FLIF uses progressive decoding to provide fully-formed lossy images from partial downloads in bandwidth-constrained situations. Best of all, FLIF is free software, released under the GNU GPLv3.

alphabetsoup writes: At CppCon this year, Bjarne Stroustrup announced the C++ Core Guidelines. The guidelines are designed to help programmers write safe-by-default C++ with no run-time overhead. Compilers will statically check the code to ensure no violations. A library is available now, with a static checking tool to follow in October.

Here is the video of the talk, and here are the slides.The guidelines themselves are here.

alphabetsoup writes: At CppCon this year, Bjarne Stroustrup announced the C++ Core Guidelines. The guidelines are designed to help programmers write safe-by-default C++ with no run-time overhead. Compilers will statically check the code to ensure no violations. A library is available now, with a static checking tool to follow in October.

Here is the video of the talk, and here are the slides.The guidelines themselves are here.

alphabetsoup writes: At CppCon this year, Bjarne Stroustrup announced the C++ Core Guidelines. The guidelines are designed to help programmers write safe-by-default C++ with no run-time overhead. Compilers will statically check the code to ensure no violations. A library is available now, with a static checking tool to follow in October.

Here is the video of the talk, and here are the slides.The guidelines themselves are here.

New submitter mutherhacker writes: A group from Osaka University in Japan and McMaster University in Canada have presented a method to control a virtual 3D object using a smartphone [video]. The method was primarily designed for presentations but also applies to virtual reality using a head mounted display, gaming or even quadrocopter control. There is an open paper online as well as a git repository for both the client and the server. The client smartphone communicates with the main computer over the network with TUIO for touch and Google protocol buffers for orientation sensor data.

New submitter mutherhacker writes: A group from Osaka University in Japan and McMaster University in Canada have presented a method to control a virtual 3D object using a smartphone [video]. The method was primarily designed for presentations but also applies to virtual reality using a head mounted display, gaming or even quadrocopter control. There is an open paper online as well as a git repository for both the client and the server. The client smartphone communicates with the main computer over the network with TUIO for touch and Google protocol buffers for orientation sensor data.

New submitter mutherhacker writes: A group from Osaka University in Japan and McMaster University in Canada have presented a method to control a virtual 3D object using a smartphone [video]. The method was primarily designed for presentations but also applies to virtual reality using a head mounted display, gaming or even quadrocopter control. There is an open paper online as well as a git repository for both the client and the server. The client smartphone communicates with the main computer over the network with TUIO for touch and Google protocol buffers for orientation sensor data.

New submitter TFlan91 writes: The first merge of the popular Node.js and io.js repositories has been released! From the announcement: "The collaborators of the Node.js project and the members of the Node.js Foundation are proud to offer v4.0.0 for general release. This release represents countless hours of hard work encapsulated in both the Node.js project and the io.js project that are now combined in a single codebase. The Node.js project is now operated by a team of 44 collaborators, 15 of which form its Technical Steering Committee (TSC). Further, over 100 new individuals have been added to the list of people contributing code to core since v0.12.7."

jones_supa writes: With a pull request systemd now supports a su command functional and can create privileged sessions that are fully isolated from the original session. The su command is seen as bad because what it is supposed to do is ambiguous. On one hand it's supposed to open a new session and change a number of execution context parameters, and on the other it's supposed to inherit a lot concepts from the originating session. Lennart Poettering's long story short: "`su` is really a broken concept. It will given you kind of a shell, and it's fine to use it for that, but it's not a full login, and shouldn't be mistaken for one." The replacement command provided by systemd is machinectl shell.

An anonymous reader writes: In Dropbox's "Hack Week" this year, a team of ten engineers built the fantasy Pied Piper algorithm from HBO's Silicon Valley, achieving 13% lossless compression on Mobile-recorded H.264 videos and 22% on arbitrary JPEG files. Their algorithm can return the compressed files to their bit-exact values. According to FastCompany, "Its ability to compress file sizes could actually have tangible, real-world benefits for Dropbox, whose core business is storing files in the cloud."The code is available on GitHub under a BSD license for people interested in advancing the compression or archiving their movie files.

An anonymous reader writes: Microsoft's new browser, Edge, has a new rendering engine, EdgeHTML. Like Edge, the new rendering engine is only available in Windows 10, but it does more than just power the company's new browser: It's also readily available to developers. To show off what EdgeHTML can do, Microsoft has built a browser using predominantly JavaScript, HTML, and CSS. Next, the company released the browser on the Windows Store and the sample code on GitHub.

Last week you had a chance to ask Dr. Tarek Loubani about his 3D-printable, 30-cent stethoscope project, and other open source, ultra-low cost medical equipment. Below you'll find his answers to your questions. What about patents?
by ciaran2014

Most activities that can be performed commercially but which can also be performed non-commercially are either exempt from patents or never get prosecuted. Fixing other people's bicycles, writing a book, and performing music come to mind. (Software development is a grey area.) But 3D printing is taking an activity where efficient production on any reasonable scale was pretty much the exclusive domain of businesses, and making it accessible to DIY-ers and people who would do it while doing their job or performing some task at home, without any direct commercial aspect. Any idea what stage the debate is at regarding patent restrictions on printing or distributing designs for things more complicated or more modern than stethoscopes?

Tarek: This project does not aim to innovate as such. We aim to drop the bottom out of the costs on devices whose patents have long since expired. We might be trolled, harassed and sued into oblivion, but not because we are in violation of any patents. Indeed, the patents that cover the stethoscope we made are long expired US3168160, filed in 1962; US3108652, filed in 1960; US3515239, filed in 1968. The patents that cover a few small innovations in the Littmann Cardiology III expire in just a couple of years US5945640, but fundamentally the tech is ancient.

It's the same for pulse oximetry. Same for electrocardiograms.

Regarding your overarching question, brilliant minds like Geist, Doctorow, Stallman, etc. might be better positioned to answer. My hope, of course, is that the copyright bargain turns in favour of users and citizens sooner rather than later.



Was your stethoscope 3D printed in Gaza?
by mrops

It seems there are a lot of restrictions on what can be imported into gaza as there is a risk technologies might fall into terrorist hands and used for nefarious purpose. Under this, is it really possible to import a 3D printer into gaza for such tasks?

Tarek: There are already 3D printers in Gaza. Those who have made Prusa i3 printers know that it's trivial to make one from salvaged parts taken from old inkjet and laser printers. These printers will be used in the production of prosthetics and medical devices.

Those who support the blockade or oppose the rights of patients in Gaza to access health care might contend that 3D printers could be used to make weaponry. This is a ridiculous claim: Gaza has hundreds of CNC routers, and most of the weaponry currently in the hands of the Palestinian resistance was either captured from Fatah forces during an “attempted coup” (David Wurmser's words) in 2007 or smuggled, mostly via tunnels under the Egyptian border. The armed resistance groups in Gaza are not waiting for us to bring in 3D printers. If they wanted them, they'd have brought them in with the last batch of rockets.



Are medical devices restricted?
by Anonymous Coward

I see lots of stuff blamed on the import restrictions, but are medical devices actually blockaded, or are they stopped because they're used as a cover to smuggle in other things?

Tarek: According to Gisha, an Israeli NGO, the blockade is “not in order to protect against security threats ... but rather as part of a policy to apply 'pressure' or 'sanctions' on the Hamas regime.” Your question assumes that the blockade is security instead of sanction, which is not the case. Even so, there has never been smuggling of illicit items into Gaza under the cover of medical supplies.

Israel does not declare the list of banned items, but claims that medicines are not banned (see this partial list of banned items, but MSF and others report chronic severe shortages of medical supplies. The World Health Organization reported in 2011 that “shortages of the 190 medical disposable items include some basic and very critical items such as: syringes, Central Venous Pressure devices, ECG and CTG paper, X-Ray film, gauze, disposables used in laparoscopies, and filtration cartridges used in haemodialysis for patients with kidney failure.”

Frankly, I have never cared about why. In Gaza, it's blockade. In Democratic Republic of Congo it's war. In Rwanda, it's poverty. The end result is the same: The denial of health care to the world's most vulnerable people. Everyone deserves health care. This project is about ensuring that doctors and patients in Gaza and elsewhere can alleviate their own suffering without waiting for international law and public goodwill to catch up with illegal occupations, collective punishments and colonial legacies.



3D Printing, catalyst for Intermediate Technology?
by Anonymous Coward

Your 30-cent stethoscope seems to be an excellent example of "Intermediate Technology" (or “Appropriate Technology“) as popularized by Dr Hans Schumacher in his influential book, Small is Beautiful. Do you think that 3D printing will become increasingly important in the third world with regards to improving basic medicine, agriculture etc?

Tarek: I see my 3D printer as a portable factory. It can't do all the same things at the same scales, but it is possible for people in very poor places to create high precision plastic parts that were previously impossible. Because these parts are created from digital models, it also allows collaboration via open source models, as we see on various model repositories. Open source models and repositories are where I think exponential achievements are happening today.

3D printing then becomes one of the ingredients in the empowering of disenfranchised people to take control and come up with indigenous solutions to problems.



Local making of tools
by fortunatus

While reviewing the online repository for the stethoscope design, I saw that mainly it's the sound gathering part that is 3D printed. The rest is - reasonably - made out of regular stuff. So then, with some regular stuff, can't local people figure out how to make stethoscopes? They really can't figure out that one sound gathering piece? It takes a doctor/hacker to come from some land far away bearing the URL to a 3D printable part to solve the problem?

Tarek: You're right - there is nothing special here, and I embrace my mediocrity as a doctor and geek. Somebody just had to do a bit of work and spend a bit of money. I don't consider myself to be from some “land far away”: I am Palestinian and lived as a stateless refugee the first 13 years of my life in Kuwait where I was born, and then in Canada. However, I now have the luxury of a Canadian passport, a first-world academic post at the Division of Emergency Medicine in London, Canada, and the ability to connect two disparate worlds.

When I saw the problem while trying to treat wounded patients in the 2012 war in Gaza, I didn't ask myself “why not somebody else?” I asked: “why not me?”



non alergenic materials for printing
by McLae

With all the allergies to various materials, such as nickel and latex, what materials can be 3d-printed that are medically inert? Surgical instruments are stainless steel, implants are titanium, how do you print these? It seems another whole line of questions to find proper materials that can be printed.

Tarek: A few plastics come to mind. ABS is FDA approved, as is Nylon 680 and some PETT. For now, underserviced populations will not be able to receive 3D printed metals – it's too costly and out of scope. However, there can be some creativity. 3D4MD, a group in Toronto, Canada has successfully developed and published on 3D printed surgical instruments made from ABS. Because their models are not published online and I believe are not open source, we have started our own surgical tools project, which will have tremendous impact when completed.

Your answer, then, has two parts. The first is that we should aim at the low-hanging fruit of medicine. Off-patent, ubiquitous devices like stethoscopes, pulse oximeters, electrocardiograms, and hemodialysis are good examples.

The second part is that we in the global south accept that some people will die because of the lack of proper supplies. Given latex gloves or no gloves at all, the choice is obvious. This is not academic: physicians and policymakers have been forced to make this decision in Gaza at the Shifa hospital's emergency department, where most of our gloves are latex.

We're talking about basics like gloves and gauze. Nobody here is talking about custom-printed titanium implants.



Challenges
by Anonymous Coward

What do you see as the main challenges in getting your devices to the regions that need them?

Tarek: I guess the main challenge by far is buy-in. Once a ministry of health or hospital buys into the idea, then the technical parts are trivial and inexpensive.



What else is out there?
by ciaran2014

I've read there are other 3D-printed stethoscopes. Is yours (the Gila 3D stethoscope) attracting attention because it's better, or cheaper, or because it's actually getting used? Or is the Gila 3D stethoscope getting attention not for what it is but for it being an example from a domain where 3D seems set to bring radical change?

Tarek: I know of a few other stethoscopes. In that sense, what we're doing is not unique technically. Our innovation is taking the technology and mixing it with the politics of Free hardware and enfranchisement and the science of verification and validation. Then, as you noted, we put it to use in the real world.

Our stethoscope is as good or better than a Littmann Cardiology III. I can prove it. You can build it today, all of the models are available to modify, and soon it will be Health Canada approved as a Class I device. A peer-reviewed publication is hopefully forthcoming.

The attention is indeed because of the idea and the promise, not the stethoscope. However, the stethoscope has created a model and a high standard that we and other groups must meet when working on future projects of this kind.

Last week you had a chance to ask Dr. Tarek Loubani about his 3D-printable, 30-cent stethoscope project, and other open source, ultra-low cost medical equipment. Below you'll find his answers to your questions. What about patents?
by ciaran2014

Most activities that can be performed commercially but which can also be performed non-commercially are either exempt from patents or never get prosecuted. Fixing other people's bicycles, writing a book, and performing music come to mind. (Software development is a grey area.) But 3D printing is taking an activity where efficient production on any reasonable scale was pretty much the exclusive domain of businesses, and making it accessible to DIY-ers and people who would do it while doing their job or performing some task at home, without any direct commercial aspect. Any idea what stage the debate is at regarding patent restrictions on printing or distributing designs for things more complicated or more modern than stethoscopes?

Tarek: This project does not aim to innovate as such. We aim to drop the bottom out of the costs on devices whose patents have long since expired. We might be trolled, harassed and sued into oblivion, but not because we are in violation of any patents. Indeed, the patents that cover the stethoscope we made are long expired US3168160, filed in 1962; US3108652, filed in 1960; US3515239, filed in 1968. The patents that cover a few small innovations in the Littmann Cardiology III expire in just a couple of years US5945640, but fundamentally the tech is ancient.

It's the same for pulse oximetry. Same for electrocardiograms.

Regarding your overarching question, brilliant minds like Geist, Doctorow, Stallman, etc. might be better positioned to answer. My hope, of course, is that the copyright bargain turns in favour of users and citizens sooner rather than later.



Was your stethoscope 3D printed in Gaza?
by mrops

It seems there are a lot of restrictions on what can be imported into gaza as there is a risk technologies might fall into terrorist hands and used for nefarious purpose. Under this, is it really possible to import a 3D printer into gaza for such tasks?

Tarek: There are already 3D printers in Gaza. Those who have made Prusa i3 printers know that it's trivial to make one from salvaged parts taken from old inkjet and laser printers. These printers will be used in the production of prosthetics and medical devices.

Those who support the blockade or oppose the rights of patients in Gaza to access health care might contend that 3D printers could be used to make weaponry. This is a ridiculous claim: Gaza has hundreds of CNC routers, and most of the weaponry currently in the hands of the Palestinian resistance was either captured from Fatah forces during an “attempted coup” (David Wurmser's words) in 2007 or smuggled, mostly via tunnels under the Egyptian border. The armed resistance groups in Gaza are not waiting for us to bring in 3D printers. If they wanted them, they'd have brought them in with the last batch of rockets.



Are medical devices restricted?
by Anonymous Coward

I see lots of stuff blamed on the import restrictions, but are medical devices actually blockaded, or are they stopped because they're used as a cover to smuggle in other things?

Tarek: According to Gisha, an Israeli NGO, the blockade is “not in order to protect against security threats ... but rather as part of a policy to apply 'pressure' or 'sanctions' on the Hamas regime.” Your question assumes that the blockade is security instead of sanction, which is not the case. Even so, there has never been smuggling of illicit items into Gaza under the cover of medical supplies.

Israel does not declare the list of banned items, but claims that medicines are not banned (see this partial list of banned items, but MSF and others report chronic severe shortages of medical supplies. The World Health Organization reported in 2011 that “shortages of the 190 medical disposable items include some basic and very critical items such as: syringes, Central Venous Pressure devices, ECG and CTG paper, X-Ray film, gauze, disposables used in laparoscopies, and filtration cartridges used in haemodialysis for patients with kidney failure.”

Frankly, I have never cared about why. In Gaza, it's blockade. In Democratic Republic of Congo it's war. In Rwanda, it's poverty. The end result is the same: The denial of health care to the world's most vulnerable people. Everyone deserves health care. This project is about ensuring that doctors and patients in Gaza and elsewhere can alleviate their own suffering without waiting for international law and public goodwill to catch up with illegal occupations, collective punishments and colonial legacies.



3D Printing, catalyst for Intermediate Technology?
by Anonymous Coward

Your 30-cent stethoscope seems to be an excellent example of "Intermediate Technology" (or “Appropriate Technology“) as popularized by Dr Hans Schumacher in his influential book, Small is Beautiful. Do you think that 3D printing will become increasingly important in the third world with regards to improving basic medicine, agriculture etc?

Tarek: I see my 3D printer as a portable factory. It can't do all the same things at the same scales, but it is possible for people in very poor places to create high precision plastic parts that were previously impossible. Because these parts are created from digital models, it also allows collaboration via open source models, as we see on various model repositories. Open source models and repositories are where I think exponential achievements are happening today.

3D printing then becomes one of the ingredients in the empowering of disenfranchised people to take control and come up with indigenous solutions to problems.



Local making of tools
by fortunatus

While reviewing the online repository for the stethoscope design, I saw that mainly it's the sound gathering part that is 3D printed. The rest is - reasonably - made out of regular stuff. So then, with some regular stuff, can't local people figure out how to make stethoscopes? They really can't figure out that one sound gathering piece? It takes a doctor/hacker to come from some land far away bearing the URL to a 3D printable part to solve the problem?

Tarek: You're right - there is nothing special here, and I embrace my mediocrity as a doctor and geek. Somebody just had to do a bit of work and spend a bit of money. I don't consider myself to be from some “land far away”: I am Palestinian and lived as a stateless refugee the first 13 years of my life in Kuwait where I was born, and then in Canada. However, I now have the luxury of a Canadian passport, a first-world academic post at the Division of Emergency Medicine in London, Canada, and the ability to connect two disparate worlds.

When I saw the problem while trying to treat wounded patients in the 2012 war in Gaza, I didn't ask myself “why not somebody else?” I asked: “why not me?”



non alergenic materials for printing
by McLae

With all the allergies to various materials, such as nickel and latex, what materials can be 3d-printed that are medically inert? Surgical instruments are stainless steel, implants are titanium, how do you print these? It seems another whole line of questions to find proper materials that can be printed.

Tarek: A few plastics come to mind. ABS is FDA approved, as is Nylon 680 and some PETT. For now, underserviced populations will not be able to receive 3D printed metals – it's too costly and out of scope. However, there can be some creativity. 3D4MD, a group in Toronto, Canada has successfully developed and published on 3D printed surgical instruments made from ABS. Because their models are not published online and I believe are not open source, we have started our own surgical tools project, which will have tremendous impact when completed.

Your answer, then, has two parts. The first is that we should aim at the low-hanging fruit of medicine. Off-patent, ubiquitous devices like stethoscopes, pulse oximeters, electrocardiograms, and hemodialysis are good examples.

The second part is that we in the global south accept that some people will die because of the lack of proper supplies. Given latex gloves or no gloves at all, the choice is obvious. This is not academic: physicians and policymakers have been forced to make this decision in Gaza at the Shifa hospital's emergency department, where most of our gloves are latex.

We're talking about basics like gloves and gauze. Nobody here is talking about custom-printed titanium implants.



Challenges
by Anonymous Coward

What do you see as the main challenges in getting your devices to the regions that need them?

Tarek: I guess the main challenge by far is buy-in. Once a ministry of health or hospital buys into the idea, then the technical parts are trivial and inexpensive.



What else is out there?
by ciaran2014

I've read there are other 3D-printed stethoscopes. Is yours (the Gila 3D stethoscope) attracting attention because it's better, or cheaper, or because it's actually getting used? Or is the Gila 3D stethoscope getting attention not for what it is but for it being an example from a domain where 3D seems set to bring radical change?

Tarek: I know of a few other stethoscopes. In that sense, what we're doing is not unique technically. Our innovation is taking the technology and mixing it with the politics of Free hardware and enfranchisement and the science of verification and validation. Then, as you noted, we put it to use in the real world.

Our stethoscope is as good or better than a Littmann Cardiology III. I can prove it. You can build it today, all of the models are available to modify, and soon it will be Health Canada approved as a Class I device. A peer-reviewed publication is hopefully forthcoming.

The attention is indeed because of the idea and the promise, not the stethoscope. However, the stethoscope has created a model and a high standard that we and other groups must meet when working on future projects of this kind.

Last week you had a chance to ask Dr. Tarek Loubani about his 3D-printable, 30-cent stethoscope project, and other open source, ultra-low cost medical equipment. Below you'll find his answers to your questions. What about patents?
by ciaran2014

Most activities that can be performed commercially but which can also be performed non-commercially are either exempt from patents or never get prosecuted. Fixing other people's bicycles, writing a book, and performing music come to mind. (Software development is a grey area.) But 3D printing is taking an activity where efficient production on any reasonable scale was pretty much the exclusive domain of businesses, and making it accessible to DIY-ers and people who would do it while doing their job or performing some task at home, without any direct commercial aspect. Any idea what stage the debate is at regarding patent restrictions on printing or distributing designs for things more complicated or more modern than stethoscopes?

Tarek: This project does not aim to innovate as such. We aim to drop the bottom out of the costs on devices whose patents have long since expired. We might be trolled, harassed and sued into oblivion, but not because we are in violation of any patents. Indeed, the patents that cover the stethoscope we made are long expired US3168160, filed in 1962; US3108652, filed in 1960; US3515239, filed in 1968. The patents that cover a few small innovations in the Littmann Cardiology III expire in just a couple of years US5945640, but fundamentally the tech is ancient.

It's the same for pulse oximetry. Same for electrocardiograms.

Regarding your overarching question, brilliant minds like Geist, Doctorow, Stallman, etc. might be better positioned to answer. My hope, of course, is that the copyright bargain turns in favour of users and citizens sooner rather than later.



Was your stethoscope 3D printed in Gaza?
by mrops

It seems there are a lot of restrictions on what can be imported into gaza as there is a risk technologies might fall into terrorist hands and used for nefarious purpose. Under this, is it really possible to import a 3D printer into gaza for such tasks?

Tarek: There are already 3D printers in Gaza. Those who have made Prusa i3 printers know that it's trivial to make one from salvaged parts taken from old inkjet and laser printers. These printers will be used in the production of prosthetics and medical devices.

Those who support the blockade or oppose the rights of patients in Gaza to access health care might contend that 3D printers could be used to make weaponry. This is a ridiculous claim: Gaza has hundreds of CNC routers, and most of the weaponry currently in the hands of the Palestinian resistance was either captured from Fatah forces during an “attempted coup” (David Wurmser's words) in 2007 or smuggled, mostly via tunnels under the Egyptian border. The armed resistance groups in Gaza are not waiting for us to bring in 3D printers. If they wanted them, they'd have brought them in with the last batch of rockets.



Are medical devices restricted?
by Anonymous Coward

I see lots of stuff blamed on the import restrictions, but are medical devices actually blockaded, or are they stopped because they're used as a cover to smuggle in other things?

Tarek: According to Gisha, an Israeli NGO, the blockade is “not in order to protect against security threats ... but rather as part of a policy to apply 'pressure' or 'sanctions' on the Hamas regime.” Your question assumes that the blockade is security instead of sanction, which is not the case. Even so, there has never been smuggling of illicit items into Gaza under the cover of medical supplies.

Israel does not declare the list of banned items, but claims that medicines are not banned (see this partial list of banned items, but MSF and others report chronic severe shortages of medical supplies. The World Health Organization reported in 2011 that “shortages of the 190 medical disposable items include some basic and very critical items such as: syringes, Central Venous Pressure devices, ECG and CTG paper, X-Ray film, gauze, disposables used in laparoscopies, and filtration cartridges used in haemodialysis for patients with kidney failure.”

Frankly, I have never cared about why. In Gaza, it's blockade. In Democratic Republic of Congo it's war. In Rwanda, it's poverty. The end result is the same: The denial of health care to the world's most vulnerable people. Everyone deserves health care. This project is about ensuring that doctors and patients in Gaza and elsewhere can alleviate their own suffering without waiting for international law and public goodwill to catch up with illegal occupations, collective punishments and colonial legacies.



3D Printing, catalyst for Intermediate Technology?
by Anonymous Coward

Your 30-cent stethoscope seems to be an excellent example of "Intermediate Technology" (or “Appropriate Technology“) as popularized by Dr Hans Schumacher in his influential book, Small is Beautiful. Do you think that 3D printing will become increasingly important in the third world with regards to improving basic medicine, agriculture etc?

Tarek: I see my 3D printer as a portable factory. It can't do all the same things at the same scales, but it is possible for people in very poor places to create high precision plastic parts that were previously impossible. Because these parts are created from digital models, it also allows collaboration via open source models, as we see on various model repositories. Open source models and repositories are where I think exponential achievements are happening today.

3D printing then becomes one of the ingredients in the empowering of disenfranchised people to take control and come up with indigenous solutions to problems.



Local making of tools
by fortunatus

While reviewing the online repository for the stethoscope design, I saw that mainly it's the sound gathering part that is 3D printed. The rest is - reasonably - made out of regular stuff. So then, with some regular stuff, can't local people figure out how to make stethoscopes? They really can't figure out that one sound gathering piece? It takes a doctor/hacker to come from some land far away bearing the URL to a 3D printable part to solve the problem?

Tarek: You're right - there is nothing special here, and I embrace my mediocrity as a doctor and geek. Somebody just had to do a bit of work and spend a bit of money. I don't consider myself to be from some “land far away”: I am Palestinian and lived as a stateless refugee the first 13 years of my life in Kuwait where I was born, and then in Canada. However, I now have the luxury of a Canadian passport, a first-world academic post at the Division of Emergency Medicine in London, Canada, and the ability to connect two disparate worlds.

When I saw the problem while trying to treat wounded patients in the 2012 war in Gaza, I didn't ask myself “why not somebody else?” I asked: “why not me?”



non alergenic materials for printing
by McLae

With all the allergies to various materials, such as nickel and latex, what materials can be 3d-printed that are medically inert? Surgical instruments are stainless steel, implants are titanium, how do you print these? It seems another whole line of questions to find proper materials that can be printed.

Tarek: A few plastics come to mind. ABS is FDA approved, as is Nylon 680 and some PETT. For now, underserviced populations will not be able to receive 3D printed metals – it's too costly and out of scope. However, there can be some creativity. 3D4MD, a group in Toronto, Canada has successfully developed and published on 3D printed surgical instruments made from ABS. Because their models are not published online and I believe are not open source, we have started our own surgical tools project, which will have tremendous impact when completed.

Your answer, then, has two parts. The first is that we should aim at the low-hanging fruit of medicine. Off-patent, ubiquitous devices like stethoscopes, pulse oximeters, electrocardiograms, and hemodialysis are good examples.

The second part is that we in the global south accept that some people will die because of the lack of proper supplies. Given latex gloves or no gloves at all, the choice is obvious. This is not academic: physicians and policymakers have been forced to make this decision in Gaza at the Shifa hospital's emergency department, where most of our gloves are latex.

We're talking about basics like gloves and gauze. Nobody here is talking about custom-printed titanium implants.



Challenges
by Anonymous Coward

What do you see as the main challenges in getting your devices to the regions that need them?

Tarek: I guess the main challenge by far is buy-in. Once a ministry of health or hospital buys into the idea, then the technical parts are trivial and inexpensive.



What else is out there?
by ciaran2014

I've read there are other 3D-printed stethoscopes. Is yours (the Gila 3D stethoscope) attracting attention because it's better, or cheaper, or because it's actually getting used? Or is the Gila 3D stethoscope getting attention not for what it is but for it being an example from a domain where 3D seems set to bring radical change?

Tarek: I know of a few other stethoscopes. In that sense, what we're doing is not unique technically. Our innovation is taking the technology and mixing it with the politics of Free hardware and enfranchisement and the science of verification and validation. Then, as you noted, we put it to use in the real world.

Our stethoscope is as good or better than a Littmann Cardiology III. I can prove it. You can build it today, all of the models are available to modify, and soon it will be Health Canada approved as a Class I device. A peer-reviewed publication is hopefully forthcoming.

The attention is indeed because of the idea and the promise, not the stethoscope. However, the stethoscope has created a model and a high standard that we and other groups must meet when working on future projects of this kind.

Last week you had a chance to ask Dr. Tarek Loubani about his 3D-printable, 30-cent stethoscope project, and other open source, ultra-low cost medical equipment. Below you'll find his answers to your questions. What about patents?
by ciaran2014

Most activities that can be performed commercially but which can also be performed non-commercially are either exempt from patents or never get prosecuted. Fixing other people's bicycles, writing a book, and performing music come to mind. (Software development is a grey area.) But 3D printing is taking an activity where efficient production on any reasonable scale was pretty much the exclusive domain of businesses, and making it accessible to DIY-ers and people who would do it while doing their job or performing some task at home, without any direct commercial aspect. Any idea what stage the debate is at regarding patent restrictions on printing or distributing designs for things more complicated or more modern than stethoscopes?

Tarek: This project does not aim to innovate as such. We aim to drop the bottom out of the costs on devices whose patents have long since expired. We might be trolled, harassed and sued into oblivion, but not because we are in violation of any patents. Indeed, the patents that cover the stethoscope we made are long expired US3168160, filed in 1962; US3108652, filed in 1960; US3515239, filed in 1968. The patents that cover a few small innovations in the Littmann Cardiology III expire in just a couple of years US5945640, but fundamentally the tech is ancient.

It's the same for pulse oximetry. Same for electrocardiograms.

Regarding your overarching question, brilliant minds like Geist, Doctorow, Stallman, etc. might be better positioned to answer. My hope, of course, is that the copyright bargain turns in favour of users and citizens sooner rather than later.



Was your stethoscope 3D printed in Gaza?
by mrops

It seems there are a lot of restrictions on what can be imported into gaza as there is a risk technologies might fall into terrorist hands and used for nefarious purpose. Under this, is it really possible to import a 3D printer into gaza for such tasks?

Tarek: There are already 3D printers in Gaza. Those who have made Prusa i3 printers know that it's trivial to make one from salvaged parts taken from old inkjet and laser printers. These printers will be used in the production of prosthetics and medical devices.

Those who support the blockade or oppose the rights of patients in Gaza to access health care might contend that 3D printers could be used to make weaponry. This is a ridiculous claim: Gaza has hundreds of CNC routers, and most of the weaponry currently in the hands of the Palestinian resistance was either captured from Fatah forces during an “attempted coup” (David Wurmser's words) in 2007 or smuggled, mostly via tunnels under the Egyptian border. The armed resistance groups in Gaza are not waiting for us to bring in 3D printers. If they wanted them, they'd have brought them in with the last batch of rockets.



Are medical devices restricted?
by Anonymous Coward

I see lots of stuff blamed on the import restrictions, but are medical devices actually blockaded, or are they stopped because they're used as a cover to smuggle in other things?

Tarek: According to Gisha, an Israeli NGO, the blockade is “not in order to protect against security threats ... but rather as part of a policy to apply 'pressure' or 'sanctions' on the Hamas regime.” Your question assumes that the blockade is security instead of sanction, which is not the case. Even so, there has never been smuggling of illicit items into Gaza under the cover of medical supplies.

Israel does not declare the list of banned items, but claims that medicines are not banned (see this partial list of banned items, but MSF and others report chronic severe shortages of medical supplies. The World Health Organization reported in 2011 that “shortages of the 190 medical disposable items include some basic and very critical items such as: syringes, Central Venous Pressure devices, ECG and CTG paper, X-Ray film, gauze, disposables used in laparoscopies, and filtration cartridges used in haemodialysis for patients with kidney failure.”

Frankly, I have never cared about why. In Gaza, it's blockade. In Democratic Republic of Congo it's war. In Rwanda, it's poverty. The end result is the same: The denial of health care to the world's most vulnerable people. Everyone deserves health care. This project is about ensuring that doctors and patients in Gaza and elsewhere can alleviate their own suffering without waiting for international law and public goodwill to catch up with illegal occupations, collective punishments and colonial legacies.



3D Printing, catalyst for Intermediate Technology?
by Anonymous Coward

Your 30-cent stethoscope seems to be an excellent example of "Intermediate Technology" (or “Appropriate Technology“) as popularized by Dr Hans Schumacher in his influential book, Small is Beautiful. Do you think that 3D printing will become increasingly important in the third world with regards to improving basic medicine, agriculture etc?

Tarek: I see my 3D printer as a portable factory. It can't do all the same things at the same scales, but it is possible for people in very poor places to create high precision plastic parts that were previously impossible. Because these parts are created from digital models, it also allows collaboration via open source models, as we see on various model repositories. Open source models and repositories are where I think exponential achievements are happening today.

3D printing then becomes one of the ingredients in the empowering of disenfranchised people to take control and come up with indigenous solutions to problems.



Local making of tools
by fortunatus

While reviewing the online repository for the stethoscope design, I saw that mainly it's the sound gathering part that is 3D printed. The rest is - reasonably - made out of regular stuff. So then, with some regular stuff, can't local people figure out how to make stethoscopes? They really can't figure out that one sound gathering piece? It takes a doctor/hacker to come from some land far away bearing the URL to a 3D printable part to solve the problem?

Tarek: You're right - there is nothing special here, and I embrace my mediocrity as a doctor and geek. Somebody just had to do a bit of work and spend a bit of money. I don't consider myself to be from some “land far away”: I am Palestinian and lived as a stateless refugee the first 13 years of my life in Kuwait where I was born, and then in Canada. However, I now have the luxury of a Canadian passport, a first-world academic post at the Division of Emergency Medicine in London, Canada, and the ability to connect two disparate worlds.

When I saw the problem while trying to treat wounded patients in the 2012 war in Gaza, I didn't ask myself “why not somebody else?” I asked: “why not me?”



non alergenic materials for printing
by McLae

With all the allergies to various materials, such as nickel and latex, what materials can be 3d-printed that are medically inert? Surgical instruments are stainless steel, implants are titanium, how do you print these? It seems another whole line of questions to find proper materials that can be printed.

Tarek: A few plastics come to mind. ABS is FDA approved, as is Nylon 680 and some PETT. For now, underserviced populations will not be able to receive 3D printed metals – it's too costly and out of scope. However, there can be some creativity. 3D4MD, a group in Toronto, Canada has successfully developed and published on 3D printed surgical instruments made from ABS. Because their models are not published online and I believe are not open source, we have started our own surgical tools project, which will have tremendous impact when completed.

Your answer, then, has two parts. The first is that we should aim at the low-hanging fruit of medicine. Off-patent, ubiquitous devices like stethoscopes, pulse oximeters, electrocardiograms, and hemodialysis are good examples.

The second part is that we in the global south accept that some people will die because of the lack of proper supplies. Given latex gloves or no gloves at all, the choice is obvious. This is not academic: physicians and policymakers have been forced to make this decision in Gaza at the Shifa hospital's emergency department, where most of our gloves are latex.

We're talking about basics like gloves and gauze. Nobody here is talking about custom-printed titanium implants.



Challenges
by Anonymous Coward

What do you see as the main challenges in getting your devices to the regions that need them?

Tarek: I guess the main challenge by far is buy-in. Once a ministry of health or hospital buys into the idea, then the technical parts are trivial and inexpensive.



What else is out there?
by ciaran2014

I've read there are other 3D-printed stethoscopes. Is yours (the Gila 3D stethoscope) attracting attention because it's better, or cheaper, or because it's actually getting used? Or is the Gila 3D stethoscope getting attention not for what it is but for it being an example from a domain where 3D seems set to bring radical change?

Tarek: I know of a few other stethoscopes. In that sense, what we're doing is not unique technically. Our innovation is taking the technology and mixing it with the politics of Free hardware and enfranchisement and the science of verification and validation. Then, as you noted, we put it to use in the real world.

Our stethoscope is as good or better than a Littmann Cardiology III. I can prove it. You can build it today, all of the models are available to modify, and soon it will be Health Canada approved as a Class I device. A peer-reviewed publication is hopefully forthcoming.

The attention is indeed because of the idea and the promise, not the stethoscope. However, the stethoscope has created a model and a high standard that we and other groups must meet when working on future projects of this kind.