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

Why I’m not leaving Python for Go

uberpython.wordpress.com

Post reply on HN
Print view View original

221–230 of 245 posts

Re: Why I’m not leaving Python for Go

#221

Post by barrkel »

ryanmolden wrote: post #211
barrkel wrote: post #158

Earlier quoted context omitted.

In my experience of web server apps, it's been fairly easy to guarantee that either the whole request succeeds, or - if there was an exception - every change is rolled back. Both user state and database state has been transactional, and state that lived on in memory in between requests was either read-only or caches. In UI apps, it's much much harder to guarantee transactional semantics unless you're using persistent…

>If you don't yet understand why GC increases productivity, it's an epiphany you'll need to look forward to. Oh I fully understand/agree with that, I just don't find C++ memory management to be too hard. The concurrency concerns pointed out by others are true, though. Whether they (the concerns) are offset by the lack of deterministic destruction and the extreme triviality of creating reference chains that root thing…

The domain of programs for which C++ memory management is not hard has only a partial intersection with programs that are small, expressive and easy to understand.

That is, if you take C++'s techniques for memory management for granted, simpler approaches to problems won't even occur to you.

Re: Why I’m not leaving Python for Go

#222

Post by Evbn »

papsosouid wrote: post #217
_ak wrote: post #213

Earlier quoted context omitted.

> If you forgot to check the error code in go, then you will end up using that non-float float that shouldn't exist as if it were really a float. Consider the following code: foo, err := strconv.ParseFloat(...) If you don't handle the error (e.g. by forgetting), the compiler will show an error because you declared err, but didn't use it. If you write foo, _ := strconv.ParseFloat(...) instead, you deliberately choose…

>If you don't handle the error (e.g. by forgetting), the compiler will show an error because you declared err, but didn't use it. But if I make a mistake like I mentioned previously, I could very well use err, thus not getting a compiler warning, and still also use foo, which is a whoknowswhat. It should be an Either, not two seperate return values. >Making these specifics a criteria for decency is nothing but arroga…

And in Haskell you could make the mistake of ignoring the error and writing

  Right x = leftOrRight y
And get a runtime crash when a Left shows up,

  Or
  Just x = justOrNone y
And crash on None.

Re: Why I’m not leaving Python for Go

#223

Post by Evbn »

flyinRyan wrote: post #168
cletus wrote: post #120

I have mixed feelings about errors as return codes. Then again, I have mixed feelings about exceptions. There are two general use cases for exceptions: 1. Unexpected (typically fatal) problems; 2. As an alternative to multiple return values. (1) is things like out of memory errors. (2) is things like you're trying to parse a user input into a number and it fails. I despise (2) for exceptions. It means writing code li…

>try: >> f = float(someText) >> catch ValueError: >> # I just parsed you, this is crazy, >> # here's an exception, throw it maybe? No, you have it exactly backwards. It's with return values that you have to check after every call to be safe. With exceptions you can truly say: if I don't know what to do if this fails then I don't do anything. You can let the exception bubble up higher, all the way up to crashing the p…

"Not checking" is just shorthand for pythons " except: pass".

Re: Why I’m not leaving Python for Go

#224

Post by Evbn »

morphyn wrote: post #191
flyinRyan wrote: post #166

Earlier quoted context omitted.

>Problem is that you then have to explain monads to average programmers who'll be using the language. No you don't, this is exactly what you don't need to do. Do we explain the finer points of stream implementation to would-be C++ programmers? No, when they need to do something non-standard with a stream/monad, that's the time to talk about them. For the majority of programmers it's just "when you need to write to a…

The Either type described in the first comment is also a Monad. They are more important in Haskell than just "when you need to write to a file..." and I don't think you can totally grasp the error handling method without understanding them.

I don't know what a thread is, but I can still use Executors in Java.

Re: Why I’m not leaving Python for Go

#225

Post by Evbn »

nostrademons wrote: post #134
theaeolist wrote: post #124

Earlier quoted context omitted.

This kind of comment kind of misses the point. The monadic style of threading error values is perfectly compatible with imperative programming if only language designers knew about it.

