When comparing Smalltalk vs Go, the Slant community recommends Go for most people. In the question“What is the best programming language to learn first?” Go is ranked 2nd while Smalltalk is ranked 15th. The most important reason people chose Go is:
The language is designed in a manner that seems logical. Syntax is simplified to reduce burden on the programmer and compiler developers.
Specs
Ranked in these QuestionsQuestion Ranking
Pros
Pro Environment of live objects
You can modify the system as it's running. You're "swimming with the fish", instead of probing a black box by remote control.
Pro Easy to learn and experiment
Pro Inspector makes objects transparent
Programmers must make detailed mental models of the system they are developing. Bugs usually happen when the mental model does not match the actual system. This is one of the greatest difficulties beginners have because most systems are so opaque. It takes a lot of effort to see what's really going on. But in Smalltalk this is much easier, thanks to the powerful tools included in the environment, like the object inspector.
Pro Superb Integrated Development Environment (IDE)
All tools (Inspector, Browser, Debugger etc.) are written in Smalltalk and are live objects in the environment. All sources are present, so that the tools can easily be studied, changed and experimented with.
The same goes for the other components like the compiler, OS-Integration etc.
Pro Pure and easy object orientation
Smalltalk is one of few languages that are purely object oriented. This provides a solid and easy to understand base on which to learn object oriented programming, the most popular approach to programming.
Pro Elegant syntax fits on a postcard
The syntax was designed to be easy enough for children to learn. Beginners can learn the language rules very quickly and then focus on programming without fighting the syntax at the same time. Things that have to be baked into the grammar in other languages are simple message sends with block arguments in Smalltalk. Expressions have only three precedence levels to worry about.
Pro Agile "interactive" test-driven development
Smalltalk had the original (and still the best) unit test system that inspired it in many other languages (like Java's JUnit). Working with interactive live objects in Smalltalk style TDD makes it easy to teach and learn TDD.
Pro Powerful integrated debugger
You can edit code and swap it in while the program is still running after an exception has already been signaled, or restart from anywhere in the call stack. You can inspect and modify the state of any object. Some Smalltalkers write unit tests and then program exclusively in the debugger.
Pro Internal source code and documentation
You can explore how everything works easily.
Pro Incremental compilation
Smalltalk provides an extremely fast code-compile-run-debug cycle. You don't have to stop and reset the world to tweak your program, since you can compile one method at a time while the environment is still running. This is great for beginners to experiment and prototype ideas.
Pro Inspired many other languages' object systems
Pro Open source
MIT licensed implementations Pharo, Squeak, Cuis & Dolphin
and GPL licensed GnuSmalltalk.
Pro Save and restore virtual machine image
A Smalltalk environment can save the state of a running program and later restore and resume execution. This includes the internal state of live objects, multiple thread stacks, and debugging sessions, making it easier for beginners to take the exact problem to an expert for assistance.
Pro Language uniformity
This leads to a very simple programming model (pure OO) that is still very powerful. A lot of stuff that is hard to implement in other languages is easier in Smalltalk.
Pro Graphical user interface
Beginners are usually stuck making command-line applications in other languages, because GUIs are too hard. Smalltalk GUIs are easy enough to start with.
Pro First-class functions with lexical closures
Also known as "blocks". These objects contain reusable snippets of code and as first-class objects they can be passed as arguments to other methods or blocks and also returned from them. "lexical closures" mean they retain access to the variables in the lexical environment they were written in, that is, in the surrounding code.
Pro It invented a lot of stuff
Smalltalk is the inventor of Just-in-Time compilation and the MVC concept, refactoring through their so-called refactoring browser and it was also one of the first adopters of a language virtual machine, closures, live programming, test driven development, an IDE and the development of GUI`s.
Pro As a first language, almost forces you to learn OO design
Hybrid languages (e.g., Java, C#, C++) make it easy to slip into procedural thinking. Smalltalk's pure OO approach makes it hard not to think in object-oriented terms. In addition, since the entire IDE and runtime components are there in the image for you to browse, you have plenty of examples of good OO design to learn from.
Pro Provides a functional way to interact with objects
Many languages today use object orientation, while the most of them stock on the half way in that perspective.
Smalltalk sees literally everything as an object and this includes things like the classes and primitive data types. There is are zero control structures such as selection and iteration, since all is done by sending messages to objects.
It use a lot of concepts from Lisp in order to provide a nice experience for this pure kind of object orientation.
It provides immutable data structures, closures, anonymous functions and higher order functions, while all those functions are objects. This is what makes Smalltalk so simple, elegant, and easy.
All this counts for Pharo, while other implementations as Amber are probably feature complete to it.
Pro Simplified C-like syntax that is as easy to read and write as Python
The language is designed in a manner that seems logical. Syntax is simplified to reduce burden on the programmer and compiler developers.
Pro Great team working behind it
Go has a solid team of engineers working on it (some of the best networking engineers in the world are working on Go). Up until now, the great engineering of the language has compensated for its lack of power.
Pro Easy to install and configure; simple to compile software
Go software can be immediately installed, regardless of your operating system, package manager, or processor architecture with the go get command. Software is compiled statically by default so there is no need to worry about software dependencies on the client system. Makefiles and headers are no longer necessary, as the package system automatically resolves dependencies, downloads source code and compiles via a single command: go build
.
Pro Programmers don't have to argue over what 10% subet of the language to implement in their software project
The language promotes programming in a specific idiomatic style, which helps keep every programmer on the same page.
Pro Supports 'modules' in the form of packages
Every Go source file contains a package line that indicates which package a file belongs to. If the name of the package is 'main', it indicates that this is a program that will be compiled into a binary. Otherwise, it will recognize that it is a package.
Pro Demonstrates a unique, simple concept to object-oriented programming
All types are essentially objects, be they type aliases or structs. The compiler automatically associates types to their methods at compile time. Those methods are automatically associated to all interfaces that match. This allows you to gain the benefits of multiple inheritance without glue code. As a result of the design, classes are rendered obsolete and the resulting style is easy to comprehend.
Pro Great language for building networking services
Go was started as a systems language but now it has fully committed in the niche of networking services. This has been a brilliant move by Go because it allows them to capitalize on the immense talent of the Go engineering team (who are in the most part network engineers).
In a world dominated by Java EE and slow scripting language, Go was a breath of fresh air and it continues to be one of the most powerful languages if you want to build networking services.
Pro Exceptionally simple and scalable multithreaded and concurrent programming
Goroutines are "lightweight threads" that runs on OS threads. They provide a simple way for concurrent operations — prepending a function with go
will execute it concurrently. It utilizes channels for communication between goroutines which aids to prevent races and makes synchronizing execution effortless across goroutines. The maximum number of OS threads goroutines can run on may be defined at compile time with the GOMAXPROCS
variable.
Pro The go compiler compiles binaries instantly — as fast as a scripting language interpreter
Compiled binaries are fast — about as fast in C in most cases. Compiles on every OS without effort — truly cross-platform compiler. As a result of the fast compilation speed, you can use the gorun program to use go source code as if it was a scripting language.
Pro Performance is on the order of C and Java
Go is blazing fast, but easier to write than Python, JS, Ruby, or many other dynamic languages.
Pro Jobs available
You can find a Job knowing Go. Which is more than can be said with many other languages.
Pro API documentation is rich in content; easy to memorize
Only features deemed critical are added to the language to prevent cruft from working its way into the language. The language is small enough to fit inside one's head without having to repeatedly open documentation. Documentation is hosted on an official webpage in a manner that is simple to read and understand.
Pro Supports functional programming techniques such as function literals
This naturally also supports first class and high order functions, so you may pass functions as variables to other functions.
Pro Multiple variables may be assigned on a single line
This conveniently eliminates the need to create temporary variables.
Fibonacci example: x, y = y, x+y
Pro Built-in unit testing
The idiomatic approach to writing a Go software project is to perform test-driven development with unit testing. Every source code file should have an associated *_test.go
file which tests functions in the code.
Pro Provides tools for automatically formatting code for your entire software project
This helps keep every programmer on the same page in a project and eliminates arguments over formatting styles.
Pro Automatically generates API documentation for installed packages
Godoc is provided to automatically generate API documentation for Go projects. Godoc also hosts its own self-contained web server that will list documentation for all installed packages in your Go path.
Pro Supports splitting source code into multiple files
As long as every source code file in a directory has the same package name, the compiler will automatically concatenate all of the files together during the compilation process.
Pro Syntax for exported code from a package is simplified to be less verbose than other languages
Any variable, type and function whose name begins with a capital letter will be exported by a project, while all other code remains private. There is no longer a need to signify that a piece of code is 'private' or 'public' manually.
Cons
Con OO is becoming obsolete
Smalltalk did it best, but the whole paradigm is a poor fit for the expected future multicore processors. Isolated mutable variables with no compile checks is a recipe for race conditions in multithreaded code. Beginners would be better off learning a functional language.
Con Not common
Smalltalk missed an opportunity to become mainstream when its implementations cost $5000 per seat versus $0 open source. New open source implementations (Pharo, Squeak) have minor corporate backers but not yet an IT behemoth. Direct jobs are scarce (but indirectly Smalltalk experience is very well regarded). Online communities are relatively small.
Con Not useful for mobile development
While Smalltalk is very powerful and easy to learn, it doesn't have a well supported mobile distribution, but you'll be spoiled for working in mainstream languages like Java, Swift or Kotlin where jobs are more readily available.
Con Virtual machine in its own isolated world
Smalltalk wants to be the whole OS. While this has tremendous advantages internally, interacting with the world outside the VM is not as easy as pure Smalltalk and must be done via a Foreign Function Interface.
Con Non-standard arithmetic ordering
Since every operation is considered a message sent sent is a specific order, all arithmetic operators have the same precedence. E.g. 2 + 3 x 4 translates to 2 + 3, and the result is multiplied by 4, giving an answer of 24 (instead of the correct answer - 14). Once you are learn this, it can easily handled using brackets, e.g. 2 + (3 x 4), but still a momentary suprise for beginners.
Con Golang controlled by Google
Solves Google problems, which might not be your or the majority of user's problems. Was created for the benefit and purposes of Google, so is less flexible in language direction and options.
Con Hard to abstract even the simplest notions
Go is famously regarded as very simple. However, this simplicity becomes problematic in time. Programmers who use Go find themselves over and over again writing the same thing from a very low point of view. Domains not already served by libraries that are easy to glue are very difficult to get into.
Con Forces K&R style and won't allow Allman style
Golang developers were extremely short-sighted and biased by forcing the K&R style, which should never have happened. Basically kicking Allman style users out of their language.
Con Doesn't have true enums
Golang does weirdness with const versus having real enums, like other languages. This reflects the stubbornness and shortsightedness of the core developers, similar to the issue with generics, where it was denied that it was needed until it became too obvious that it should have been added years ago.
Con Does not have sum types
Makes it harder to have functions of different parameters types in a non OOP language. Thus messy generics and interfaces, and more confusion, where sum types could have solved a number of issues.
Con It appears Google uses position to snuff out or suppress other languages
Newer languages that could threaten Golang (or other Google controlled languages) appear to have suppressed search results on Google and YouTube. Dangerous situation where large company can manipulate user choice and market share. The freedom to freely choose and user rights need to be protected.
Con Designed to make the programmer expendable
Go was designed for large team projects where many contributors may be incompetent. That Go can still get things done under these conditions is a testament to its utility in this niche. Go's infamously weak abstraction power is thus a feature, not a bug, meant to prevent your teammates from doing too much damage. This also means any team member can be easily replaced by another code monkey at minimum cost. Good for the company, bad for you. The more talented programmers, on the other hand, will be very frustrated by having one hand tied behind their back.
Con Easy to shadow variable
Due to single character only difference, declare and assign statement can easily shadow variable from outer scope unconsciously. Example:
err := nil
if xxx {
err := somefunctionthatreturnsanerr
}
return err // always return nil
Con No forms designer
Those who are used to Visual Studio can feel the lack of a forms designer for rapid development.
Con Bizarre syntactic choices like a unique date format.
Con Changing visibility requires renaming all over the code
Con Lacks support for immutable data
Only way to prevent something from being mutated is to make copies of it, and to be very careful to not mutate it.
Con Performance slowdown because of indirect calls and garbage collection
Practically no meaningful Go application can be written without indirect function calls and garbage collection, these are central to Go's core infrastructure. But these are major impediments to achieving good performance.
Con Implementation of interfaces are difficult to figure out
Finding out what interfaces are implemented by a struct requires a magic crystal ball. They are easy to write, but difficult to read and trawl through.