I had to laugh (in a kind way) at this slide:
We have one in the Rust world, too, just the axes are different (Control vs. Safety):
It is interesting that the golang axes attempt to be accurate, where as the the Rust one is just the obligatory up and to the right (which may also be accurate, of course!).
People in my very unscientific survey suggest that Go:
Benchmarks suggest that Go is:
i’m not a huge fan of go viewed purely as a language, but if you consider “fast and fun for humans” as a sum of language + dev tooling + deployment, they’re selling themselves short on that axis, if anything.
3. is productive
To a point. There is a lot of copying and pasting, a lot of “verbosity” for the sake of … not sure what, but the don't DRY out quote from one of the posted slides sort of explains it.
don't DRY out
I like go for small projects, for large projects with lots of code it becomes an unrefactorable mess.
I don’t defend Go because I like it, mind you. But, I can’t ignore the speed in which I and others have developed pretty high quality, and scalable stuff with it, either.
I’m somewhat surprised by the existence of large projects written in go.
The language is <10 years old - either someone wrote a lot of code in a very short period of time, or we have different definitions of large (my first job after uni had >1million SLOC and ‘unrefactorable mess’ did not begin to cover it).
Kubernetes is in that range but i may have counted dependencies.
edit: 700k lines without dependencies, 1.2 million with them
There’s no clear definition of “large”. 1 mloc might be considered “very large”.
Ours is not large but we’ve had some transitioning of some of our services at gitlab to Go
Go offers several ways to avoid repeating code. Each has its own tradeoffs. Sometimes copy and paste is the most appropriate, but its hardly the default.
Re: large systems. I’m just getting there with Go and to remain effective I’ve rewritten a few packages multiple times. I see no evidence unrefactorable messes are inevitable.
Our startup switched to Go almost a year ago and we came to the same conclusions.
Can confirm that 4. is indeed very true, we were surprised by how easy it can be to output scripts that are still maintainable/readable and being written on a short timeframe.
Regarding 1. and 3. our feeling is that it clearly depends on what is being implemented.
As soon as the project requires a lot of business logic, in our experience, expressivity became clearly a problem. We ended with a lot of boiler plate and some rather boring code but it still executes pretty fast so it’s a fair tradeoff. Maybe with more experience this will come better, we’ll see. If anyone could point me toward resources addressing this, that’d be awesome ! :)
On the other hand, when it comes to writing stuff that needs to be fast and mostly does one critical thing, the results are speaking for themselves, code is simple and concise and pretty damn fast. It’s not that we couldn’t have written it in C, it’s just that it’s really comfortable to do it in Go and quickly yield clearly solid results (for us).
Still our team feel some frustrations regarding the lack of abstractions, but we’re solving this from now on by using Go mostly in the latter scenario.
There’s also Simon Peyton Jones' chart, where the axes are “usefulness” and “safety”.
<3. I love how this is obviously from the time where STM seemed to be the topic of the day.
Also: I have a horrible, horrible memory for faces. Is that Erik Meijer in a shirt with just two colors?
Also (II): Interesting that the idea of bringing SQL stuff back into the programming languages has worked out.
This is a favorite video of mine, for a couple of reasons:
As a real world example of #2, I presented at the same conference as this presenter, and he came up before mine to introduce himself, say hi, and ask if we shouldn’t grab some lunch sometime since we both live in NYC. I was very humbled. I wouldn’t say the Rust and Go teams know each other super well, but we’re extremely friendly and respectful of each other’s work, generally speaking.
This slide looks like it was written by someone who doesn’t even know C++. They put Go way above it, but put C only barely below it.
This is completely wrong; it should be the other way around. Go is only marginally easier than C++, while C++ is much easier than plain C.
You are aware that this is a slide of a rust core member? They probably know C and C++ quite well.
All slides are marketing material and the grouping isn’t scientific.
C++ is much easier to write than C is but not necessarily to read (other’s people’s code). Because of how verbose Go is, it is much easier to read other people’s code.
Business always wants to somehow blame us for being the victim of ‘identity theft’, but in reality, it’s they who are responsible for ensure they are not the victims of fraud.
Don’t let companies get away with blaming their lax measures on you if this happens.
What can we really do about this?
Take your wallet to a different company. Change the carrier. If you can’t swap out to a different company consider giving them less business with a pre-paid phone plan for example. Burden them with support costs and dispute all charges that were fraud, even if you lose and won’t get reimbursed they will feel the cost required for handling your support request / claim processing. Most of all, make your friends aware that they should be doing the same. Companies will start caring when they see money going a different way.
This process is very frustrating. It would be really cool if we adhered to a strict policy that would not push away people that are genuinely interested in contributing