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

61–70 of 142 posts

Re: Things from Python I'd miss in Go

#61

Post by dragonwriter »

seanmcdirmid wrote: post #44
dilap wrote: post #32

Earlier quoted context omitted.

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…

Generic methods is one place where non-explicit error handling is essential. What if your map/select call fails? You have to make sure to thread error handling through everything that would ever take another function as an argument (since the error handling characteristics of the unknown function are open), which, in this day and age, is ridiculous. C# couldn't do LINQ at all in this case. Sometimes a bit of dynamic…

> Generic methods is one place where non-explicit error handling is essential.

And, really, the error-handling part fits fairly well with Go (not only what the language supports -- which is, after all, full-featured exceptions with a different [IMO, improved] syntax -- but also with the conventions on their use across public API, though that requires some thought about the motivation for that rule and how it applies to that kind of function.)

OTOH, Go's type system, as opposed to its error-handling approach, is a real problem for generic functions. Though if you just mean non-generic higher-level functions, this is less of an issue.

> You have to make sure to thread error handling through everything that would ever take another function as an argument (since the error handling characteristics of the unknown function are open)

No, you just have to state as an assumption of the "generic" that any function it works on is wrapped to panic in the event of error, and the caller needs to handle the panics. To fit with the Go convention on panics and public APIs, you should wrap any function that results from applying such a higher-level function to a function that an fail into another function that recovers from panics and provides error returns before passing the resulting function across a public API boundary.

Re: Things from Python I'd miss in Go

#62

Post by edgarbob »

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…

Hopefully Rust's approach to zero-overhead abstractions will alleviate a lot of the problems you run into in C++.

Re: Things from Python I'd miss in Go

#63

Post by [deleted] »

dragonwriter wrote: post #41

> No exceptions [...] If I want higher-level error context I need to propagate the error upwards, with an if at every function call along the way. This is flat out false. Go has fairly standard exceptions (panics), though instead of using try/catch/finally blocks it uses deferred functions that perform a hybrid of the "catch" (if they use "recover") and "finally" functionality. It is a go convention that library code…

[deleted]

Re: Things from Python I'd miss in Go

#64

Post by pekk »

atilaneves wrote: post #12

I've been waiting for someone to weigh in on this from the Python side for a while now. I'm a C++ and Python programmer (amongst other things) and I can't ever see myself switching to Go. I'd sooner switch to Rust or Swift, but D has been my favourite language by far since I picked it up last year. I actually don't understand why, in the absence of niche use-cases, how and why Python programmer would write Go code an…

Less than 100% of the reported switches from Python to Go actually started with serious knowledge of Python.

Re: Things from Python I'd miss in Go

#65

Post by S4M »

philbarr wrote: post #53
S4M wrote: post #46

Earlier quoted context omitted.

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

My comment only applies for Java - I don't know C#. As you say, it's usually a bad idea but it's quite reasonable to do for numerical analysis, as your sibling comment says.

Re: Things from Python I'd miss in Go

#66

Post by _yosefk »

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…

First of all - yes they're "just tools" and that's pretty much what I said - Go is for servers and it won't "rule them all", and I wouldn't write the obvious if it weren't for the massive Go hype.

Another angle though - a language comes at a massive cost of vocabulary (builtins and libraries) which dwarfs the cost of learning a new grammar (easy compared to natural languages though a cost in itself). A language suited for a narrow niche will still replicate a lot of libraries, tools etc. Whoever pays the costs, too many languages in one's toolbox, be it a person, a company or society as a whole, is not necessarily a net gain.

So if Java could have gotten goroutines without having to make a whole new language... would Go be a good idea? (I don't know the answer and maybe it's practically irrelevant but it's an interesting question I think.)

Re: Things from Python I'd miss in Go

#67

Post by pekk »

moreentropy wrote: post #17
drdaeman wrote: post #11

Earlier quoted context omitted.

That creates some mostly unnecessary boilerplate. I.e., if an error happens down the stack in function to read config, which calls a function to parse a file, which calls a function to read a file, you'll have to either propagate (or otherwise handle) that `err` manually or lose the precious information. On the contrary, Java-like pattern of functions like `Config readConfig() throws IOError, ParseError` simplifies c…

OTOH, if you follow Go's idioms and handle every error where it happens, your code will look like having a lot of boilerplate at first, but you end up with better error handling. It's the same as putting a try-except catchall around every single call in python, because in python you can never be sure (without reading the source) what kind of exceptions something will throw. For request based services and something wh…

You shouldn't be putting a try-except catchall around every single call in Python. Exceptions mean you don't have to do that.

Re: Things from Python I'd miss in Go

#68

Post by _yosefk »

rakoo wrote: post #42

I think the author misses the point. The number one reason Go was created was to build maintainable softwares , the kind Google uses at large. The easiest way to build these are: - Automatic memory management -> GC - Bug catching before the software is run -> Static typing - Overall simplicity -> few features, added only if it is extremely needed The thing is, when you start using Go, you already know its features. T…

Why do I miss the point if, like me, you think Go is the new Java? :-)

I think it's exactly that, it works and that's fine, and why the JVM doesn't do cheap concurrency I don't know. If it did Java might have been the new Java :-)

Re: Things from Python I'd miss in Go

#69

Post by dragonwriter »

[deleted] wrote: post #63
dragonwriter wrote: post #41

> No exceptions [...] If I want higher-level error context I need to propagate the error upwards, with an if at every function call along the way. This is flat out false. Go has fairly standard exceptions (panics), though instead of using try/catch/finally blocks it uses deferred functions that perform a hybrid of the "catch" (if they use "recover") and "finally" functionality. It is a go convention that library code…

[deleted]

I'm not objecting to you choosing not learn something in depth because you don't like how it looks on the surface (that's a rational approach to avoiding wasting time, which is a valuable resource), I'm objecting to you, in the linked article, commenting in depth (and inaccurately) on something its clear that you decided not to learn in depth because you didn't like how it looks on the surface.

The statement that Go has "no exceptions", or that for deep error handling in your own code you have to handle errors at each level is false. And, fine, you didn't learn anything about it because maybe you saw sample code showing how you need to deal with the public API of common libraries because of the Go convention that panics aren't exposed across public APIs. And if all you said was that, it'd be fine -- but you went beyond that and said things that weren't true and which people who haven't learned the language might not realize were statements from ignorance rather than experience, and might turn them off of the language where they wouldn't be turned off if they knew the truth, because if they were true, they'd be real and deep problems with the language design.

Choosing to remain ignorant about Go because it doesn't seem like its worth your time to learn is fine. Making up stories about why you don't like Go that aren't grounded in anything real is not.

TL;DR: if you choose to be ignorant, you don't get to pretend to be an authority.

Re: Things from Python I'd miss in Go

#70

Post by onalark »

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…

If you want/need maximum performance, why are you programming in a "high-level language"?

Many of the highest-performance scientific computing libraries are written in assembly or use inline assembly instructions. The vast majority of scientific programmers don't need to write at this level. I challenge you to write a native C++ matrix-matrix-multiply algorithm that generally outperforms the matrix-matrix-multiply available to MATLAB, Python/Cython, and Julia through their interface to the assembly-optimized OpenBLAS library: http://julialang.org/

Note that C, Fortran, and Julia are all using OpenBLAS in the rand_mat_mul benchmark, and OpenBLAS is written in C (with assembly).

Post reply on HN