Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning Go as a Python Developer: The Good and the Bad

new.pythonforengineers.com

Post reply on HN
Print view View original

131–140 of 269 posts

Re: Learning Go as a Python Developer: The Good and the Bad

#131

Post by darkarmani »

jjoonathan wrote: post #68
MonkeyMalarky wrote: post #59

Earlier quoted context omitted.

Don't forget Anaconda because you're on windows and have no idea how to compile random packages that are really C++ code with Python bindings!

Solving environment | Solving environment / Solving environment - Solving environment \ Solving environment | ... One day it takes 10 seconds, next month it takes 10 minutes, and the month after that it takes 30 minutes and then fails entirely.

Are you using conda-forge? Solving from over 6TBs of packages can take quite a while. Conda-forge builds everything. This isn't a criticism, but because of that the number of packages is massive.

Re: Learning Go as a Python Developer: The Good and the Bad

#132

Post by Zopieux »

mountainriver wrote: post #124

> The libraries for Go aren't as good as for Python– certainly, the documentation is lacking Huh, Go has some of the best autodoc features of any language. Also the library assertion is insane to me. I switch back and forth from Go to Python all day and generally Go has more stable better maintained libs

Sadly I agree with the author on the general feel of Go libraries. I can feel the language design itself and non-written philosophical identity of Go strongly affects what APIs people write in it. Most often, they suck. They feel monolithic, unforgiving, and impossible to extend. I don't belive we can only blame the lack of generics for that, it runs deeper.

On documentation, I've never seen a language community that comes with so little examples most of the time. Take any random Python library RTD, it's full of it. You can skim through said examples to understand the overall features and capabilities before you dive into the API reference. No such luck in Go: here is the bare-bones godoc, good luck!

Re: Learning Go as a Python Developer: The Good and the Bad

#133

Post by tptacek »

obviouslynotme wrote: post #78
37ef_ced3 wrote: post #52

Earlier quoted context omitted.

As an engineer who uses Go and appreciates it as a replacement for most purposes where you might use C or C++, the complaints just seem bizarre. You've got people who argue against explicit error checking and people who don't understand the important role of nil pointers and people who don't see the massive net win of garbage collection in concurrent programs, and so on. Endlessly. It feels like a waste of time defen…

Go has always been a Java, C#, Python, and Ruby killer. It has not and never will be a C or C++ killer. C is the language of libraries and embedded, neither of which Go is good for. C++ is the language of large systems that need extreme control over resource allocation. Go is not good for this either.

It is too easy for people to forget that C was not always the language of "libraries and embedded", and that writing large systems programs in C, of the sort that nobody would realistically consider writing that way in 2022, was a norm. Displacing C doesn't just mean rewriting existing C dependencies, but also changing the balance of decisions about which new programs to write in C. Go has had a tremendous amount of impact there. Without Go, Docker would almost certainly be a large ball of C code.

Re: Learning Go as a Python Developer: The Good and the Bad

#134

Post by cookiengineer »

I've been reimplementing a tool that was done in nodejs before and ported it to golang.

I have to say that a lot of programming paradigms are different in golang, a few parts are annoying, and some parts are "getting there" with generics.

The most annoying part if you do a lot of parsing is the golang mandated rule of what is public and what is private in a package. If you want to parse lots of JSON into a struct, mess is on you, always have to implement a custom marshal/unmarshal for it.

If you always have to implement a custom JSON marshalling method, and abuse annotations for mapping upper/lowercase properties...why was the uppercase rule mandated in the first place?

I wish golang had gone for an export keyword instead. Structs would have been so much cleaner.

The second issue I have with golang is that struct properties (as all data types) aren't nullable except via pointers, which makes consuming JSON APIs a fustercluck to deal with some times. I wish there was a nullable string data type instead of having to use dozens of helper functions.

The last issue is lack of functional ideas (as of now) but they are coming. lo is a lodash inspired library that makes a lot of things easier. [1] I hope that a lot of these helpers will at some point be part of the core libraries, so that datatypes can be easily mapped, casted and filtered.

[1] https://github.com/samber/lo

Re: Learning Go as a Python Developer: The Good and the Bad

#135

Post by fiddlerwoaroof »

tempest_ wrote: post #104
okasaki wrote: post #96

Earlier quoted context omitted.

