17

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)

Improve this question
2
  • @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, 2011 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, 2017 at 17:42

3 Answers 3

Reset to default
32

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).

Improve this answer
2
  • Unless you use the "unsafe" package, in which case you can crash the program any way you like :)
    – Eloff
    Jul 5, 2014 at 23:58
  • 1
    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, 2018 at 10:20
4

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

Improve this answer
5
  • 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, 2011 at 14:00
  • Doing type assertions, type-wise, is basically like calling a method on a dynamic type
    – dan_waterworth
    May 20, 2011 at 4:33
  • ok so in short it doesn't have that kind of type-safety c# allows?
    – Pacerier
    May 20, 2011 at 7:39
  • It does if you don't do type assertions.
    – dan_waterworth
    May 20, 2011 at 16:30
  • 6
    @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, 2011 at 20:43
-2

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.

Improve this answer
2
  • 3
    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, 2014 at 0:05
  • Golang's idiom of having you assert types using an empty interface as a common pattern to avoid the implementation of generics as a language features is certainly not something I would consider "type safe", and while it may keep the language spec simple, when the problem arises(and it will) it leaves the complexity on the plate of the person who's now left to solve the issue with the roll of duct tap golang calls a feature. It certainly doesn't seem like a language that was designed in the last 2 decades, because there are languages which address type safety in a much better way.
    – tsturzl
    Sep 19, 2019 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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