this page http://golang.org/doc/go_faq.html writes:

although Go has static types the language attempts to make types feel lighter weight than in typical OO languages

So my question is exactly is it safely typed with generics (like C#) or loosely typed (like javascript) or optional (like option strict in Vb.Net)

  • @JamesMcNellis meaning if a type fails, it can only be because i do a type-cast (any other action should not cause a type exception) – Pacerier May 21 '11 at 19:29
  • 1
    @davidk01 Java will compile ( 1 + "boo" ), and Java's pretty type safe. That expression has a definite static meaning to it because + is overloaded for String objects by the language, and all primitive literals can be type-lifted to wrapped objects which can be then turned into Strings. – Trixie Wolf Jan 26 '17 at 17:42

Type safety is not a black-or-white type-safe or not. It's more of a spectrum and some languages can be more type safe than others (and vice versa). However, I think what you're thinking of with C# vs. Javascript is likely static typing (where type-checking happens at compile-time) vs. dynamic typing (where type-checking happens at run-time) -- certainly, that's what the Go FAQ is talking about.

Google Go is statically typed, but a number of features make it "appear" to be (at least somewhat) dynamically typed. For example, you do not need to explicitly mark your class as implementing any interfaces. If the method signatures of your class match up with those on the interface, then your class automatically implements that interface (a kind of duck-typing). This is useful for extending built-in classes and classes in third-party libraries, because you can just make up your interface to match the methods on the third-party class and it will automatically implement it.

Type safety is actually a different "axis" of the type system. For example, C is a statically-typed language that is not type-safe -- pointers let you do pretty much anything you like, even things that will crash your program. Javascript is dynamically typed, but is also type-safe: you can't perform operations that will crash your program. C# is mostly type-safe, but you can explicitly mark areas of code that are unsafe and do things which are no longer type safe.

Google Go is also type-safe in the sense that you can't mess around with types and crash the program (no direct access to pointers).

  • Unless you use the "unsafe" package, in which case you can crash the program any way you like :) – Eloff Jul 5 '14 at 23:58
  • You can mess around with types and do have access to pointers. And yes, you can easily crash your program by doing that. – eithed Nov 9 '18 at 10:20

It is safely typed in that a type will never be misinterpreted, but an incorrect type can cause the program to panic.

  • i don't get it, does it mean that non-type safe code can actually be compiled? (which isn't possible in c# unless we use dynamics) – Pacerier May 19 '11 at 14:00
  • Doing type assertions, type-wise, is basically like calling a method on a dynamic type – dan_waterworth May 20 '11 at 4:33
  • ok so in short it doesn't have that kind of type-safety c# allows? – Pacerier May 20 '11 at 7:39
  • It does if you don't do type assertions. – dan_waterworth May 20 '11 at 16:30
  • 5
    @Pacerier: It's perfectly possible to run mistyped expressions in C# without dynamics: Just insert casts everywhere (which is basically what type assertions are). – sepp2k May 20 '11 at 20:43

Go's map type is not thread-safe, it is statically typed. It does not have type inheritance, generic programming, assertions, method overloading, or pointer arithmetic either and for good reason.

Type safety and memory safety are long term aims, here in lie's a problem.

Type safety presents an overhead, in kilobytes and megabytes which is acceptable. Go is designed with MapReduce and "Big data", exobytes an petabytes of data, which presents performance issues with type safety, type checking (boxing / unboxing) creates overheads and takes cycles away from processing.

Type safety can be restrictive in sub-typing and polymorphism and in duck typing (cast object to object), this creates dangers and also a space where languages like Go are of great benefit. C++ and Java are not being replaced by Go, it is a new language to help distributed programming and massively parallel system.

The big statement by Bruce Eckel - "Go makes much more sense for the class of problems that C++ was originally intended to solve", is debatable. C++ is a very efficient language and the Boost implementation of MapReduce is very efficient.

Concurrency primitives are the future. Type safety has always been a very contentious topic and Go maybe the first language to address this issue in 20 years, or since Algol.

  • 2
    Sadly I need more reputation to -1 this answer. Type safety is not an overhead, runtime overhead is definitely not measured in units of bytes, and go does have boxing/unboxing in the Java sense. Static typing allows the compiler to make more optimizations than a dynamically typed language can. Map reduce is neither here nor there, ditto with thread safety. – Eloff Jul 6 '14 at 0:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.