About unused imports, cannot you simply use formatter on build hook ?
Learning Go as a Python Developer: The Good and the Bad
91–100 of 269 posts
Re: Learning Go as a Python Developer: The Good and the Bad
#92TL;DR: Python is hard because of library dependencies, go is better about that because of compiling to an executable, but is pickier about code quality ("I just want to try something"), and has more issues with library quality.
I've encountered input libraries in go tha for some reason just grab all the signals and whatnot, so you can't ctrl+c, sighup, sigterm, use ctrl+z to return to the shell… the only option is to do a kill -9 from a different shell. Great library indeed :D
Maybe there's a go library that implements that "kill but make it look like an accident" functionality on HN a few days ago? :-)
Re: Learning Go as a Python Developer: The Good and the Bad
#93I realize that Go's original release is later than Python's, but they still feel roughly the same vintage to me. Usually, these articles have a "old to newer" feel, but these two ecosystems feel just different to me. Which is not bad.
What would be fascinating is to see some HN links to articles where the journeyman programmer went backwards in time, e.g. "Learning Fortran as a Python developer" or something like that.
Re: Learning Go as a Python Developer: The Good and the Bad
#94Earlier quoted context omitted.
i guess he's not using linux, otherwise python dependencies would be no problem
Docker is linux specific. It can only run in a VM on non-linux platforms.
It requires a linux subsystem, true, but not a fully fledged VM. The subsystem still shares the file system with the primary OS, for a start. And while I haven't tried it, the instructions for installing AppImage on WSL (for example) don't look trivial.
Re: Learning Go as a Python Developer: The Good and the Bad
#95I don't think Python packaging is as bad as people make out (if packages only stick to the basic features of Python!) A far bigger issue I see is despite Python supposedly being 'cross-platform': the language introduces so many small, backwards-compatibility breaking changes that you really need to use the most up to date interpreter you can.
For instance: there is now a really cool operator that lets you do expressions where you assign a value and evaluate the result in one line. So you can write the C equivalent of something like while(buf = recv(...)) ... and it will work. Well, any program that uses this new feature won't run on anything but the most bleeding edge Python versions. Despite a program only needing a small fix to remove such expressions. It wouldn't run at all.
I think the Python interpreter needs to be 'smarter' and add the capability to automatically install parallel Python versions if it detects a package using a more recent interpreter. Would honestly solve so many issues.
Re: Learning Go as a Python Developer: The Good and the Bad
#96>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…
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 some incompatible version, even when it builds it doesn't work)
By the way if you're a Python user, Nim is worth checking out. It's compiled, fast and very low fuss kind of language that looks a lot like Python.
Re: Learning Go as a Python Developer: The Good and the Bad
#97Earlier 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.
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...
Re: Learning Go as a Python Developer: The Good and the Bad
#98Earlier 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…
Now try installing tensorflow. Treat yourself to ice cream if you get it to install without having to reinstall Linux and without borking the active project you're on.
The major issues you'll see involve library version mismatches. It's a very good idea to use venv with these tools since there are often mismatches between projects.
Re: Learning Go as a Python Developer: The Good and the Bad
#99I hated the "damnable use requirement" (the error you get on unused imports) for years, but I've been keeping a count of how many bugs they've caught (I was surprised the first time this happened) and I'm up to 3-4 now. What people who code in Go seriously do is just hook `goimports` up to their editor, and then never think about this again.
How is this better than downgrading the error into a warning? You'd be able to build but would still know something was wrong-ish. Certainly a warning would be sufficient to chase down any bugs, and is very freeing compared to an error.
Re: Learning Go as a Python Developer: The Good and the Bad
#100Earlier quoted context omitted.
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.
That's half of why from 2017 to 2021 I had a yearly "uninstall Anaconda and start fresh" routine. The other half is because I'd eventually corrupt my environments and have no choice but to start over.
Me too. In 2021 it got so egregious that I finally jumped ship. Pip or bust.
Since you specifically mentioned 2021 instead of 2022, I half suspect you had the same experience.