Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)

share|improve this question
    
Does it compile the expression "1 + 'boo!'"? No? Then it's type-safe. –  davidk01 May 21 '11 at 2:35
    
@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
add comment

3 Answers

up vote 6 down vote accepted

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

share|improve this answer
    
Unless you use the "unsafe" package, in which case you can crash the program any way you like :) –  Eloff Jul 5 at 23:58
add comment

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

share|improve this answer
    
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
4  
@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
add comment

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.

share|improve this answer
    
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 at 0:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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