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

Things from Python I'd miss in Go

yosefk.com

Post reply on HN
Print view View original

51–60 of 142 posts

Re: Things from Python I'd miss in Go

#51

Post by adwn »

Touche wrote: post #33
adwn wrote: post #20

It's ironic that the author dismisses C++ to a small niche: > Those who still stick to C++, after all these years, either really can't live with the "overheads" (real time apps - those are waiting for Rust to mature), or think they can't (and nothing will convince them except a competitor eventually forcing their employer out of business). Yet later he gives a good example for an important area where C++ is still unb…

I don't understand your complaint, isn't "scientific computing libraries" a niche?

> isn't "scientific computing libraries" a niche

In a way, yes. The point I'm trying to make is that there are many niches that require the performance of C++ [1], while the author implied that there's just a single one.

Sorry, I should have been clearer on that.

[1] If you're not convinced, I can give you a lot more examples.

Re: Things from Python I'd miss in Go

#52

Post by swasheck »

klibertp wrote: post #38
Kurtz79 wrote: post #4

Sometimes we get so invested in a language that we forget that it's just a tool, and a good engineer/hacker should try to choose the best one for the problem at hand. Go is just another tool in our toolbox: as the author says it sacrifices some of Python's friendliness and ease of use (but not as much as other compiled/statically typed languages) and features for performance and a solid concurrency model. It's up to…

I try to advocate polyglot programming - using the best tool for the job - everywhere I go, but unfortunately people are largely allergic to the idea. Most programmers don't want to learn new tools, much less new paradigms or methodologies. Even worse, the management agrees - the upside of building better systems isn't convincing enough to justify a temporary drop in performance while learning. More to the point, I d…

Though I agree with, the primary argument that I've heard has always been that fragmentation/heterogenous systems in a corporate infrastructure make the human and capital management more of a nightmare.

Re: Things from Python I'd miss in Go

#53

Post by philbarr »

S4M wrote: post #46
jamra wrote: post #29

Earlier quoted context omitted.

It looks like the author found the worst use case for Go in comparison to a library that Python absolutely soars in and uses that as a basis for this argument. Go does not have something as nice as numpy. For numeric computing, by all means use Python. He then makes some crazy statements about operator overloading as if that is the essence of a good language. I disagree. I don't want operator overloading. I almost ne…

> I almost never used operator overloading in C# or Java. Dude, you can't overload operators in Java. You can overload methods of a class, but not operators. Operator overloading means that you can overload '+' for example for your particular class, which would enable you to write code like (in Java): Matrix a = zeroMatrix(4,4); Matrix b = identityMatrix(4,4); Matrix c = a+b; You can't do that, so you would have to w…

As it stands you can't in Java but you can in C#, although it's usually a really bad idea.

Re: Things from Python I'd miss in Go

#54

Post by phazmatis »

Goranek wrote: post #9

In the beginning i missed repl, but i've realised using repl in the first place was a mistake.. Now i rely on docs(godoc is awesome) and when i need to test something i use go playground.

The REPL is part of my TDD loop... Which is actually, write a test, come up with a plan to make it pass, google for the programming constructs I need in the language I'm using, test a snippet (or a fully functional line) in the REPL, copy over to my project, make the test pass, ..(refactor). Without the REPL I would have an extra cognitive overhead of wondering if I had introduced a bug through misunderstanding a sketchy part of the docs.

Re: Things from Python I'd miss in Go

#55

Post by kyllo »

rogerdpack wrote: post #16

Did he say that people looking for faster build times than C++ went to java? They may not have found what they were looking for, in that case... Go does lack a quality [IMO] IDE [re: REPL use is for development], but that can still come with time. Quality GUI bindings can also come with time [how often do you actually use Python for GUI stuff, though...but still nice to have, just not its major use I doubt] Another t…

Another thing you'll miss from Python is accidentally typo'ing variable names and having to discover that only at runtime :)

    python -m compileall .
:)

Re: Things from Python I'd miss in Go

#56

Post by zimbatm »

drdaeman wrote: post #22
zimbatm wrote: post #19

Earlier quoted context omitted.

