I feel like you should spend some time with Go. If I were building a startup, I would probably choose Go for core infra for being able to move quickly as a developer and write incredibly performant code with about as much mental overhead as most dynamically typed languages.

Anecdotally, I've seen it replace Java in quite a few small and medium sized established companies.

I feel like Python is your pepperoni pizza can't go wrong option for almost anything.

Go feels similar but younger. I love languages with big standard libraries. Just need their package management story to settle down for a while.

There's something wonderful about a language being so popular and around for so long that there's plenty of resources and answers on just about anything. I think that's a core part of what I'm missing from Go.

Python can go wrong for large codebases. There are exceptions, of course, but if I focus on the consensus: large code bases in a dynamic language have an anecdotally significant likelihood of becoming unmaintainable. It's a glass ceiling that almost everyone I've met, who has done serious work with a dynamic language, has encountered.

There are ways to deal with it, but it requires rigorous discipline, and resisting Python's dynamic siren call earlier on in the process.

Golang naturally guides you into a style of programming which scales. You're not fighting the language (or your own inclinations) to avoid getting entangled later on.

Everything has exceptions†, you can shoot yourself in the foot with anything, yes. But, reasonably, it's about the relative struggle to end up in a similar place. Which is higher for Golang initially, but higher for Python later on.

Not trying to turn this into a Python vs Go thread; they both have their place. But Python can definitely go wrong, in an area significant to many people.

† Except Go... T_T

Most of the workarounds seem to boil down to de facto static typing in function signatures. That is, using annotations / rigidly formatted comments to provide the type information necessary for IDE support.

Yeah I'm inclined to agree the more I think about it.

If Go adds generics and a smoother method of doing error handling, I could see it eventually taking Python's place. It already is doing so to an extent, but with those features plus everything else it can do better than Python, it'd be tough to beat. 95% of my programming is in Python, and I honestly don't really enjoy coding in Go that much, but with those changes I could see myself switching.

Same. 99% of my back-end and robot code is Python. Maybe this is a grass is always greener kind of thing but I'm hitting projects of a size where I miss static typing.

I will say that asyncio is amazing and really solves concurrency for me. But Go looks like you also get parallelism without a lot of work.

Asyncio is good but it will not give you true parallelism: asyncio still uses the GIL, on a single thread

Yep. Concurrency is not parallelism. But a lot of the time it's just not necessary.

On the other hand if Python community had more love for PyPy, to follow up on JavaScript and Julia footsteps, maybe that wouldn't be even an issue.

Go targets a number of performance sensitive systems programming contexts where Python would be completely inappropriate.

Its beauty is that there is so little to it. You don’t need StackOverflow to discover/debug a clever way of expressing something because there is no clever way. It feels limiting until you learn the idioms.

Package management has indeed been extremely painful, particularly in the Glide era, but Dep and VGO are both solid.

Python is wrong for anything performance sensitive (unless the performance part is already written in C/C++, like TensorFlow).

Performance sensitivity is a rather relative line, I understand your point but I’ve heard people argue that C was the performance sensical choice as opposed to C++, or assembly rather than C. I love python but I wouldn’t use it for everything. I really enjoy Go but the use cases for me are smaller than most people I know that use Go daily. At work we have to use Go and I’ve had to make the argument to use JVM for some services and Erlang/Elixir for other use cases. I could’ve done everything in Go, but it really felt more dogmatic than pragmatic

> I would probably choose Go for core infra for being able to move quickly as a developer

At the company I used to work at it took nearly a 1000 lines to replace an 80 line bash script. So I can't help but laugh at this statement.

I've helped port some bash-based CLI tools to Go. The amount of code produced was pretty similar, just some overhead for typing and adapting some of the `awk` and `sed` functionality to be self-contained in the program. What kind of stuff was this 80 line bash script doing that resulted in over 12.5 times more code?

Since when LoC is a meaningful metric?

Since always but it depends on what you actually take into account.

More LOC means more opportunities for error, and more resources needed to review that code and more time required for a new developer to get familiar with the code base.

That said if you have 85 LOC vs 1000 it usually means that the 85 LOC “app” used a metric ton of external dependencies which are on their own a good source for problems.

When comparing apples to apples (as in both apps use dependencies equally) I don’t see how such delta can be caused by using a different language, even using assembly would likely not cause this much inflation.

I LOLed on this one :) I can literally double LOC in any project, just by putting { } on separate lines

If you LOLed at this one you likly don’t understsnd how LOC are counted.

How well did the bash script handle exceptions?

I can replace those 1000 lines with a bash script of 1 line that just calls the Go program ^_^