So even though neither Python nor Go have websocket support in their standard libraries, it was much more obvious in Go how to do concurrency and what form the readers/writers should take.
In short, Go has good concurrency primitives baked into the language, and a much better-designed and cohesive standard library (Python's was designed over the past 30 years by a much larger collection of people; it's more bazaar than cathedral, with all the pros and cons that come with that).
Whereas in Go there's only one way and that's it. pretty much. Oversimplified maybe, but my point is, 'bigger' languages offer options, and options increase overhead.
I support having simplified subsets of languages - or rules in a company, whatever - that sets standards as to which language, stdlib and library features to use. Less options reduces complexity. At the cost of code volume maybe, but code volume is not and never has been the problem - complexity is.
In theory this would be very similar to what Go offers, in practice I guess we'll see once it's released, whenver that is.
Keen to know what extremes you're seeing in Python and Go unless you're referring to the static vs dynamic typing?
You can think of it as C with type safety and easy concurrency. That's it really.
Python is very "hackable", as in you throw something together very quickly. If that's what simplicity is to you then Python is simple. I don't think Python is that simple though, there's a lot of hidden behaviours due to things like operator overloading. It's not type safe and type hints are relatively new. Shipping a Python application is an exercise in itself. What's worse is downloading a Python project, running it, and then getting a random crash 10 minutes later at runtime only to find that you're using the wrong version of Python.
I can code Go as fast as I could code Python. I find Go simpler than Python. There's very little hidden behaviour and the behaviour that does feel weird is easily explainable. Shipping a Go application is as easy as sharing an executable. I'd pick Go over Python for all of my problems today because it's what I like, and there's many tasks where Python would be slightly better, but I don't think Python is well suited/well-rounded to all the tasks Go is good at. Like I wouldn't program a high performance websocket server in Python.
Sure, they say use the race detector. But then I say: sure, but I need to run it first.
Of course the race detector isn't holy either. Thread leaks are a thing and there's probably a detector for that somewhere too. But surely the parallel to messing up memory with C and its detectors (valgrind?) can be made, and I thought we were all pretty done with that.
I never shot myself in the foot with Java and Scala as easily compared to go, yet you almost get ridiculed for mentioning those 2 former languages.
This, good cross platform support and single file executables. I use https://www.py2exe.org, and it works great once you've figured out how to set it up. However, doing the same thing in go is simply `GOOS=windows GOARCH=amd64 go build ./cmd/...`
I love programming in python, so long as I don't have to ship it. That part is painful enough that it's worth considering other languages to avoid that headache alone.
My impression was that it doesn't really compete with C at all - it just can't given that it's garbage collected. How many projects that actually need to be written in C can be successfully rewritten in Go?
I see Go more as a replacement for Python that's compiled, statically typed, performant and has better concurrency. Great for backend, web APIs, CLI tools etc but you wouldn't build an OS kernel with it.
The other thing is you're saying _need_ to be written in C. Out of the millions of C applications out there, do you actually think the majority need to be written in C? C is good in a lot of places, like kernels, or very constrained systems, but would something like cURL need to be written in C? I'd argue not. A lot of developers swear by C because they like how basic it is. Go gives you almost the same levels of basic syntax and then stops you corrupting memory accidentally.
The other strength of Go is that it's trivial to target so many different platforms. I can take an application that runs on Windows and then run it on Linux. And then run that same application on an Arduino or ESP32 microcontroller with minor changes.
Maybe you wouldn't build an OS kernel to challenge Linux in Go. But people have built kernels in Go. There's nothing that prevents you from doing that other than the aims of your kernel. It's not stopped people writing kernels in Java or C# before.
That is the wrong way to ask the question. Almost no C program had to be written in C. The right way to phrase the question would be more like: how many C program could be successfully rewritten in Go? And I think the answer is: most of them.
The main speed difference between a C program and the same program written in Go is that the Go compiler is less good at optimizing the assembly output. There are very few tasks where the presence of a GC is prohibitive - if you don't generate garbage, it won't run. The Go GC is even written in Go, carefully scrutinized to not allocate dynamic memory.
I'm torn on this article. On one hand I love the simplicity of Wirth's languages. Oberon-07's language spec is 17 pages, including a 1.5 page BNF specifying the syntax of the entire language.
On the other hand my current preference in terms of language is Ruby, and while I dislike Python I'd pick Python over Go any day if I had to choose between them.
My impression of Go is similar to yours - it's a better C or C++, and it's conceptually simple-ish, but on one hand it doesn't match the simplicity in terms of syntax and semantics of Oberon, so if I wanted Wirth-like simplicity Go wouldn't even make the list, while it doesn't match the simplicity of use of Ruby or Python.
And if I had to pick a C/C++ replacement today, I'd probably opt for Rust over Go.
1. Tooling. Things like package management, single-binary deployment, profiling, etc are far simpler in Go than Python.
2. Performance. Optimizing Python is a painful endeavor. And the usual platitudes (e.g., "just rewrite the slow parts in C!") have significant caveats. Naive Go tends to be hundreds of times faster than optimized Python, and when you must optimize Go, it's typically just moving allocations outside of a hot loop or something trivial by comparison.
3. Concurrency. Python's async framework leaves a lot to be desired. If anyone calls a library that makes a sync call under the hood or uses too much compute, the whole process gets hosed and it's really difficult to identify the culprit. I also regularly see people forget to await the result of an async function--yeah, these are type errors and yes if you have the forethought and unlimited time you can write tests for any kind of type error, but this isn't a good use of anyone's time.
4. Rails. Go guides people toward good code. It guides people away from the kind of code that dynamic typing purists tend to write. For example, in the Python standard library, the type of an object returned by the `open()` API varies based on the value of an input parameter. Similarly, matplotlib, pandas, sqlalchemy, etc do silly things like this (although specific APIs aren't coming to mind). And of course there's a whole universe of junior engineers who try to emulate these things. As an aside, these rails are largely a matter of static typing, which also means automatic documentation (compared with Python's "x is a file-like object" with no information about what "file-like" actually means--does it support read? write? close? seek? truncate?) and great static analysis tooling.
Under those definitions, I agree some things in Go are not necessarily as easy to solve as in Python, but Go is definitely simpler.
Also what makes Go simple? This (From the article):
> If it worked ten years ago, it works now.
I have a collection of blog posts from the Go blog and other sources which I revisit from time to time and many are from indeed, ten years ago. Less cognitive overhead on figuring out what's from version x or y, if it's been deprecated, etc.
Go can be a great replacement for C, C++, maybe some Java stuff. Not for what you'd otherwise use Python, Ruby, PHP, etc.... right tool for the job. The "But channels are amazing and concurrency and speed and memory" argument doesn't matter as much for 90% of projects using it.
Back then, that was a unique selling point of the language for me. These days, those are quite diffrent.
Except for all the times where it does not, which is most of them.
It won’t force you to deal with errors (generally, it will in some cases as a side-effect of erroring on unused variable but there’s plenty of case where that’s going to be suppressed or irrelevant), it won’t force you to deal with nullable pointers (which is all of them), it won’t force you to deal with unsynchronised shared mutables (which is easy to do unwittingly, just send a map or a pointer over a channel), it won’t force you to lock the right mutex before manipulating those when you’ve thought of having one, it won’t force you to properly use debatable APIs like `append`, it won’t force you to deal with the possibility of typed nils, etc…
It will force you to remove or explicitly silence unused import though, because, you know, that’s what’s important.