Sometimes I feel people are using Python very differently than me. I just use pip freeze and virtualenv (these are Python basics, not some exotic tools) and I feel it works great. Granted, you don't get a nice executable, but it's still miles ahead of C++ (people literally put their code into header files so you don't have to link to a library), and even modern languages like rust (stuff is always broken, or I have s…

Comparing anything to C++ is a very low bar. I have rarely encountered issues in rust. Most rust crates stick to semver so you know when there will be a breaking change. My rust experience with Cargo can only be described as problem free(though I only develop for x86 linux). As for pip freeze and virtualenv things start to fall apart especially quickly when you require various C/C++ dependencies (which in various par…

The issue I’ve encountered in rust is looking at a library and seeing that it requires a nightly build of the compiler.

Re: Learning Go as a Python Developer: The Good and the Bad

#136

Post by fiddlerwoaroof »

okasaki wrote: post #96
jeremydw wrote: post #38

Earlier quoted context omitted.

This comment section itself clearly shows how crazy dependency and environment management is in Python. In this thread alone, we've received instructions to... - poetry - "Just pin the dependencies and use Docker" - pip freeze - Vendoring in dependency code - pipreqs - virtualenv This is simply a mess and it's handled much better in other languages. I manage a small agency team and there are some weeks where I feel l…

Sometimes I feel people are using Python very differently than me. I just use pip freeze and virtualenv (these are Python basics, not some exotic tools) and I feel it works great. Granted, you don't get a nice executable, but it's still miles ahead of C++ (people literally put their code into header files so you don't have to link to a library), and even modern languages like rust (stuff is always broken, or I have s…

When I was a Python dev, I never saw that happen in ten years or so of work. Pip freeze and virtualenv just worked for me.

I will say, though, that this only accounts for times where you’re not upgrading dependencies. Where I’ve always run into issues in Python was when I decided to upgrade a dependency and eventually trigger some impossible mess.

Re: Learning Go as a Python Developer: The Good and the Bad

#137

Post by wizofaus »

obviouslynotme wrote: post #119
wizofaus wrote: post #97

Earlier quoted context omitted.

Is Go really killing C# though? I've rewritten Go components in C# (the initial version only had basic functionality requirements, but as they expanded, Go made less and less sense given the rest of our codebase), but can't readily imagine wanting to rewrite C# in Go. Maybe once they add proper exceptions...

No. C# is usually used by Microsoft shops, and half the reason to use C# is so you can use Visual Studio.

That implies that if a better alternative to VS came along, C# developers wouldn't choose it! I certainly would, for one, and I'm a long-term VS user, well aware of its failings (but also yet to come across another IDE that's noticeably superior. And coding with a text editor and command line compiler is something I spent 10+ years doing when it was all that was available, and nothing I have any great hankering to go back to - even if it's something I still resort to as an emergency measure, e.g. when on some remote system with text-only access etc.)

Re: Learning Go as a Python Developer: The Good and the Bad

#138

Post by ActorNightly »

jeremydw wrote: post #38
ActorNightly wrote: post #6

>sharing your code is even pain with colleagues even if they are using the same operating system, mainly because the Python requirement file doesn't pin dependencies, wat? Pretty sure you can use == in requirements.txt Also, its very possible, and quite easy to just include the code for the library in your package, which effectively "locks in" the version. We did this all the time when building AWS lambda deployments…

This comment section itself clearly shows how crazy dependency and environment management is in Python. In this thread alone, we've received instructions to... - poetry - "Just pin the dependencies and use Docker" - pip freeze - Vendoring in dependency code - pipreqs - virtualenv This is simply a mess and it's handled much better in other languages. I manage a small agency team and there are some weeks where I feel l…

Its not a mess, people just make it a mess because of the lack of understanding around it, and getting lazy with using a combination of pip install, apt install, and whatever else. Also, the problem is compounded by people using Mac to develop, which have a different way of handling system wide python installs from brew, and then trying to port that to Linux.

Re: Learning Go as a Python Developer: The Good and the Bad

#139

Post by linsomniac »

ActorNightly wrote: post #6

>sharing your code is even pain with colleagues even if they are using the same operating system, mainly because the Python requirement file doesn't pin dependencies, wat? Pretty sure you can use == in requirements.txt Also, its very possible, and quite easy to just include the code for the library in your package, which effectively "locks in" the version. We did this all the time when building AWS lambda deployments…

I'm a huge, long time, python fan. I don't tend to have a lot of problems with dependencies, but it clearly is something that certain situations have problems with.

As I understand the post, the author is saying "It sure is nice to be able to just hand off a go executable and be done with it." And I think we can agree that the Python runtime situation is far from this.

I largely control my work environment, so this isn't a huge issue for me. But I'm right at this very moment converting a "python" to "python3" in a wrapper script because the underlying code got converted to py3 and can't "import configparser". (Actually, I'm removing "python" entirely and adding a shebamg).

I've been looking at writing a small tool in Python and then porting it to Go (I don't know go, so seems like a reasonable way to approach it), because the main target of the app is my developers, who probably don't have the right Python environment set up, and I just want them to be able to use it, not give them a chore.

Re: Learning Go as a Python Developer: The Good and the Bad

#140

Post by devonkim »

37ef_ced3 wrote: post #52
returningfory2 wrote: post #30

> I had heard of Go for many years, but never stuck with it; it gets constant negative press on Hacker News/Reddit I think on Hacker News it's really fashionable to criticize Go, and this has led to a culture where Go gets significantly more negativity than it deserves. As technologists, one of our most important jobs is to see through such fashions and judge languages/tools/technologies based on their actual merit.…

As an engineer who uses Go and appreciates it as a replacement for most purposes where you might use C or C++, the complaints just seem bizarre. You've got people who argue against explicit error checking and people who don't understand the important role of nil pointers and people who don't see the massive net win of garbage collection in concurrent programs, and so on. Endlessly. It feels like a waste of time defen…

I think there’s a lot of disagreements about what people think is desirable in a language in the first place and then start complaining without understanding the design concepts that shaped its creation nor even agree the problems are even problems to begin with. Many even seem to think that bad ergonomics are to be accepted and want to create a higher barrier for programming productivity (there are some merits to this attitude honestly but that’s not the point I’m interested in).

I think it’s more akin to trying to talk to people about Quentin Tarantino movies. Lots of people enjoy them, many critics like his stuff, and then there’s a relatively small group of people that disparage everything he does because he isn’t ascribed to any artistic school of filmmaking and under a lot of such critical analysis his films are pop fodder. It’s not like he ever makes his movies to please critics is the thing, he’s basically a super fan that just winged it all. Many fairly sane and measured, learned critics “get” Tarantino and appreciate him for what he tries to do and all is fine there. But it won’t matter what Tarantino does going forward with the other crowd - it’s because they have diametrically opposed ideas of wtf movies even are supposed to be.

Post reply on HN