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

Why I went from Python to Go (and not node.js)

orel.li

Post reply on HN
Print view View original

101–110 of 202 posts

Re: Why I went from Python to Go (and not node.js)

#101

Post by jimbokun »

batista wrote: post #93
dons wrote: post #27

Earlier quoted context omitted.

You're digging in. > Haskell I would argue against being an industry language FYI, the problems the Haskell community has been working on are things like scalability, performance and safety because they're critical to industrial problems . Toy approaches don't work at the scale we operate at -- you need real computer science. You want 1,000,000 Haskell threads in your app? You've got it. Want to write numerical model…

> /me wanders back to a multi-million line Haskell codebase running systems in 25 countries, processing billions a year in financial transactions. Hope the codebase runs well, because that's the bank I use in Singapore ;-) Has you/anyone written something about how Haskell got picked for the task by that particular bank? Is the language used at other financial type businesses? I've heard some firms use Ocaml.

"I've heard some firms use Ocaml."

Jane Street.

Would be fun to see a panel with dons and Yaron Minsky discussing the pros and cons of Haskell and Ocaml, respectively.

Re: Why I went from Python to Go (and not node.js)

#102

Post by jimbokun »

batista wrote: post #92
swasheck wrote: post #66

Earlier quoted context omitted.

Honestly, I find Go more difficult than Haskell

After you've learned both, maybe. But that is beside the point. Haskell is more difficult to learn.

Probably not if that's what you start with. Carnegie Mellon now starts all CS students with ML, I believe.

For those of us who learned to program in an imperative language first, the difficulty with learning functional programming is unlearning all of our bad habits.

Re: Why I went from Python to Go (and not node.js)

#103

Post by jimbokun »

IsTom wrote: post #91
zemo wrote: post #24

Earlier quoted context omitted.

ah, so, I don't think I wrote that section particularly well. I hold Erlang and Haskell in very high regard; I was really trying to mock my own superiority complex, which I think is fairly common in the Python community. I guess what I was really trying to get at is that Go is verymuch an industry language. Haskell I would argue against being an industry language not because it can't be used in industry; that's not a…

Erlang is intimidating? How? It's a braindead simple language.

It doesn't look like C!!!

Re: Why I went from Python to Go (and not node.js)

#104

Post by jimbokun »

niels_olson wrote: post #74

I keep hearing about go. I am new-ish to programming. Only really getting started on my first project, which depends on pyparsing, which depends on other things. Is go something a novice should be attacking real-world problems with?

I'm not a Go developer, but if you start having performance problems in Python, that might be a good time to consider Go.

Re: Why I went from Python to Go (and not node.js)

#105

Post by pcwalton »

scott_s wrote: post #83
outworlder wrote: post #11

Earlier quoted context omitted.

> but this is part of the problem: it's a library. Concurrency deserves language-level support. Adding concurrency at the library level is like adding an object system at the library level. Which is not a problem at all. Lisp and Scheme have been doing that since forever.

I assume they depend on macros to do so? That changes the game. Hans Boehm has an excellent paper on this issue titled "Threads Cannot be Imlemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf That paper was published in PLDI ( http://dl.acm.org/citation.cfm?id=1065042 ). His arguments have much to do with what the compiler doesn't know, which could potentially be solved with macros.

You don't need macros to solve this problem. You can use unique types, STM, etc. to forbid the data sharing at the type level and ensure a coherent memory model.

Re: Why I went from Python to Go (and not node.js)

#107

Post by Ideka »

jonathansizz wrote: post #99
IsTom wrote: post #90

Earlier quoted context omitted.

"Everyone less nerdy than me is stupid and everyone more nerdy than my is a no-life". I think it's pathetic, not funny.

It's actually kind of bizarre that so many Pythonistas actually have the kind of attitude that the article mocks, since Python is a thoroughly mediocre language. I can only attribute their patronizing disposition to a lack of genuine awareness of the broader programming world.

since Python is a thoroughly mediocre language.

Care to elaborate?

Re: Why I went from Python to Go (and not node.js)

#108

Post by jeremyjh »

erichocean wrote: post #62
zemo wrote: post #36

Earlier quoted context omitted.

well, the complaint isn't entirely that it's hard, per se, but that there are many different ways to do things concurrently in Python, and that it presents too many choices to be made for the novice programmer. In Go, you just say `go myfunction()` and you're done. There's a lot of value in that.

Until, that is, you tackle a problem for which one machine isn't big enough, at which time you need to do all of the "real" solutions anyway, and `go myfunction()` buys you...nothing. There's way too much focus today on new languages that are designed to work on just one machine, and scale there – as if vertical scaling was the true problem we all face, when in fact, it's not. /sigh

He's talking about a web application doing a task asynchronously. There is no reason why it would be hard to scale Go web servers across multiple machines. Yes you could use a distributed broker system to do asynchronous tasks, and some languages platforms leave you no other choice, but there is no reason to think his use case actually requires anything more than running an asynchronous task.

Re: Why I went from Python to Go (and not node.js)

#109

Post by scott_s »

pcwalton wrote: post #105
scott_s wrote: post #83

Earlier quoted context omitted.

I assume they depend on macros to do so? That changes the game. Hans Boehm has an excellent paper on this issue titled "Threads Cannot be Imlemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf That paper was published in PLDI ( http://dl.acm.org/citation.cfm?id=1065042 ). His arguments have much to do with what the compiler doesn't know, which could potentially be solved with macros.

You don't need macros to solve this problem. You can use unique types, STM, etc. to forbid the data sharing at the type level and ensure a coherent memory model.

The paper's position is that you can't implement threads, safely, as a library because the compiler is not aware of the concurrency. My point was that this reasoning may not hold if your language has full macros. Your suggestions will work great, but those are in the compiler, not as a library.
Post reply on HN