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

31–40 of 142 posts

Re: Things from Python I'd miss in Go

#31

Post by Rapzid »

yonaguska wrote: post #23
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.

Could you elaborate on why using the repl was a mistake? I don't really miss python's repl, but coming from the Lisp repl, the playground doesn't seem to cut it. Now, if anyone has written an emacs mode that lets you interact with the playground by loading a buffer- I think I'd be much happier.

The repl/insta-repl in LightTable was amazing to me. Particularly what you could do with clojure-script when it was hooked up to the browser.

Re: Things from Python I'd miss in Go

#32

Post by dilap »

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 becomes much harder.

(E.g. maybe for some reason a field in a record you're loading isn't valid UTF8. Let's say it's in the context of a larger request -- you still want the request as a whole to succeed; the non-valid UTF8 isn't a critical issue, just something you should log and fix later. In Python land, it's quite possible you wouldn't even realize that an exception could be thrown there. You leave your code by a totally unexpected exit. Users are seeing errors for no particularly-great reason. So: you fix things to handle this case properly, and you end up with ugly try:catch: indentation that's worse than just checking error return codes in the first...)

Re: Things from Python I'd miss in Go

#33

Post by Touche »

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?

Re: Things from Python I'd miss in Go

#34

Post by fulafel »

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 abstractions being unique to C++ doesn't sound right to me. Then again I haven't heard the term used outside C++ circles and its meaning is nebulous, so maybe it's just a name for C++'s tradeoffs?)

Re: Things from Python I'd miss in Go

#36

Post by pjc50 »

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…

Java is faster to build than C++ almost all of the time. Header files (especially with templates) tend to turn C++ in to an O(n^2) run time, often running into hours.

Re: Things from Python I'd miss in Go

#37

Post by sergiosgc »

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…

From what I understand, Go is an opinionated language, with a nice concurrency framework. It's not groundbreaking, it's not particularly expressive or adapted to any specific use case. It so happens that if your style fits Go's ideology (opinionated view), you become a fan.

For me, the lack of exceptions kills the language. C-like error testing smells like a twenty year de-evolution. I also dislike the flat object model, but could force myself to live with it for the sake of trying composition over inheritance. Error returning, however, is taking the ideology too far.

Re: Things from Python I'd miss in Go

#38

Post by klibertp »

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 don't understand why the OP wrote this article in the first place. It's obvious that Go is not designed to support his use-cases and that's really all there is to it. Listing reasons why Go is bad at doing things it wasn't meant to do seems a bit pointless to me. It's like bashing a screwdriver for how bad a hammer it makes...

Re: Things from Python I'd miss in Go

#39

Post by seanmcdirmid »

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…

You forgot to mention CUDA, which is trouncing Fortran, C, and C++ in performance and being adopted at a fast rate. Now, one could argue that CUDA is a dialect of C++, but it is much more than that.

Re: Things from Python I'd miss in Go

#40

Post by Goranek »

yonaguska wrote: post #23
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.

Could you elaborate on why using the repl was a mistake? I don't really miss python's repl, but coming from the Lisp repl, the playground doesn't seem to cut it. Now, if anyone has written an emacs mode that lets you interact with the playground by loading a buffer- I think I'd be much happier.

Instead of going through the docs and code i used dir function inside repl to figure out what to do, how something works and so on.
Post reply on HN