I disagree with this article. I think it does hit on a lot of what makes a language a good teaching language, simplicity, tooling, and concurrency support are all important components of a teaching language, but I think the inflexibility of Go is a little unfortunate for a teaching language.
I’m going to hedge than unopinionated languages are slightly better suited for computer science education since they allow a class to explore each different bias without suffering from the language’s opinions in the process. That’s part of what makes SICP/Scheme so great! Everthing is equally simple/painful and you end up with a fairly unbiased view of what each paradigm is like.
Of course in a “real world setting” some biases can be incredibly helpful by enforcing consistency throughout the ecosystem.
The type-theorist in me can’t help but say, Go’s static type system is not what you should introduce as a canonical view of what static typing is like, SML would be far better for that. It’s far too easy to chafe against Go’s type system’s inherent restrictions while trying to accomplish mundane tasks.
Type theory is important, but it’s not the be-all, end-all topic of computer science education. Arguably—and I argue that—a programming language with a restrictive type system is in fact better for teaching a lot of computer science fundamentals.
Of course not, but types are an important part of computer science and at some point everyone should be given a brief overview of type systems. This shouldn’t be done in Go.
As far as being better for learning, at a certain point yes. No one would say to learn programming with Agda! :) But you also don’t want such a restrictive system where it stops you from writing many common things safely. I’d rather spend a few hours explaining parametric polymorphism then explain why segfaults or casting errors are happening.
Go programs that don’t use the unsafe package can’t segfault. (EDIT: To be more correct, Go prevents all segfaults that are caused by memory access violations. Go will let you dereference a null pointer, but the result is a helpful stacktrace.)
There are plenty of opportunities to use polymorphism in Go without resorting to runtime casts.
I’d call that a null pointer dereference. The Go runtime probably has its own handlers to recover from the actual segfault and present a nice stacktrace to the user.
I generally think of segfaults as memory access violations. e.g., Reading or writing memory that your program doesn’t have access to. Go will not let you do that by virtue of its type system (sans unsafe or cgo).
I’m sure reasonable people will disagree. But the key point to take home is that Go has strictly better memory safety than C.
I disagree with this article. I think it does hit on a lot of what makes a language a good teaching language, simplicity, tooling, and concurrency support are all important components of a teaching language, but I think the inflexibility of Go is a little unfortunate for a teaching language.
I’m going to hedge than unopinionated languages are slightly better suited for computer science education since they allow a class to explore each different bias without suffering from the language’s opinions in the process. That’s part of what makes SICP/Scheme so great! Everthing is equally simple/painful and you end up with a fairly unbiased view of what each paradigm is like.
Of course in a “real world setting” some biases can be incredibly helpful by enforcing consistency throughout the ecosystem.
The type-theorist in me can’t help but say, Go’s static type system is not what you should introduce as a canonical view of what static typing is like, SML would be far better for that. It’s far too easy to chafe against Go’s type system’s inherent restrictions while trying to accomplish mundane tasks.
Type theory is important, but it’s not the be-all, end-all topic of computer science education. Arguably—and I argue that—a programming language with a restrictive type system is in fact better for teaching a lot of computer science fundamentals.
Of course not, but types are an important part of computer science and at some point everyone should be given a brief overview of type systems. This shouldn’t be done in Go.
As far as being better for learning, at a certain point yes. No one would say to learn programming with Agda! :) But you also don’t want such a restrictive system where it stops you from writing many common things safely. I’d rather spend a few hours explaining parametric polymorphism then explain why segfaults or casting errors are happening.
Go programs that don’t use the unsafe package can’t segfault. (EDIT: To be more correct, Go prevents all segfaults that are caused by memory access violations. Go will let you dereference a null pointer, but the result is a helpful stacktrace.)
There are plenty of opportunities to use polymorphism in Go without resorting to runtime casts.
Is this not a segfault?
http://play.golang.org/p/PczjVXz2oN
I’d call that a null pointer dereference. The Go runtime probably has its own handlers to recover from the actual segfault and present a nice stacktrace to the user.
I generally think of segfaults as memory access violations. e.g., Reading or writing memory that your program doesn’t have access to. Go will not let you do that by virtue of its type system (sans
unsafeor cgo).I’m sure reasonable people will disagree. But the key point to take home is that Go has strictly better memory safety than C.
It’s a normal panic, so it can be recovered: http://play.golang.org/p/cl1F2Y9YI0
I was thinking of C in that case, it’s the only other statically typed language I see used much anymore without parametric polymorphism.
And that’s true, and plenty of situations where you still have to :)