Java v. Go

Java (was?) meant to be simple

Source: https://www.stroustrup.com/1995_Java_whitepaper.pdf.

Go is a simple language

How does it stand up to these features, which, as James Gosling points out, are not present in Java?

No more typedefs, defines and preprocessor

Source code written in Java is simple. There is no preprocessor, no #define and related capabilities, no typedef, and absent those features, no longer any need for header files. Instead of header files, Java language source files provide the definitions of other classes and their methods.

A major problem with C and C++ is the amount of context you need to understand another programmer’s code: you have to read all related header files, all related #defines, and all related typedefs before you can even begin to analyze a program. In essence, programming with #defines and typedefs results in every programmer inventing a new programming language that’s incomprehensible to anybody other than its creator, thus defeating the goals of good programming practices.

In Java, you obtain the effects of #define by using constants. You obtain the effects of typedef by declaring classes—after all, a class effectively declares a new type. You don’t need header files because the Java compiler compiles class definitions into a binary form that retains all the type information through to link time.

By removing all this baggage, Java becomes remarkably context-free.

Programmers can read and understand code and, more importantly, modify and reuse code much faster and easier.

Go has «typedefs» (via its «type» keyword, which is used to name types), but doesn't have a preprocessor.

Check?

No more structures or unions

Java has no structures or unions as complex data types. You don’t need structures and unions when you have classes; you can achieve the same effect simply by declaring a class with the appropriate instance variables.

In Java, you simply declare classes.

In Go, every type works the same way. There are no «primitive types». There are no classes. You simply declare types and add methods to them.

You can make the instance variables as private or as public as you wish, depending on how much you wish to hide the details of the implementation from other objects.

Same in Go.

There are no public or private keywords, however. This will be public: ThisWIllBePublic. This will be private: thisWillBePrivate. Capitalization controls visibility (capitalized — public, not capitalized — private).

Also, there are no unions.

Check.

No more functions

Java has no functions. Object-oriented programming supersedes functional and procedural styles. Mixing the two styles just leads to confusion and dilutes the purity of an object-oriented language. Anything you can do with a function you can do just as well by defining a class and creating methods for that class.

Go has functions, as well as methods. It can be confusing, whether a function or a method should be used in a particular case.

Not check.

No more multiple inheritance

Multiple inheritance—and all the problems it generates—has beed discarded from Java. The desirable features of multiple inheritance are provided by interfaces—conceptually similar to Objective C protocols.

An interface is not a definition of an object. Rather, it’s a definition of a set of methods that one or more objects will implement. An important issue of interfaces is that they declare only methods and constants. No variables may be defined in interfaces.

Go has embedding and doesn't have inheritance. Multiple embedding is possible. But, then one has to specify which member or method should be used from which embedded type, or compiler will complain.

Interfaces work in a similar manner to Java.

Check.

No more goto

Java has no goto statement. Studies illustrated that goto is (mis)used more often than not simply “because it’s there”. Eliminating goto led to a simplification of the language—there are no rules about the effects of a goto into the middle of a for statement, for example. Studies on approximately 100,000 lines of C code determined that roughly 90 percent of the goto statements were used purely to obtain the effect of breaking out of nested loops. As mentioned above, multi-level break and continue remove most of the need for goto statements.

Go does have goto.

Not check.

No more operator overloading

Same in Go.

Check.

No more automatic coercions

Same.

Check.

No more pointers

Most studies agree that pointers are one of the primary features that enable programmers to inject bugs into their code. Given that structures are gone, and arrays and strings are objects, the need for pointers to these constructs goes away. Thus, Java has no pointers. Any task that would require arrays, structures, and pointers in C can be more easily and reliably performed by declaring objects and arrays of objects. Instead of complex pointer manipulation on array pointers, you access arrays by their arithmetic indices.

Go has pointers, but there is no arithmetics on them.

The Java run-time system checks all array indexing to ensure indices are within the bounds of the array.

Same in Go.

You no longer have dangling pointers and trashing of memory because of incorrect pointers, because there are no pointers in Java.

Same in Go. Because Go is garbage collected, there are no dangling pointers in Go:

func CreateUser(name string) *User { return &User{Name: name} }

This is perfectly valid code in Go. It's possible to return pointers from functions. Pointers will not be dangling and they will not be garbage collected when the function returns. They will be moved to the heap.

Check?

Summary

• No more typedefs, defines, preprocessor: check?
• No more structures or unions: check.
• No more functions: not check.
• No more multiple inheritance: check.
• No more goto: not check.
• No more operator overloading: check.
• No more automatic coercions: check.
• No more pointers: check?

As it turns out, there are many similarities between Java and Go.

Author: Alan Urmancheev