Problem is that you then have to explain monads to average programmers who'll be using the language. I love monads (I love arrows more, but that's another issue). I'm a language design geek. My level of expertise is different from someone who has just been hired into a new job and wants to get things done. I suspect that most language designers know about monads - I'm not sure Rob Pike did, but it's pretty common kno…

You can write Haskell programs entirely in IO, and the result looks and works almost exactly like Python, but type safe.

The dangerous part of Haskell, like Scala and C++, is that it also has super scary dark magical parts.

Re: Why I’m not leaving Python for Go

#226

Post by prodigal_erik »

Evbn wrote: post #223
flyinRyan wrote: post #168

Earlier quoted context omitted.

>try: >> f = float(someText) >> catch ValueError: >> # I just parsed you, this is crazy, >> # here's an exception, throw it maybe? No, you have it exactly backwards. It's with return values that you have to check after every call to be safe. With exceptions you can truly say: if I don't know what to do if this fails then I don't do anything. You can let the exception bubble up higher, all the way up to crashing the p…

"Not checking" is just shorthand for pythons " except: pass".

But not checking is invisible. I can't grep for it. It doesn't stand out in a code review. It's almost never what I meant to do, so it shouldn't have been the default or easily overlooked, much less both.

Re: Why I’m not leaving Python for Go

#227

Post by Evbn »

djhworld wrote: post #164
pestaa wrote: post #138

Earlier quoted context omitted.

That'd kind of defeat the whole point of linking a binary. Were you using cabal to build executables? What shared libs were missing on remote machines?

When I just do a simple hello world app, I get this error ghc helloworld.hs -o helloworld ./helloworld ./helloworld: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory However if I compile statically, I get a different error ghc helloworld.hs --make -optc-static -optl-static -optl-pthread -static -o helloworld ./helloworld FATAL: kernel too old Segmentation f…

How old is your kernel, anyway?

Re: Why I’m not leaving Python for Go

#228

Post by Evbn »

_ak wrote: post #181
tikhonj wrote: post #80

As usual in these threads about Go, I really wish people would consider Haskell as a nice alternative. A lot of people write Haskell off as "academic" or "impractical", which I feel is not an entirely fair assessment. Particularly: Haskell is fast, concurrent by design (whatever that means, I'm sure Haskell is :P), typed but not cumbersome or ugly (less cumbersome and ugly than Go's types, even) and--most importantly…

> As usual in these threads about Go, I really wish people would consider Haskell as a nice alternative. A lot of people write Haskell off as "academic" or "impractical", which I feel is not an entirely fair assessment. As someone with 10+ years of programming experience in the industry but no formal college education, I see the problem with Haskell (and other, similar functional programming languages) that in order…

And Java programs with Guide and AOP and magical JUnit are hard to understand. You can either not use the weird stuff, or you can learn it.

Re: Why I’m not leaving Python for Go

#229

Post by Evbn »

emillon wrote: post #135
sausagefeet wrote: post #128

Earlier quoted context omitted.

I'm not sure how, C doesn't have multiple return values either. I also don't really understand the second part. How is that any worse than the current situation of not checking the error side and reading an undefined (or whatever it is?) value?

Well, the choice is between structures or tagged unions. I'm not a Go user, but if I understand correctly ("It's like an Either that always has Left and Right."), functions return a structure with both an error code and a value. To wrap a C function into a Go function with this signature, you can initialize a structure with { code: success; value:f() }; and then of course error checking has to be done C-style (errno,…

By "unsafe tagged unions" you mean "untagged unions" (or ad hoc runtime-tagged unions)?

Re: Why I’m not leaving Python for Go

#230

Post by sp332 »

rachelbythebay wrote: post #52

Rejecting something because it's "from the 1970s" seems like a particularly weak way to roll. Automatically equating "old" with "broken" is just as lazy as automatically equating "new" with "pointless". The world is far more nuanced than that.

"Old" as in, the last time this seemed like a good idea was the 70's.
Post reply on HN