Why Go and Rust Are Not Competitors (2015)
dave.cheney.net
dave.cheney.net
Go competes for mindshare in the post 2006 Internet 2.0 generation of companies who have outgrown languages like Ruby, Python, and Node.js (v8) and have lost patience with the high deployment costs of JVM based languages."
Though I guess the same applies to PHP.
It's a lot nicer to write webapps in Go though since you have control over global state and not the per-request state of PHP, which makes for some easier solutions to problems (work-queues are easy to implement/use on the server-side unlike in PHP)
Also the stricter type system compared to PHP is nice in addition to static linking making it more portable than PHP (minus not being portable to shared hosters)
Guess the global state access and easier parallelization are the main selling points.
I wrote a few APIs with long running queues in PHP and Node.js and found it both a bit too clunky for that job.
A fix for master programmers is e.g. Rust, and a bunch of GC-based languages, from newcomers like Crystal and Nim to the battle-hardened JVM ecosystem, or Erlang/Elixir.
The way C++ did not displace C, or the way Ruby and Python did not displace PHP, these guys will not displace Go.
Longtime systems and UNIX pros, not language/compiler pros though. That would be someone like Anders Hejlsberg or Lars Bak respectively.
No, that was because the focus of Dart (replacing JS on web browsers) wasn't feasible, and even Google dropped it. Which says nothing about the quality of the language (which was selected for the Flutter SDK anyway).
Besides, popularity in tech, as in high school, doesn't say much. Engineering shouldn't be a pop culture.
>What about C?
What about C? That was made by Dennis Ritchie, not involved in Golang. And even so, it's not the best basis for a 2007-2017 language.
As far as Go design is concerned I believe that someone who designed few programming languages can be called a "pro" even if he doesn't agree with the mainstream opinion about what makes a good design. Simplicity is underestimated.
There are bunch of comparisons Hugo vs Wordpress on internet.
Good static site generators are many. The point of a product might be near-zero transition friction.
However if someone is coming from PHP, Go must look positively modern. Considering the millions of PHP programmers out there, Go can keep on growing for a long time.
Not to mention the fact that go fmt makes everyone’s code look exactly the same. No more weird, personal styles being brought into into source code or pointless discussions of naming conventions or indentation.
But what about static linking, fast compile times and awesome standard lib is like "stepping into the feature"?
Standard lib is just plain awesome. You can build most things right out of the box without searching the web for competing versions of the same thing. Web apps are a great example.
Fast compile times was a feature built into Go from the beginning. Presumably from people frustrated by compile times of large C/C++ codebases [1]. It’s about developer productivity.
1. https://golang.org/doc/faq#What_compiler_technology_is_used_...
Because they are invented at a time before storage and RAM is dirt cheap and lightning fast. It was painfully wasteful and slow to load a copy of the standard library for every process. Dynamic linking was invented basically because static linking wasn’t feasible.
Oh, and the IDE environment is amazing - you literally don't need much more than VSCode or vim (the language tools have built in refactoring support, formating, quick compile for syntax error, godoc).
And you have closures, something Java didn't have until 8, and even now many libraries don't support it.
That said, it certainly is more complicated refactoring arbitrary data flows. There is certainly a cost for all the benefits! :)
They also kind of hit a wall around 1-2GB of memory that took ages to get past with GC. It had the potential to kill your 95th percentile numbers to have long GC pauses. It contributed to things like Redis and Memcached taking off because of how frequently you needed data close to you but couldn’t just keep it in process.
Its actually trivial to deploy and updates are just pushing one file; your uberjar. This is so much better than anything node/ruby/python/php have to offer.
I also feel much safer running code in a VM on the server than directly native where a single invalid dereference brings down the whole thing in a rain of fire.
The entire point of java was that bytecode is portable, it's "write once, run anywhere". Don't make me build your stupid .jar and figure out all your dependency / build-time issues, just give it to me!
I write exclusively Clojure on the JVM now; its like having all the advantages of the JVM and none of the inconvenients of Java!
With go you can just run 'go build' and get static executables for all common platforms with zero dependencies.
The key difference between that and just throwing jar files on random systems is that static executables truly work anywhere and will never crash because you don't have the right version of JDK and usually won't need messing up with arcane command line parameters or .properties files.
Deployment is one area where Go truly shines and I guess that helped its popularity. PHP also got immensely popular due to ease of deployment, although of a different kind, in a different era and with different expectations.
Yes, I think that was in an article by Rob Pike, might have been his article titled "Less is exponentially more."
Edit: Found that article:
https://commandcenter.blogspot.in/2012/06/less-is-exponentia...
Excerpt: [ I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. ]
https://blog.learngoprogramming.com/about-go-language-an-ove...
...that was used to build OS's and other system stuff. Here's a brief history I just submitted and the official pages.
https://news.ycombinator.com/item?id=15704806
The Delphi product and the Oberon offshoot Component Pascal were used as C++ replacements. Here's an IDE for Component Pascal:
http://blackboxframework.org/index.php?cID=home,en-us
So, the point is that it's a variant of a Wirth-style language for writing operating systems and low-level apps. With that, many of us figured it can also target the same thing. It might need some modification in its runtime or something if not originally aimed at it. I see no reason why a language stronger than Oberon couldn't be used for at least what Oberon was used for, though. As partial evidence, people are already writing prototypes for OS's in in.
https://news.ycombinator.com/item?id=14537691
https://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item
Throw in real-time or selective GC's as a modification to get it closer to taking over a lot of stuff that C would be doing. There's also nothing stopping the low-level code from being straight-up unsafe with checks added by programmer since that's already the baseline with C. One would get a more pleasant language that was at least memory-safe in other components that could take a GC. House OS is an example where the H Layer wraps the unsafe, lowest-level parts of the kernel of an OS mostly written in type-safe Haskell.
I develop in both Go and Rust.
I use Go as main replacement for .NET/Java web tier...no need for install specific Java or .NET run-time library.
I use Rust when there's heavy disk reads and writes...and I know it's a nightly job which should never segfault and never finish the execution since it crashed.
GO = useful for rapid prototyping and a good .NET/JAVA middle-tier replacement.
RUST = you CARE about performance.
You can use both with FFI/C - use Go as the carrier and use RUST where the functions should squeeze every bit of performance to do something...
Its really, really hard to beat the iteration cycle of a Lisp.
To be fair, concurrency is baked the Rust type system itself. It's certainly a first class concept. I think the better way to describe it is that Rust wants to make concurrency safe regardless of what mechanism it's based on (system threads, futures/asyncio, maybe other things eventually?), while Go wants to provide a particular (very convenient) mechanism as part of the language.
Rust do not have language constructs for any concurrency/parallel model, and this is a good thing. You can use fork-join, parallel iterators, mutex, rwlocks, channels (mpsc, mpmc...) or any other model as a library.
The nice thing is that, as you say, is the type system the component that guarantee a free from data race code in safe Rust.
"For that reason, Some smart Google engineers decided that it’s time to address the limitations of C and C++ by designing a new programming language: Go. [...] Go is based on the C programming family, one of the most widely used programming language trees in the world [...] Go attempts to combine the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++.We’re hoping Go turns out to be a great language for systems programming with support for multi-processing and object-oriented design, with some cool features like true closures and reflection.”
I was there when it happened, so regardless of the way go is being used and what it's being touted for now, in 2009-2011 it was all about Google's new systems programming language, set to replace both C and C++. And it was very clear that by "systems programming" Pike et. al meant any kind of job that was traditionally relegated to C/C++: http://www.informit.com/articles/article.aspx?p=1623555
Rust came out only slightly later and was also touted as a system programming language. From the the rivalry sprang out.
It turns out that Go's trade-offs and focuses (implementation simplicity, relative familiarity, static compilation, solid tooling, solid stdlib and easy concurrency) fit well for its eventual target demographics of web servers, networking and command line tools. These are all places where C/C++ had some foothold, but more often than not Go was replacing (or competing with) Ruby, Python or Node.
Rust, on the other hand, took over most of C++'s trade-offs and focuses (Zero-cost abstraction, expressive power and full control over memory management) while relatively neglecting I/O, tooling, ergonomics and the stdlib in the beginning. This attracted a very different crowd that looked to solve very different problems.
People are move the goal post here.
Go has failed it's first goal. Rust hasn't.
But Go pivoted, and succeeded at their new goal.
But what did React steal from Ember and what did Rust steal from Go?
I only knew about CRA.
Some of the points to be made here is that C and C++ are being used for a very wide range of applications
So if you do compare Go and Rust, you will find distinct technical advantages and disadvantage
Rust/Go are currently the C/C++ alternative
I like to think of it this way (image the line below is the range of software c/c++ is being used for, systems software on far left and apps on far right)
(systems)------------------C/C++------------------(apps)
People coming from left prefer Rust, people coming from the right prefer Go
Once you’ve learned all of the ins-outs of C/C++ then you don’t have an incentive to use Go to replace them. When you don’t need performance you can use a scripting language like ruby or python. I see this happen often.
> Some of the points to be made here is that C and C++ are being used for a very wide range of applications
That's a really good point. C is an odd language: people used it to squeeze every ounce of performance out of machines, even when they didn't need to. E.g. an ls or cat written in C is almost certainly a premature optimisation. Even a program like Sendmail should probably have been written in something like Lisp or Go (had it existed) rather than in C (and anyone over a certain age knows the high price of Sendmail being written in C: vulnerability after vulnerability).
People were using C almost as a scripting language, which in retrospect is insane. Using it as a portable assembler to build the bulk of an OS, or at least the low-level parts of an OS, made sense — trying to use it for high-level programming was a mistake.
I write Go every day, but I'd like to take a look at Rust eventually. I wonder if decent Rust can be written as quickly as decent Go can.
Before C++ and some of the less and more recent higher-level languages became available and were stable enough, people were writing both business applications and desktop / server software products in C - a lot.
Biz apps that required database-like functionality were written either using ISAM-type libraries or low-level proprietary database APIs (specific to a particular database server) or using embedded SQL in C (e.g. Pro-C for Oracle, ESQL/C for Informix, DB-Library for Sybase, etc.
And lots of successful Unix and Win32 software products were written in C, for both the logic and GUI parts of the apps. I've worked some earlier on real projects / products of all those types I mentioned (except Sybase).
Some higher level products such as 4GLs also existed (for reporting and other purposes) and those were used too, but C was still used, even for business apps. When there were less of good higher-level-but-still performant choices available, and hardware was not as powerful, it was not an insane option at all.
Plus, as is known to C programmers, "in C you can do anything." Not many higher-level languages can say that - except by linking to C libs via FFIs of some type. Obviously there were cons involved too, such as string handling, memory and pointer management, and less productivity than higher-level tools.
https://en.wikipedia.org/wiki/Embedded_SQL
https://en.wikipedia.org/wiki/Pro*C
https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0...
like "micro controllers, AAA game engines, and web rendering engines"? I highly doubt it! Swift 5+ might have a chance but Go has none(as it is now).
As long as it lacks Windows support Swift has no chance to be even considered for an AAA game engine.
C# is about the closest thing these days thanks to value types but even then Unity had to drop down to C++ to really get the performance they needed at the engine level.
C# is fine for scripting, but absolutely terrible for performance critical batching where branch predictions and cache misses are your main optimization points.
Also the lack of array slices make it really hard to avoid memory allocations.
I love scripting languages for orchestrating logic(luaJIT!) but when you need to massively vectorize your data so that you get full utilization of the prefetcher there really is no substitute.
http://stroustrup.com/applications.html
A big list.
Also, most of the applications never allocate because they can't even afford the overhead of pooling/freelists that come with a stock malloc implementation.
You're using value types and raw pointers in those targets because even the memory overhead of a heap/freelist/etc can be too much. With things like AVR you're looking at 512B to 16kB of total memory(part of which includes the code you write).
i'm not sure i follow - you're saying that a gc existing implies that one cannot preallocate and avoid dynamic allocation?
This will still use dynamic allocation to do the preallocation. You'll have a heap to track this which comes with its own overhead.
I believe the C/C++ developers will look for a Rust-like solution(even if I don't like Rust) rather than Go if crashing is an issue. Go doesn't solve the crashing issues. It has its own crashing issues(e.g. dereferencing nil pointers , deadlocks, data-races, nil and nil interfaces etc). If the GC is not an issue they can choose any other GC language so Go is not that special anymore in this regard. The truth is that Go has its own niche and that's web services.
Last I checked it had absolutely terrible reflection capabilities and meta-programming; both of which are used as the foundations of modern engines.
A game engine is also radically different than your usual use of Rust; its almost impossible to model with borrows without going dynamic and those come with runtime overhead; something not acceptable when you're used to zero-cost abstractions.
A web rendering engine has ridiculously less state and moving parts than a game engine. D would be a much better fit for game engines than Rust.