Go 1.10 Release Notes
golang.org
golang.org
What I mean here is that this problem is finally fixed: https://www.weave.works/blog/linux-namespaces-and-go-don-t-m... GH issue: https://github.com/golang/go/issues/20676 The fix itself: https://go-review.googlesource.com/c/go/+/46033 Relevant part of the release notes: https://golang.org/doc/go1.10#runtime
Compile times on Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz:
Go 1.9.2 7.2sec avg
Go 1.10 6.1sec avg -15.3%
Go 1.9.2 50,727,552 bytes
Go 1.10 49,604,128 bytes -2.2%
At last! Yes!
The go test command now caches test results: if the test
executable and command line match a previous run and the
files and environment variables consulted by that run
have not changed either, go test will print the previous
test output, replacing the elapsed time with the string
“(cached).”
But it's slow if you modified a file that is not involved in tested code paths.
This is just one concrete example. In general when the code size grows, very quickly it becomes impossible to tell if a given edit could possibly affect tests or not. So you want to run `go test` just in case so making it faster is a good thing.
Before 1.10 `go test` used to re-run tests unconditionally.
Since 1.10 it'll avoid re-running them in some cases.
Neither me nor the announcement claims "intelligence".
The rules are simple and effective which is the Go Way.
While you could try to make even better, more "intelligent" rules for determining wether to re-run the tests, those would quickly run into engineering complexity chasing diminishing returns. That is not the Go Way.
Historically the argument against them have been about adding needless complexity. I wonder who was asking for this and how they got it prioritized.
It was implemented by rsc subsequently, after discussion on the issue: https://go-review.googlesource.com/c/go/+/75631
I'm not sure what you're trying to insinuate.
This makes it wildly different from language changes, which require a lot more consideration.
This is the kind of difference I'm getting
GOCACHE=off time go build
16.36 real 37.02 user 6.43 sys
0.66 real 0.53 user 0.37 sys
find . -name '*.go' | wc -l
2031I'm ok with that I guess and I suppose I see the benefit when running multiple package test runs where their aren't dependencies between them. But I've just not seen the utility in practice, and it seems like it can introduce bugs where the cache is used incorrectly.
I'm a heavy user of table-driven tests that typically use YAML files that set up the parameters for the test scenarios. These use filepath.Glob(), ioutil.ReadDir(), and so on. For "go test" to invalidate its cache correctly, it would have to intercept those calls and record the dependencies. That'd be awesome.
It would be nice if tests could give hints like t.DisableCache() or t.DependsOn(filename).
Bug: https://github.com/golang/go/issues/22593 Commit: https://go-review.googlesource.com/c/go/+/81895
Incredibly, they've modified the standard library (os.Exec(), Stat() and so on) to log the activity to an internal mechanism used by the testing package. I'm rather flabbergasted by the close coupling (it's a feature that would've been impossible for anyone outside the Go team to implement), though it's certainly a pragmatic solution.
Tracking seems to only occur within the current process, so if you call out to a subprocess to generate files, those files won't be taken into account, but I've not gone through the code with a fine comb.
I guess changing the scripts would be detected by `go` so perhaps I don't have a problem. At present none of my scripts invoke other scripts.
Also, "[this package] has known issues" was removed from the doc.
Compiler Toolchain
...
... plugin now works on linux/ppc64le and darwin/amd64> Go 1.10 is the last release that will run on OS X 10.8 Mountain Lion or OS X 10.9 Mavericks. Go 1.11 will require OS X 10.10 Yosemite or later.
Would Go programs just not compile on those OS versions, or not run entirely?
It means we are not going to test on those old systems anymore, so we make no promises about either.
> As announced in the Go 1.9 release notes, Go 1.10 now requires FreeBSD 10.3 or later; support for FreeBSD 9.3 has been removed.
The OS X >= 10.10 and Windows >= 7 requirements of Go 1.11 is good reason to maintain compatibility/support for 1.10 for some time. I don't have a sense for the impact to *bad systems in use.
I keep looking at languages like Go and frameworks like Angular as being steered for huge-org problems, but I wonder if startups are better off incurring the debt of riskier, less conservative languages and paradigms and worrying about the technical debt only once they've reached the scale where it a) actually matters to your agility in delivering customer value and b) you have the capital to make it worth solving the problem.
Maybe this is reading too much into the generics kerfluffle, but I would love to be enlightened if anyone can clarify this further.
The reason for that is largely the 'come back to it' factor. I'm reasonably able to identify go code I wrote and put away. I can't say the same for other languages I've used professionally.
Is that it just doesn't matter very much. F# has very powerful generics, and there are particular circumstances where that saves me a lot of typing. But you can still get it done in C# with less powerful generics, or Go with none.
F# has sum types, and replaces null with an option type - great ideas, but you can approximate these ideas in any language if you need to.
Similarly, Nim's metaprogramming has let me do some really clever things, but again, it just saves some typing.
I've found that language features and properties are often given more weight than they deserve. The really hard problems I've had when coding are just the actual problems. And while a particular language can be life-changing in particular problem domains, its rare that they are life changing in general.
Go is maybe the language I think is least interesting of all of the ones I've played with but I currently prefer it over the others because
1. stable, mature language and tools (unlike nim) 2. fast compile times (unlike rust) 3. compiles to native executables
F# might be my favorite if it had fast compile times and native compilation. Rust might be my favorite if I ever grok the borrow checker. But if someone said I had to use language X to do project Y I would almost always be fine with it, unless there were insurmountable performance problems caused by the language.
How? You can make up for it somewhat with linters, unit tests etc. but it's tiring and nowhere near as robust as a type checker that enforces null checks for you.
But it is just one parameter of a thousand affecting how easy it is to write good code, it sometimes has runtime costs.
Both C and Go are very, very simple languages; there aren't many keywords, and it's pretty easy to grok both at a functional level. It takes, of course, a bit to reach the second-level understanding you need to make full use of either language, but it's easy to hit the ground running in both.
We sometimes get stuck on one language being better than others because it has X feature or Y concept, and I've seen some people essentially root for one language over another. But at the end of the day, languages are tools to get your work done, and on balance the work is going to be hard whichever route you go. Use the one that suits the talents you have available and that broadly complements the needs that you have.
I haven't used it with teams of people on any way yet but I imagine it makes it somewhat easier to drop into code that isn't yours and understand it. There are less ways to create voodoo. Which can be a pro or a con, depending!
Are you sure about that? I don't think you'll be running Go on an AVR. Likewise to this day Go still can't pin pointers so interop with native C libraries is a royal pain(this is something that C# and Java both support).
People love to bag on C but there are domains where it can go that a GC'd language can't. I wouldn't be so quick to equate the two.
I don't think Go needs to be a like-for-exact-like analog of C to be a valid replacement. For many C programs, the memory management pattern they use is something that could be handled just as easily with GC, and done so in such a way as to lift a significant burden on the programmer.
I mentioned this in another comment, but definitely, if you need to manage your own memory—don't use Go. I must disagree that GC disallows Go as a replacement for the language. But I will respect your opinion if you think it does!
Much if modern C usage is in this space even if it's not as visible to the average developer.
GCs have a host of problems like needing a 2x working set, pauses and the fact that you can't control allocation locations for better cache usage. Go may be fast but it will never unseat C/C++/Rust in performance for the reasons above.
No, go has a garbage collector. It is not a replacement for C. Languages like C++, Rust or Ada are.
I suppose you could write your own malloc in Go... if you preallocated a bunch of bytes in a huge chunk, and wrote some functions to use that up. But that sounds like a pain.
If you really really specifically need to manage your own memory, then I agree, you shouldn't use Go. But that doesn't mean that Go is not a valid replacement for C. Do you think a majority of programs that are written in C are done so because they need to manage their own memory?
It doesn't do everything C does, it doesn't allow manual memory management at first place.
So you can't pretend that a garbage collected language does everything a language with manual memory management does.
Manual memory management is a feature, Go does not have such a feature. Deterministic behavior in a program is fundamental when writing hardware drivers or real time programming, Go can't do that.
Joe Duffy has putted it quite nicely regarding how many in the Windows team saw Midori, even though it was proven to be running right in front of their eyes.
RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing by Joe Duffy
You'd have to define what you mean by system language at first place before making such a claim.
The only programming language for a single platform, besides a little Assembly for hardware integration.
The traditional CS definition of systems programming languages on OS research literature.
No, it is not. Put macros back in, pointers and memory without GC before claiming Go can do the same things C does.
Go does have a GC, not manual memory management
Go can't interact performantly with other languages.
Go is like Java (not C). Its kind of nice but deliberatley sabotaged by (Big Company).
That said, I don't think there's anything more I can say which can add to the conversation. I'm happy to allow what I have said to stand.
C was owned by AT&T, and now by everyone that can afford to have a seat at ANSI/ISO C meetings, apparently it is easy to forget this little fact.
I have to disagree with this one. I tried go briefly, and what I found was that it provided a couple of relatively nice high-level features (multiple return, nested functions, interface{} (although that doesn't count it's basically void*)), but that ultimatley it tried to constrict what I could do in a way that c didn't. Add to that that c somehow has much better metaprogramming than go even though literally every language ever made has better metaprogramming than c.
i am sure you must have heard of ocaml and reasonml .. why didn't you consider them
Ocaml has some tough to live with syntax for me, the threading issue, and tiny ecosystem.
But yes it interests me! ReasonML fixes the syntax and maybe it will lead to a bigger ecosystem, that would be great.
Having less lines of code looks like a big win to me.
So I don't think it is always a big win, but maybe sometimes it is.
I'm glad it's a big win for you! But in the main, I think, it's a tradeoff. Expressiveness has a cost; simplicity has a cost.
Personally, I think it's best not to get too attached to specific concepts or languages, because times change, and needs change. If you're a good programmer, you can learn any language and any concept you need to.
Yes, i will approximate a Formula 1 car by connecting two bicycles side to side and fitting a lawnmover motor.
If you insist on car analogies, Go is a good-at-most-things car.
It's not the fastest car, it's not the most gas efficient car, it's not the cheapest car, it's not the best looking car, it's not the most technically advanced car but it scores in 10% percentile on all on those fundamental characteristics.
Other cars are more bimodal. One car is very fast but also very expensive. Another uses the latest high-tech titanium making it very light but designers only included very small gas tank. C++ is like Homer Simpson's car: wants to have everything and ends up as a frankenstein.
And I'm already regretting this car analogy because it's so unnecessary.
Go gets top marks on things that matter.
Fundamentals like: generates fast code, compiles quickly, has garbage collector, array bounds checking, excellent concurrency, great standard library, lots of third party libraries, generated binaries use little memory etc.
Go might not have something that your favorite language X has but language X is very bad on at least one of those fundamentals.
It might be 10x slower, compile code 10x slower, rely on gigantic runtime, lack any reasonable concurrency etc.
Why doesn't Java count?
* Because it doesn't have "excellent concurrency"? (I posit its concurrency is far better than C, Python, Ruby, JS, or pretty much any mainstream language)
* Or because "generated binaries use little memory"? (That's the stereotype and arguable, but Java is used as the primary user space language on low end, memory constrained mobile devices. AFAIK, Go can make no such claim.)
* Or something else?
FWIW, Java has other fundamentals like custom generic collections, standard package management system/conventions, nullable types/optionals, and a workable error strategy.
if (...) {
...
} else if (...) {
...
} else {
...
}
Since it is structured code, I keep adding more features without much breakage. I know people can do it so many other languages and ways. My point was that Go can be used for variety of person or single developer projects. It is more tuned towards making new/interesting things in boring language vs learning interesting language to reimplement existing things.
semi random, but for another example of someone enjoying the hell out of go for personal projects, take a look at:
that guy's amazing, one of my programming heroes.
Go was the first compiled language I learned coming from Python and scientific computing. And I felt the same way and was so delighted to write fast native multithreaded code without ceremony.
But then I learned some other languages that have elegant and powerful type systems (namely, Rust, OCaml and Haskell) and now I'm somewhat disgusted at my former self. Go could have been great, but it ain't. It's a blub language if ever there was one.
I know my opinion on these things doesn't matter. But I feel resentful of Go, I feel like I was duped.
GOPATH took me a few hours to figure out at the time, but that was because the documentation was incredibly sparse at the time (this was before Go hit 1.0). Now it's just:
mkdir -p ~/go/src/hello
echo "package main" >> ~/go/src/hello/main.go"
echo "func main() { println("Hello world") }" >> ~/go/src/hello/main.go"
go build hello
./hello ///usr/bin/env go run "$0" "$@"; exit $?
package main
import "fmt"
func main() {
fmt.Println("Hello World")
}but i wouldn't feel "duped".
those are much more ambitious languages than go; they're in a different space. go is simple, easy to learn, small...
(a lot what's nice about go is beyond the language too -- the whole ecosystem is just very pleasant to work with.)
1. Documentation. It's lacking or spread thinly across the Internet, and it's mostly low quality in my experience. 2. Windows support was dodgy last I checked. 3. Build tooling is byzantine and fragmented 4. Standard libraries - The official standard library is limited and frustrating - Other standard libraries are limited and frustrating - There is more than one standard library 5. Devs seem more interested in adding language features than making it useful to people who want to write real applications
> At least Ocaml has such a great package manager
As long as I'm consuming packages, it's great. Making packages is a nuisance. Go's dependency and distribution tooling isn't pretty, but at least it gets out of my way--`dep` does what I need it to do and I haven't had any problems. Still, both Go and OCaml's package management story is a far cry from Rust's Cargo.
> better compiler
What does this mean? Certainly not "faster" or "produces faster code" or "works better across platforms".
> repl
Granted, but I program in Python professionally and rarely touch the repl. I use it more often as a command line calculator than anything. If I were doing data science, I might feel differently, but for application development I don't miss it.
> allocation profiler
Go has had an (excellent) allocation profiler built into the toolchain for years. Besides, it's much easier to intuit about (and control) allocations in Go than it is in OCaml.
If I could borrow anything into Go from OCaml, it would be generics and sum types. The rest (syntax, runtime, tooling, libraries, etc) I'll leave be.
Yes ocaml compiler is light years ahead Go’s one in terms of optimizations and code analysis (and even correctness [1]). It is still not as great as haskell’s one, but very good, especially with new lambda middle end. Go compiler is straightforward as hell and can’t do much inlining or optimizations that ocaml can.
Windows support was always tier 1 in compiler. Jbuilder also supports windows and even cross-compilation with windows as a target. Opam now compiles on Windows was too.
As for libraries opam now have thousands of these and ocaml libraries’ quality is often much higher than the quality of libs of this other imperative language due to quality of language.
>go standard library
lol no math for ints, no data structures beyond map, but crappy http and Json serialization.
[1] https://blog.janestreet.com/proofs-and-refutations-using-z3
This reads like you're trying to pass a stylistic objection off as a functional objection. If that's not the case, feel free to add substance.
> And how is making packages is a problem? You jast add opam file and that is all. You can do versioning, pin any opam or git repo, or even some fs resource.
Ignoring the one-off syntax choice, opam files require you to bring your own installation and build scripts.
> Yes ocaml compiler is light years ahead Go’s one in terms of optimizations and code analysis (and even correctness [1]). It is still not as great as haskell’s one, but very good, especially with new lambda middle end. Go compiler is straightforward as hell and can’t do much inlining or optimizations that ocaml can.
I don't care about "light-years of optimizations" if the end result is still slower than Go.
> lol no math for ints, no data structures beyond map, but crappy http and Json serialization.
This is an enumeration fallacy. I can rattle off a laundry list of OCaml standard library problems as well. This isn't constructive discussion.
> As for libraries opam now have thousands of these and ocaml libraries’ quality is often much higher than the quality of libs of this other imperative language due to quality of language.
I find this not to be true, at least in the case of OCaml vs Go. OCaml libraries are typically overly-abstract or they prefer unintuitive operators and identifiers and generally take much longer to grok than the time they save to use.
Again, I agree that Go the language needs work, but the ecosystem is fantastic. Of course, improvements to the language could benefit the ecosystem (for example, sum types would bring sanity to JSON), but I can still be far more productive in Go than in OCaml.
What do you mean?
>if the end result is still slower than Go.
Benchmarks?
>OCaml libraries are typically overly-abstract or they prefer unintuitive operators and identifiers and generally take much longer to grok than the time they save to use.
Examples? I’ve never seen any of this in a whole mirage stack, lwt, angstrom/faraday, yojson or any other major ocaml lib.
build: [
["./configure" "--prefix=%{prefix}%"]
[make]
]
I'm not asserting that Go is faster, I'm saying that you need to provide evidence that OCaml is faster if you want me to believe that OCaml's compiler is "light-years ahead of Go's in terms of optimizations". Perhaps you didn't mean "OCaml is faster", but only "OCaml is hard to very hard to make fast, but the OCaml compiler does a fantastic job despite". In which case you'll need to justify why that matters to me if it's not actually faster than Go (especially if the performance is worse and/or less intuitive).
> Examples? I’ve never seen any of this in a whole mirage stack, lwt, angstrom/faraday, yojson or any other major ocaml lib.
It's been a while, so the details are foggy. Looking at the RealWorldOCaml page for yojson, however, immediately takes us through an example with a dozen `|>` operators and functional combinators. Perhaps this is a documentation problem and there are more straightforward mechanisms, but that's no great comfort to me as a user. Something as common as JSON should be dead simple, at least in the main cases. And while I have lots of criticism for Go's JSON handling, it is dead simple in the main cases.
Note that this isn't a particularly good example of OCaml libraries being overly abstract; it's just the most concrete example I could provide in a 5 minutes.
Nowadays it's just build: ["jbuilder" "build" "-p" name "-j" jobs ]
It's just one line of config and it is worth it since it gives an opportunity to use any build system you want to (or for some reasons have to) use. Still much better then pulling "deps" from github repos directly.
>I'm saying that you need to provide evidence that OCaml is faster
>"OCaml is hard to very hard to make fast, but the OCaml compiler does a fantastic job despite". In which case you'll need to justify why that matters to me if it's not actually faster than Go (especially if the performance is worse and/or less intuitive).
Sure, you can write manually a ton of boilerplate for each numeric type in go, just like it's done in gonum. I'm not sure if it is good since more code means more issues and bugs, and I definitely prefer to write or hack something like this:
https://github.com/inhabitedtype/httpaf/blob/master/lib/pars...
instead of this:
https://github.com/valyala/fasthttp/blob/master/header.go
(and this is only a header)
and let the compiler do all the dirty work.
> with a dozen `|>` operators
how the hell is `|>` an obscure combinator? It's just a "unix pipe's" typesafe kin. I've never seen any usage of obscure combinators in ocaml beyond parser-combinator libs ofc but these usually are well documented and you wouldn't use them if you don't like combinators anyway.
>Something as common as JSON should be dead simple
It is dead simple, just add [@@deriving yojson] to your data structure, and you'll get to\of_yojson functions, what could be more simple?
It's just one line of config and it is worth it since it gives an opportunity to use any build system you want to (or for some reasons have to) use. Still much better then pulling "deps" from github repos directly.
I strongly disagree here. Deps is rather ugly, but it works and it's easy to use. A language should have 1 build tool that works for 99% of use cases, and the rest of the tooling should support that by default. This is especially painful for beginners, amplified by the fact that the docs point you to Makefiles by default.
> Sure, you can write manually a ton of boilerplate for each numeric type in go, just like it's done in gonum. I'm not sure if it is good since more code means more issues and bugs, and I definitely prefer to write or hack something like this:
I'm confused; you're responding in the context of compilers producing fast code, but you seem to be advocating for a more generic type system than Go has, which I've already agreed about.
> how the hell is `|>` an obscure combinator? It's just a "unix pipe's" typesafe kin. I've never seen any usage of obscure combinators in ocaml beyond parser-combinator libs ofc but these usually are well documented and you wouldn't use them if you don't like combinators anyway.
I didn't claim it was obscure; I claimed that it's not useful--it's optimizing for fewer keystrokes and not readability. I can appreciate code-golf for its own sake, but I need my team to be able to jump into code quickly, and that often means that naive is better than clever and a little boilerplate is better than terseness. BTW, the HTTP parser that you shared is a good example of this. The Go version might be imperative, but at least it's clear.
> It is dead simple, just add [@@deriving yojson] to your data structure, and you'll get to\of_yojson functions, what could be more simple?
Like I said before; this might not be a good example, it's just the first one that came to my mind. Maybe the problem here is that the good documentation is so hard to find. Still, I've come across lots of unnecessarily abstract libraries before, I just don't recall the details.
it makes code much more readable
produce_collection ()
|> Col.filter pred
|> Col.map to_json
>The Go version might be imperative, but at least it's clear.
Depends on how do you define clear. If huge manually optimized pile of imperative spagetty is clear, than yes. My definition of clear presumes sophisticated abstractions making hard things easier to reason about and comprehand, not a pile of hand-written state machines.
>Still, I've come across lots of unnecessarily abstract libraries before,
So many that you couldn't find an example?
search again
Having a compiler that catches 80% of the errors you can make during big code changes already starts becoming a real advantage.
I don't think that Go is a perfect language, but for most of my use cases it is the most efficient one overall.
Go has a simple syntax that rarely changes and has been backwards compatible since 1.0. It even has a built-in code formatter to keep things consistent. This means that you can write a service with the confidence that it will compile on the latest version of Go when you need to change it. Even if that is months or years later.
Additionally, the dependencies for Go programs are stored on disk, relative to the project, in a simple hierarchy. I can't think of a single other language or package manager that makes it easier to vendor all your dependencies. And I do so for most Go projects I work on (I mostly use it for standalone services, not libraries).
Here are the typical steps for reviving a project that I haven't touched for over year:
git clone ...
cd ...
go test ./...
this has pro's and cons.
Eh, you get that with most languages, though.
Additionally, I agree with your points about Go.
But on the other hand, when the day is done and I look at what has been created, I'm really impressed with the quality of the project. A good team can write good software in any language, but I do believe this language has helped this team write better software than they might have in another language.
I suppose that, like everything, there are tradeoffs. I'm not not yet sure which tradeoffs are most important to me.
.filter()
Not having to write useless type casting boilerplate like this: https://github.com/majewsky/sqlproxy/blob/f5b297e7dce14c0453...
Not having to write `if err != nil { return nil, err }` every second line. (Or, in other words, Rust's question-mark operator.)
There is a clear path to working around this case, but I find it to be a bit tedious. I miss languages where, through generics, duck-typing, or similar that I can simply pass the application's structure to the third-party library and it "just works".
[1] https://github.com/upspin/upspin/blob/master/upspin/proto/pr...
I can give you some counter-testimonial for .net when I ran a 50 dev project. Skillsets were all over the place, the architects wrote boilerplate the devs didn't understand, and the codebase was messy, thanks in due part to .net drawing commodity developers and Anders making sure csharp has 5 different ways to do everything.
Lang history driven in large part by new features is turning out to be bad for business, IMO. I want something solid for my team that's easy to code, easy to test, and easy to consistently hire for. And I want them all to be SME's on the code they write for their domain. What that gets me is a lot of devs who will effort point stories about the same, no matter what team they are on. My gut tells me I can get to that state of bliss with something like golang faster than I can .net. Lot of mitigating factors built into that I get it, but that's what my gut tells me.
> A corner case involving shifts by untyped constants has been clarified, and as a result the compilers have been updated to allow the index expression `x[1.0 << s]` where s is an untyped constant; the go/types package already did.
But the docs [https://golang.org/ref/spec#Operators] state that
> `var u = 1.0<<s // illegal: 1.0 has type float64, cannot shift`
If I'm correct, that means in `x[1.0 << s]`. 1.0 is a "number", therefore the shift is valid, but in `var u = 1.0 << s`, it's a float64, and therefore the shift is invalid.
see also: https://blog.golang.org/constants
How strong is the guarantee of "no code execution during build"?
I'm currently working on a Go build system and my understanding is that the Go compiler was designed for compiling untrusted code. You'd have to exploit the compiler on order to get RCE, right?
(I'm sandboxing it either way, but it's good to know for risk assessment)
`go build` on a pure Go code only executes the compiler and linker of the go toolchain.
If you add cgo to the mix, `go build` might invoke system C++ compiler (gcc, clang, mingw) to compile the C part of the code and system C++ linker.
The issue was that gcc allows arbitrary plugins and if the right cgo flags were provided, gcc would load and execute such plugin, leading to executing whatever code was in the plugin.
That hole was plugged in 1.10.
This is the whole story. There are no other vectors of executing code that is not part of Go toolchain.
Then again, what is your threat model?
If you worry that blindly compiling my evil package will execute my evil code during build, you should also worry that linking my evil package will execute my evil code when you run your compiled executable.
If this is what you are talking about - they 'fixed' it in 1.8 a year ago.
EDIT: Found the proposal on the dep roadmap: https://github.com/golang/dep/wiki/Roadmap
I just come here to eat popcorn and learn about type theory.
This is my least favorite part of the release.
I'll continue hoping goderive becomes a language that displaces go.