Its true, Go won't match the speed of C, but it comes pretty damn close. Say you have 4 cores, 1 would be dedicated to GC and the other 3 would be executing your program. That sounds sub-optimal, meaning that a Go program could only be 75% as fast as an equivalent C program. But you have to wonder how many developers are capable of writing multi-threaded, correct C code. Go is simple to learn, lightning quick to compile and runs reasonably fast. By no means is it perfect, and it is not the tool I'd use for every task in front of me, but it is good enough for most tasks.
I agree that Rust is the future in the low level space.
In my opinion, idiomatic golang is not that GC heavy. A slice (a bit like ArrayList) of structs can be a contiguous chunk of memory as opposed to array of object references, which requires allocating each object separately.
There are an order of magnitude less allocated objects than in Java for example. (Perhaps the situation will change once Java gains value types in maybe Java 9).
In my experience, you don't mean: learn to make C and C++ development just as easy as Go development and enjoy the best of both worlds.
I agree with you, but it seems illogical on the surface.
Last I checked golang generated code 3 years ago, it was full of redundant instructions, most notably redundant range checks. Seemed to be about half as fast as equivalent C/C++ code.
I believe golang can approach something like 80-95% of C/C++ performance once codegen is good.
While C designers were trying to create UNIX at AT&T, Xerox PARC was busy creating Smalltalk, Interlisp-D and Mesa/Cedar.
Other companies were creating Genera and the Connection Machine,
In the end Worse is Better won, because the machines were too expensive for most pockets, normal developers could not grasp Lisp, mismanagement from those companies and UNIX was kind of cheap when comparing prices, with source code available almost for free (AT&T was prevented from selling it early on).
And these figures aren't using the SBCL Lisp compiler which should currently be faster than the one cited.
You are correct, it wasn't designed to compete against C. And it has a garbage collector. But make the right choices and a compiler like SBCL can produce surprisingly "clean" (optimized) machine language code.
Sorry if dumb question but how is this possible when it's garbage collected?
Now I really feel like I need to learn a Lisp though.. Is there a certain Lisp you would recommend that's practical enough I'd use it for projects? Racket?
https://en.wikipedia.org/wiki/Genera_(operating_system)
https://www.ics.uci.edu/~andre/ics228s2006/teitelmanmasinter...
http://www.softwarepreservation.org/projects/LISP
Just check the hardware capabilities of systems having Lisp 1.5 support, several years before C was created.
Lisp is not only manipulating lists, it grew up to natively support all relevant data structures, including primitives to handle systems programming tasks.
Regarding GC and systems programming, there are plenty of GC enabled systems programming languages, the main point is that they offer features to control the GC and also do stack and GC free allocation if required.
Some examples would be Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Oberon-07, Active Oberon, Component Pascal, Sing#, System C#, D
On a big or complex system you end up at least doing one or both or two things:
a. Having to manage many temporal (transient) objects in memory. Thus you end up doing some sort of garbage collector, either doing it yourself, or using the facilities provided by the languages, or a library.
b. Allocating fixed big blocks of memory (such as arrays, or doing a "malloc") and then using this block of memory as your storage area, which then you manage.
Usually on C programming you do (b), although you can also do (a), it is not so easy.
Usually on Common Lisp programming you do (a) very easily, but you can also do (b) by allocating an array and a bit more stuff. It is not difficult, really.
Common Lisp lets you give "hints" to the garbage collector, so you end up with pretty much what you'd have in C but without the manual memory management.
> Is there a certain Lisp you would recommend that's practical enough I'd use it for projects?
Racket is very nice and comes with great documentation, a huge standard library and a very handy IDE. Clojure was hyped a lot so it has lots of libraries, which however might be of dubious quality or unmaintained by now, and it's on the JVM, which might or might not be a good thing for you. Common Lisp is very versatile and "pragmatic", but lacking in external libraries.
Go will be a significant speedup over Python, but likely won't quite match the speed of C/C++ for most tasks. Then again, the ease of development in Go will likely be noticeably better than in C or C++. Rust could potentially match the speed of C++, but it's a much more complex language than Go, so it will take some time to master. (Personally, having spent a large amount of time programming in Rust, I find myself more productive than in Go due to the powerful abstractions present in the former and lacking in the latter, but conventional wisdom is that this won't be the case for most people, and it certainly won't be when you're first learning Rust).
EDIT: Anecdotally I've heard that D is a nice language, but I have no experience with it, so I can't comment on how productive it is or how fast D code will run.