I really found "still" to be funny because I think for many Go devs (including me) the simplicity and lack of features especially enables us to create more easily.
It's the opposite of standing in front of giant fridge shelves in the supermarket with 100+ kinds of yoghurt where you have a hard time deciding. You only have a few choices so you just go ahead and pick one/just do it.
Forgive my bad analogy.
But when it came to Go, I personally found myself battling the language as a result, rather than being more productive with it.
Ultimately if it makes you more productive, then that's awesome and that's all that matters.
Yeah man, it must be so fun doing large-scale construction work with just a hammer and a shovel; so easy to use, so easy to learn. Who needs caterpillars, pneumatic drills and such.
Last time I checked, Brainfuck is easier to learn than Go (more simplicity!!!, and runs in even more platforms.
I don't agree that Go has only "a hammer and a shovel". It has at least a saw in its toolbox too.
On a more serious note.. fun is highly subjective and the brainfuck / simplicity argument is just useless.
Just like if you're building a small tool to wrap another you might just choose to use bash over Java, it all comes down to what you need most commonly vs what would "be nice to have".
>build large barns entirely
Not the same 'large-scale' construction work I had in mind.
So naturally I used many programming languages with Go's limited set of features, which doesn't mean I want to return to those days.
I started programming a few years later than you.. first on Atari ST (Basic) then later in DOS (Pascal). I often wish myself back to these systems when I see today's bloated stacks of crap (obviously this does not apply to everything).
I don't think this is relevant for the original discussion though..
Even the last version of Turbo Pascal for MS-DOS (7.0) was more feature rich, ignoring the lack of GC for a moment.
type Colours = (Red, White, Blue);
type Colours int
const (
Red Colours = iota
White
Blue
)
function Sin(const num: Integer): Double; external 'ext name';
// #include <stdio.h>
// #include <errno.h>
import "C"
func Sin (num uint) float32 {
return C.sin
}
procedure Swap(var a,b:Integer);
var
temp: Integer;
begin
temp:=a;
a:=b;
b:=temp
end;
Swap(x, y)
Swap(nil, y) { compiler error: Got "Pointer" expected "SmallInt" }
func Swap (a *int, b*int) {
var temp = *a
*a = *b
*b = temp
}
Swap(&x, &y)
Swap(nil, &y) { runtime error: Invalid memory address or nil pointer dereference }
Ah, and Turbo Pascal 5.5 was compiling around 34 000 lines/minute in computers whose CPUs were maxed at about 30 MHZ, http://edn.embarcadero.com/article/20803
Regarding nil safety, did Pascal allow something along the line of the following?
var x: ^int;
...
x^ := nil;
Swap(x^, y)They can be used as indexes, range validation, access control in variant records to simulate sum types.
Enumerations are so useless that majority of modern languages have direct support for them.
Yes, it did allow your contrived example, which seldom occurred in practice because proficient Pascal programmers only used pointers when other type safe alternatives weren't possible.
I was ultimately looking for a versatile language that I could use for my personal projects outside of work and thus I was indeed trying to find a single language that could do everything I wanted. Up until this point, that language has been Python.
Go is clearly sufficient for many very successful and amazing projects (many of which I use daily, like Hugo, Terraform, Docker .etc), so developers can still produce excellent tools with its limitations. But in saying that, the language is not for me, and that's okay; if it works for someone else, then that's okay too. Go does lack various features that many developers want, including me.
Fun fact, the blog post was generated by Hugo ... which is written in Go :)
With regards to Nim, yes, my experience with Nim is limited and I am still hoping to learn it further and do a more thorough evaluation. Hopefully I'll spend a good amount of time with Nim in the future to give it more of a fair go.