I have met Shapiro and he is a very nice and smart guy, but I find it rather shocking that somebody could invest so much time and effort in designing new language before building a library to do something as fundamental as I/O.
Is interesting to contrast his approach building BitC to that of Ken Thompson and Rob Pike (both former colleagues of his at Bell Labs) building Go.
Go has been criticized for "not paying attention to PL research", which might be true, but is already extremely useful and even before its first 'stable' release people already have used to build large systems used in production.
I think what applies to building other kinds of software applies to designing programming languages too: you need something that you can start using to build real systems as soon as possible and then iterate from there based on your experience.
The problem with languages is that changing the language involves throwing away the code you wrote, which discourages one from building real systems with a language that is still changing.
That puts even more value in keeping languages simple. And tools like gofix are also quite nice to help with this.
They have fairly different goals, though. BitC's main goal was to be a verifiable systems language, so it makes some sense that a lot of effort up front was put into investigating the "verifiable" part. Rather than building libraries and trying to get it to catch on, the effort was focused on trying to figure out if it could be designed in a way that simultaneously supported low-level, systems-ish programming while also supporting verification. If the answer on the verifiability part turned out to be no, then that would mean it wouldn't necessarily be worth building the rest (or trying to get people to use it), since that was the point of the project existing in the first place.
Let's define success as new + useful. You can build something new then make it useful, or you can start with useful and add something new.
I suggest that the second approach is better, because we already have a good sense of how to measure useful, so you will always know where you are. Keep your eyes on the prize, as they say.
If the goal was to make a C-like language that's verifiable, though, and you end up with a C-like language that isn't verifiable, in what sense is that useful? The whole usefulness of the project, at least as it was conceived, hinged on it adding some notion of verifiability to C. Otherwise it's just a C clone with smaller installed base, worse tool support, etc.
There are degrees of verifiability. A C-like language with imperfect but stronger verifiability (for example, with a strong, formalized type system) is still more verifiable (admits the proof of more theorems via static analysis) than C.
The whole usefulness of the project, at least as it was conceived, hinged on it adding some notion of verifiability to C.
That is exactly what I am saying. It sounds like they trimmed away too much of C in the process and didn't check to make sure those parts could be added back. I haven't really followed the whole saga though.
I think you're missing that this was was research project, and they were trying to answer the fundamental question, can we build a verifiable systems language?
>Go has been criticized for "not paying attention to PL research", which might be true, but is already extremely useful and even before its first 'stable' release people already have used to build large systems used in production.
Is that a factor of being a better language (for some value of "better"), or of being marketed by famous people working for a famous company?
I really do mean this. Pike et al have Google behind them, and thus not only the Google publicity machine but a whole team of Googlers working actively on making Go work. BitC was a creature of, IIRC, 8 people working on research, and possibly their grad-students if that number doesn't include grad-students already.
The core Go team was smaller than 8 people, at least at launch, although it has lots of peripheral contributors now. But you could look at that as the value of launching. :-)
Java, that had marketing. As in million dollar campaigns, ads in trade magazines, tons of articles and PR even in NON-tech outlets about the "next big language", a company betting most of its strategy on the language and so on. C# too.
Go? Being made by Google guys that are also battled tested programmers helps, but it's not like the language had any marketing. A website, a mailing list, a blog not that frequently updated, and a few appearances on some tech conferences. That about sums it.
As a language, Dart is more heavily touted by Google. And is made by the famous V8 (and more) guy. But noone is using it.
So, yes, Go is used for its pragmatic merits, not because of marketing.
Go might have had less marketing than Java, but it still had a decent amount of support. There were several high quality promotional videos when it was first released. The web page is really full-featured; it has a ton of documentation, including translations for several languages. And all those appearances at tech conferences take time & money (and I'm sure that Google sponsorship helped to secure some of them).
All that stuff adds up in terms of manpower and budget, and it's out of reach of what a small independent team can do. It's not all about technical merit.
There's active marketing and there's passive marketing (brand association). Go is popular because of its association with the brand of Google and the brand of Pike and Thompson. A lot of people like the language on its merits (although I disagree with pretty much every decision they made), but I believe the reason the language got traction is because of its brand association.
>Go is popular because of its association with the brand of Google and the brand of Pike and Thompson.
A (non factual) jump to conclusion.
For one, Go isn't that popular. From the latest TIOBE notes:
"Another interesting observation is that while big software-related companies such as Oracle, Microsoft and Apple all have one of their programming languages in the top 10, Google seems to be incapable to achieve the same.Google's Go language dropped out of the top 50 this month".
Second, Dart is also associated with the brand of Google and the brand of Lars Bak. Yet, it's totally unpopular.
Same goes for Unladden Swallow. Touted by Google, got nowhere, died. (Hell, even things Google spends ton of marketing money on go nowhere: Google Buzz, Google Wave, Google Wallet, ...).
>A lot of people like the language on its merits (although I disagree with pretty much every decision they made), but I believe the reason the language got traction is because of its brand association.
That might get some early interest in the language, but not continued traction (and not that it has much traction, anyway).
People like it because it's fast, the type system gets out of the way, it's not as weird as the lisp-like languages for those used to C syntax, has some cool modern features (from closures, to easy concurrency) and has a big and current standard library.
I also happen like the language on its merits. I also believe that most of those who disagree don't share the design goals of the language designers and wanted mostly just another derivative functional language or some fads-of-the-day-in-academia thing like Scala.
>I also happen like the language on its merits. I also believe that most of those who disagree don't share the design goals of the language designers and wanted mostly just another derivative functional language or some fads-of-the-day-in-academia thing like Scala.
Oh, goody, jumping for joy, another Industry Versus Academia holy war!
Look here. I think Go has some very, very nice ideas in it. I also think it's fundamentally broken by a couple of stupid decisions the designers made: no exceptions, no parametric polymorphism. I also think it's fundamentally pointed at the wrong problem domain: systems languages don't have runtime libraries, don't have garbage collection and don't require operating systems beneath them so that they can write free-standing systems code.
Go is a brilliant, but also broken, competitor against C++, Python, Java, and Erlang (especially Erlang) for the applications-language space, especially highly-concurrent applications (as sometimes handled by Erlang, which I will be happy to see Go murder and replace). Go is not remotely a replacement for C.
And the exact reason for these things is that Go ignored parametric polymorphism (aka generics) and left out exceptions (which are messed-up in Java by quite widely useful in real programming!).
Now, as to "derivative functional languages", there mostly aren't that many. Most derivative work in functional languages gets fed back into Haskell, and nobody expects you to use Haskell for doing Real Work. Haskell does, after all, have the motto, "Avoid success at all costs."
And as to "fads-of-the-day-in-academia", Scala is the single best language I've ever used. And I don't even use all of it. I just use the subset of Scala that is Everything Java Should Have Been.
It has lambdas and closures. It has just enough type inference. It has mutability control for slots. It has object orientation and case-classes/pattern-matching and type-classes via implicit parameters. Scala lets me figure out what language paradigm I need to Get Stuff Done. It's the Python of statically-typed languages, and it interoperates with a vast outside ecosystem to boot.
I can't say as much for every fad-of-the-decade-in-industry thing like Java or Go.
This is one of my favorite features of Go. Exceptions are a horrible mess in every language I have seen that has them. They make following control flow basically impossible. They are equivalent to COME FROM.
Go's multiple returns and defer/panic/recover are a much cleaner way to handle errors, not perfect, but way superior to exceptions.
> Go ignored parametric polymorphism (aka generics)
Go didn't ignore parametric polymorphism, Go already has features (interfaces and slices/maps) that provide most of what people use generics for. Go might even get generics some day if a good design for them is found. But the people using Go every day don't miss generics, and that is because the language itself already provides what people needs.
Also note that C lacks both exceptions and generics, and many people still consider it the best language around to build many kinds of systems.
This has been explained to you time and time again. You keep posting this exact same comment, complete with the "COME FROM" analogy. Then it gets explained to you that panic/recover are an exception system. Then you ignore it. It's really tiresome.
Additionally, people get around the lack of generics in C with macros. Go doesn't have those.
If panic/recover is the same as exceptions, why does everyone whine about the lack of exceptions?
The fact is that while in theory panic/recover are mostly equivalent to exceptions, in practice they are very, very different. Panic is only used in truly extreme situations (like running out of memory) or programmer errors, and you can pretty much write code ignoring it.
Most programs at most will need to call recover() once. Compare this with how exceptions are used in most languages where they are a fundamental aspect of a library's API.
Also the way defer() reliably and cleanly handles cleanup is much more pleasant than exception and 'finally'.
As for C macros, good C programmers have known for a long time that they are best avoided as much as possible.
Because panic/recover are bad exceptions (recover can't specify the types of the exceptions it wants to recover from), and the libraries don't use them. Having to check errors is annoying since most of the time you want to bubble the error up to your caller. This is exactly what exceptions (or the error monad) do for you. In Go you have to do it manually.
Anyway, Go does have exceptions. It just doesn't make much use of them. Seems a shame to not use a useful feature, but oh well.
defer is not reliable if you forget to call it. RAII is much more foolproof than defer in this way. You can forget to call defer, but you can't easily forget to call the destructor.
If the answer is "panic", note that exceptions are superior here, since exceptions let you "panic" without having to litter your code with those calls.
If the answer is some form of "log an error message", exceptions are superior, since you can group multiple related calls into one try-catch block and avoid having to check at the site of each and every call.
If the answer is some form of "return a different error code to your caller", exceptions are superior, because you can catch many different types of exceptions in one try-catch block and re-throw a different exception.
>If the answer is "panic", note that exceptions are superior here, since exceptions let you "panic" without having to litter your code with those calls.
If the answer is some form of "log an error message", exceptions are superior, since you can group multiple related calls into one try-catch block and avoid having to check at the site of each and every call.
If the answer is some form of "return a different error code to your caller", exceptions are superior, because you can catch many different types of exceptions in one try-catch block and re-throw a different exception.
How about locally handling the problem --which could be some non-issue-- and continue without the OVERHEAD of an Exception?
How about now using the verbose and convoluted try-catch-finally idiom for common and not at all exceptional error conditions?
How about THINKING about the error handling, instead of blindly catching "many different types of exceptions in one try-catch block and re-throw a different exception", which we've known for Java to result in a mess...
How about avoiding the exception stack penalty that happens when you "group multiple related calls into one try-catch block and avoid having to check at the site of each and every call" to merely log errors?
>Go has exceptions. They are called panic/recover.
This has been explained to you time and time again. You keep posting this exact same comment, complete with the "COME FROM" analogy. Then it gets explained to you that panic/recover are an exception system. Then you ignore it. It's really tiresome.
He might ignore the similarity of panic/recover with Exceptions, but you also ignore:
panic/recover is not used for 99% of exception control in Go. We just check the out-of-band error code and act accordingly.
Panic/Recover is only used for TRULY EXCEPTIONAL situations.
Wish we could say the same for, say, Java's exceptions.
Odd that you say that, because the language that's most similar to Go here is Java, with its checked exceptions. The same reasoning that led to Go's error codes (that you should always handle your errors) led to checked exceptions. The fact that people generally think checked exceptions are a bad idea is a point against Go, not in favor of it.
Checked exceptions are superior to Go's error return codes anyway, since they make it easier to bubble your errors up to your caller.
This is exactly what crossed it off my list. I am interested in a better language than C++ for writing really fast, low-level code but I already have tons of good options for higher-level code.
>I also think it's fundamentally broken by a couple of stupid decisions the designers made: no exceptions, no parametric polymorphism.
Is C "fundamentally broken" too? It doesn't have exceptions or parametric polymorphism either, but people seem to get a lot of work done. Fuck, people even get work done with Javascript, that's it's a bona fide example of a language with broken semantics (Harmony fixes some of those).
The thing is, "fundamentally broken" to me sounds like "it's totally unusable", and that is far from the truth. You might call it "not as convenient as it could be", but not "fundamentally broken". Broken implies "it doesn't work". Well, Go works fine.
Parametric polymorphism would be nice -- at least they are already thinking of adding generics in some v2.0 edition. But it's not a showstopper either, as in "fundamentally broken".
>I also think it's fundamentally pointed at the wrong problem domain: systems languages don't have runtime libraries, don't have garbage collection and don't require operating systems beneath them so that they can write free-standing systems code.
Well, by the "systems" moniker, they don't mean OSs and drivers, they mean what other people call large scale application systems. What you'd might use Erlang for, for example. Server stuff with high concurrency and big memory/cpu etc needs, but without all the C pain. From stuff like, say, Solr, to Hadoop, to Cassandra, etc, ...
>I can't say as much for every fad-of-the-decade-in-industry thing like Java or Go.
I wouldn't call Go "fad of the decade". For one it's not a fad, as it's not even popular.
>*And as to "fads-of-the-day-in-academia", Scala is the single best language I've ever used. And I don't even use all of it. I just use the subset of Scala that is Everything Java Should Have Been.
Well, I like Scala too. But it lacks some things that Go has, and help me in a few cases: no static binaries. No control over memory alignment. No dead easy FFI to C. No dead simple syntax I can understand in a weekend.
C was designed and released in, IIRC, 1972. If someone designed and released C in the year 2012 as a new, state-of-the-art systems programming language, I would tear their guts out for releasing something so fundamentally broken, unsafe, obsolete and simplistic!
>people seem to get a lot of work done.
Quite to the contrary, the entire shift to virtual machines and scripting languages happened because people didn't like using C and C++ for application domains where their advantages don't count.
In fairness I think its a bit early to say that Dart is totally unpopular. The target market for it isn't tech bloggers and proggit. The people who will potentially use it are those who are primarily driven by the need to get some work done as opposed to evaluating new, evolving languages. They won't use it until all the tools and infrastructure are in place.
Guilty as charged. I do want a functional language like Scala, because I believe that school represents a better design. That school of language design saves me the headache of null pointers; it helps me write unit tests with QuickCheck; it allows me to define custom generic collections; it places emphasis on having a fast GC; it features monadic style to help with error handling.
It's not a reasonable comparison. Go lacks any features that haven't already been thoroughly explored in other languages. BitC was an attempt to do something that had never really been done before.
If you read the BitC documents, Shapiro mentions that one of the goals of the project was to avoid innovation.
The BitC goal isn't to invent a new language or any new language concepts. It is to integrate existing concepts with advances in prover technology, and reify them in a language that allows us to build stateful low-level systems codes that we can reason about in varying measure using automated tools. The feeling seems to be that everything we are doing is straightforward (read: uninteresting). Would that it were so.
Avoiding innovation in a particular narrow area, while combining others' new idea from other areas in a novel way, is innovation. In fact, it's very rare to see any other form of innovation.
BitC was started when Shapiro was at a research university. No research institution would fund Go, because Go is not a research language. BitC was, however, designed as a research language.
For that to be true, the Go developers would have to be open to adding research ideas to the language. Java is (for example, generics). Right now Go's developers are not open to this. As a result, Go is not publishable.
Is interesting to contrast his approach building BitC to that of Ken Thompson and Rob Pike (both former colleagues of his at Bell Labs) building Go.
Go has been criticized for "not paying attention to PL research", which might be true, but is already extremely useful and even before its first 'stable' release people already have used to build large systems used in production.
I think what applies to building other kinds of software applies to designing programming languages too: you need something that you can start using to build real systems as soon as possible and then iterate from there based on your experience.
The problem with languages is that changing the language involves throwing away the code you wrote, which discourages one from building real systems with a language that is still changing.
That puts even more value in keeping languages simple. And tools like gofix are also quite nice to help with this.