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

261–269 of 269 posts

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

#261

Post by Ygg2 »

takeda wrote: post #260
Ygg2 wrote: post #214

Earlier quoted context omitted.

It's not. See https://imgs.xkcd.com/comics/python_environment_2x.png Or sometime the computer is haunted and my colleague had problems installing tensorflow. To this day he has no working tensorflow.

I suppose we can follow memes or facts. Please note I never used tensorflow on that computer in fact I never used tensorflow, but this is my experience: https://gist.github.com/takeda/89ec29501b6e8641415668f22f3e9... It succeeded after first try. I do see that in their repo[1] they use a non standard way to build the package. They use Bazel, but that's Google for you. They never do things everyone else is doing. I'm…

That's the thing. It's not a meme. It's a joke, that rings true.

It works fine for me.

Not for him. Same package, nearly identical laptops, different outcomes.

And I as newcomer to Python, there are like four (pip, venv, brew, conda) cli APIs that I had to learn just to get working on some Python file.

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

#262

Post by korijn »

throwawaymaths wrote: post #253
korijn wrote: post #219

Earlier quoted context omitted.

Ok, now I am curious :) let's try some typical problems from the Python package ecosystem: - Can you resolve precompiled GPU dependencies with system managed CUDA driver versions? - Are there packages that can convert PDF to PNG without system dependencies? - Can you run a Qt GUI app on CI without needing to do any additional system setup? With regards to cross compilation tools like burrito, that's neat! But Python…

1) not sure how Nx does it. 2) not that I can find for that specific task but the typical strategy is to download (or compile) a binary, drop it into a {project-dependency}[0]-local "private assets" directory, and call out the binary. This is for example how I embed zig pl into elixir (see "zigler") without system-level dependencies. Setting this up is about 40 lines of code. 3) wx is preferred in the ecosystem over…

So it seems python and elixir are not that different at all. You are handling these problems the same way as the Python community is.

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

#263

Post by scott_s »

bobbylarrybobby wrote: post #99
tptacek wrote: post #5

I 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.

I think it's important to know what problem the no-unused-imports error is solving. See Rob Pike's talk from 2012, and in particular, the section of dependencies in C++: https://talks.golang.org/2012/splash.article#TOC_5.

Basically, the point of no-unused-imports is to reduce compilation time at scale. In the C++ ecosystem, there are lots of redundant and unused #includes. This means that a lot of the bytes sent to the C++ compiler are just thrown away. If you can guarantee that the compiler will never need to look at a source file it does not need to, you can cut down on the compilation time. For small projects, this doesn't matter much. For large projects, it does. Go was designed for large projects.

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

#264

Post by fiddlerwoaroof »

mypalmike wrote: post #199
jhardy54 wrote: post #197

Earlier quoted context omitted.

Are you familiar with npm? I haven’t used it deeply in years, but the last time I checked it still supported conflicting dependencies. If A and B both depend on different versions of C, then both versions of C are installed and A/B see the version they want.

I've used npm but an not familiar with these kinds of details of it. There would seem to be some potential putfalls, such as two libraries accessing a single system resource (a config file, a system socket, etc.). I will take a look into this though. Thanks.

npm works around some problems like this with a concept of "peer dependencies" which are dependencies that can only be depended on once. The typical dependency, though, is scoped to the package that requires it.

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

#265

Post by smeagull »

stavros wrote: post #240
Game_Ender wrote: post #201

Earlier quoted context omitted.

Machine learning packages like Tensorflow can result in GB size package directories.

Yes, the biggest available library is big, that's hardly an argument though.

A really common library that gets used in every project for common use-cases is big.

It's a very good argument.

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

#266

Post by smeagull »

goodpoint wrote: post #236
smeagull wrote: post #150

Earlier quoted context omitted.

The real issue is that you can't have multiple versions installed at the same time. if you could import numpy==3.2 it'd solve many problems.

That's a feature, not a bug.

It's really not. I can't install tensorflow more than 10 times before I'm done. Virtualenvs are not fit for purpose.

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

#267

Post by stavros »

smeagull wrote: post #265
stavros wrote: post #240

Earlier quoted context omitted.

Yes, the biggest available library is big, that's hardly an argument though.

A really common library that gets used in every project for common use-cases is big. It's a very good argument.

No, saying "one common library is big" isn't a good way to show that "Python dependencies are big", which is what the initial claim was. Most libraries are tiny, and there's a very big one because it does many things. If Tensorflow were in JS it wouldn't be any smaller.

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

#268

Post by stavros »

morelisp wrote: post #251
diarrhea wrote: post #247

Earlier quoted context omitted.

Python 3.8 and its walrus operator is 2.5 years old, it's not bleeding edge, at least not anymore. That being said, I'm worried about the language in that complexity increases through the introduction of new language features without much benefit at all.

2.5 years is still bleeding edge for a backwards-incompatible syntax change.

It's not a syntax change, it's a new feature. If you know your version of Python doesn't support it, don't use it.

I think your issue is mostly with library authors who drop older versions just so they can use a slightly more convenient syntax.

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

#269

Post by blooalien »

stavros wrote: post #223
oarabbus_ wrote: post #192

Earlier quoted context omitted.

>But Python has a decent and a reproducible way of installing packages. Reading the comment thread it's not immediately clear what the answer is - it seems implied that the proper way is using Poetry, is that the case?

To me, yes. Poetry for me has been fairly straightforward, in anything I needed to do (dependency management, package publishing, etc).

Poetry has been the one I've settled on as well. It "Just Works™" for everything I've used it for thus far, and it's even been easy to convert older methods I've tried to the Poetry way of doing things.
Post reply on HN