The readConfig example is not really an issue in go. Just return the io error and type switch after the readConfig. if config, err := readConfig(ioReader); err != nil { switch err.(type) { case io.ErrClosedPipe: // do one thing case ParseError: // do something else case ... } }

> Just return the io error Manually, on every function call that may fail - that was my only point why exceptions may result in a clearer code. section, err := parseSection(ioReader) if err != nil { return nil, err } Has some boilerplate, as compared to a typical exception-based section = parseSection(reader) // throws IOError

Yeah I get what you mean.

If you forget that "throws" comment then the Java code is opaque to the exception. I think Go developer see a value in having errors exposed explicitly, it forces them to think about how to handle them instead of having a catch-all at the top of the program. But now we're down to philosophy and personal taste :)

Re: Things from Python I'd miss in Go

#57

Post by jerf »

dilap wrote: post #32
nkozyra wrote: post #5

The error handling one is an area I've never understood - in a well-designed Go app errors will be returned from functions/methods and you'll either deal with them or not _/err. I love try/catch/finally but I fail to see how doing either a _ or writing a simple log function to do something with returned errors necessarily represents "more code" than handling exceptions.

People complain about the error handling of Go a lot, but I've recently switched from writing Python to Go, and so far, I am really enjoying the change to more explicit error handling. The thing is, if you're playing fast and loose, exceptions are great; there's no extra work, and it blows up if something goes wrong, so you find out -- great! But if you're trying to do the best possible thing in every scenario, it be…

"In Python land, it's quite possible you wouldn't even realize that an exception could be thrown there."

In the context of server code, that's really the fatal problem. And in general, "scream and die" isn't necessarily the optimal case either; not everything is a consumer web app where showing an error page is perfectly fine (I mean, not good, but generally fine). Knowing what can throw an error where is really useful.

I don't consider the error question settled yet. I think the failure of checked exceptions is instructive, because they clearly demonstrated that there's this "unioning" effect where a bit of code's error throwing capabilities is the union of all code it may call (in the absence of a programmer carefully restricting it), and seemingly minor bits of code may in fact result in "union"ing in a whole whackload of other errors. I'm not convinced anything has fully managed to address this yet. Unchecked exceptions tend to just cover over the problem, but don't help you deal with it much. A closed sum type for errors is great when you can use it, but it composes poorly if you start trying to move that around the system, and in practice Haskell still has exceptions. Using arbitrary or nearly-arbitrary terms for errors like Go (error is an interface) and Erlang do means you can pass errors back up the stack easily without the type system complaining and it's not a "hidden goto", but it means there's no way to be really sure that you've actually handled all possible errors in the best way. There's still no way to point at a block of code and assert that you know all the errors it can generate.

I think part of my willingness to accept how Go does errors is that I lack the belief that it's a solved problem and "duh, just use $SOLUTION". There's only some solutions that do a good enough job of sweeping the issue under the rug that they've convinced you it's solved, but the issues are still waiting to pop out as soon as someone stomps their boot down in the right place. It still seems like there's more work to be done here.

Re: Things from Python I'd miss in Go

#58

Post by mercurial »

gbog wrote: post #13

When I read go specs or go vs python comparison, nearly every diff is a specific pain point of our big python code base. No keyword argument? to hell with them. Strict formatting? That should be in python interpreter. No unused import: would have saved our lives. No cyclic dependencies? No inheritance? No exceptions? Great, all of them are maintenance nightmares.

What's your issue with keyword arguments, apart from magic args/*kwargs? They're quite convenient. As for exceptions, the problem with Python is more that the exceptions are unchecked than exceptions in general.

Re: Things from Python I'd miss in Go

#59

Post by markrages »

fulafel wrote: post #34
adwn wrote: post #20

It's ironic that the author dismisses C++ to a small niche: > Those who still stick to C++, after all these years, either really can't live with the "overheads" (real time apps - those are waiting for Rust to mature), or think they can't (and nothing will convince them except a competitor eventually forcing their employer out of business). Yet later he gives a good example for an important area where C++ is still unb…

Zero-cost abstractions come at a pretty hefty price if you pick C++. The cost is in programmer productivity & quality of resulting software. I'm sure there are some fields of academia where this is a reasonable tradeoff (if you're programming DSP algorithms running on a embedded battery powered device strapped to a dolphin, say...) but your generic number crunching job rarely calls for it. (As an aside, zero-overhead…

For embedded DSP, the preferred language is C (no ++). The extra complexity the ++ adds is of little or no value in small embedded systems.

Re: Things from Python I'd miss in Go

#60

Post by _yosefk »

jamra wrote: post #29
jgrahamc wrote: post #3

Towards the end of the article there seems to be a confusion between servers and web servers. Yes, Go is nice for writing servers, no, web servers aren't the only things out there doing 'serving' in systems-land. Three examples from CloudFlare all written in Go: 1. Our Internet compression/optimization technology called Railgun 2. Our DNS server 3. Our CA infrastructure All are networked, all are highly concurrent. A…

It looks like the author found the worst use case for Go in comparison to a library that Python absolutely soars in and uses that as a basis for this argument. Go does not have something as nice as numpy. For numeric computing, by all means use Python. He then makes some crazy statements about operator overloading as if that is the essence of a good language. I disagree. I don't want operator overloading. I almost ne…

Erm... so:

* I didn't "find" my use cases - they found me. All are real things I do with Python.

* I'd switch to something faster than Python, and finding more errors statically, if it wasn't for the bunch of things I'd miss.

* I like C better than C++ though the former lacks operator overloading; it's not "the essence of a good language", just one thing I use in Python.

* Further evidence that "I'm not here to bitch about Go for the sake of it": I didn't mention generics or similar, for instance - because they don't matter in the cases where I use Python, at least I don't recall that they do. I'm not looking for things to complain about.

* Deployment, etc. - it probably won't make someone switch to Go though it might be nice if you start in Go, and also - it's an argument in itself. I like how in Python you can change a file and all code using it "sees" the change, or how in languages with dynamic libraries/runtimes/whatever you change the library and all code "sees" it. Basically there are deployment trade-offs and in my environment - a controlled LAN - Go is simply worse. On a DreamHost box with ancient everything it'd be a godsend.

Overall - I don't think "Python is better than Go", but the ones who "beat their chest about how your language is a superior language because it is superior in a very specific niche" are people arguing about Go the way you do :-) That niche in Go's case being servers.

Speaking of servers... I know the difference between servers and web servers, I just said/implied that if Go is great for web apps, then it might take off as a really big thing, if it's just for high-performance infrastructure it's a language for Google, CloudFlare and a small number of others...

Post reply on HN