3 ms·

Flask is better in the little mechanics of interacting with HTTP - parsing a parameter out of a URL (in Flask, it's a function argument; in Go, it's at least on

Flask is better in the little mechanics of interacting with HTTP - parsing a parameter out of a URL (in Flask, it's a function argument; in Go, it's at least one extra line per arg), returning JSON (just return a dictionary in Flask), handling errors. Flask also is able to auto-reload the code when it changes (turn on development mode) which is really convenient. Plus all the ways that Python is more convenient than Go.

andreygrehov 6y ago
But...you are comparing a web framework with a Go's standard library. I mean, it's not a fair comparison. I'm pretty sure there are Go modules that support those handy things.
- dnautics 6y ago
  doesn't go stdlib contain an http server library "that you are supposed to use in prod"?
  - andreygrehov 6y ago
    It does. It's rock solid and most people use it in production. But the parent is more concerned about quick and handy functions. IMHO, such functionality is usually part of third-party libraries and is certainly an option in Go. It's just idiomatic Go favors KISS principles, less external dependancies and a more self-contained software. The benefit is that pretty much all the Go source code is more-or-less identical, regardless of an author. It makes it super simple to understand and deep dive into a random complex piece of software. Go is not about abstractions, Go is about solving problems here and now.
- barumi 6y ago
  > But...you are comparing a web framework with a Go's standard library. I mean, it's not a fair comparison. Why do you feel that the comparison isn't fair? Aren't we talking about modules that provide the features necessary to implement a type of application? Would it make any difference if tomorrow there was a PEP making Flask a standard component? Unless you are aware of any Go module that addresses the downsides of Go with regards to Python, your observation is mute and unhelpful.
- curryst 6y ago
  There are, but Go's type system doesn't really accommodate them very well. `interface{}` tends to abound, and it tends to feel less magical because you're still generally wiring things up yourself (i.e. you still have to explicitly unmarshal the request JSON). In some ways, that explicitness is better because you know what's happening. In other ways, I'm incredibly tired of typing out 'if err := req.Bind(myStruct); err != nil { return err }'.

andreygrehov 6y ago

But...you are comparing a web framework with a Go's standard library. I mean, it's not a fair comparison. I'm pretty sure there are Go modules that support those handy things.

dnautics 6y ago
doesn't go stdlib contain an http server library "that you are supposed to use in prod"?
- andreygrehov 6y ago
  It does. It's rock solid and most people use it in production. But the parent is more concerned about quick and handy functions. IMHO, such functionality is usually part of third-party libraries and is certainly an option in Go. It's just idiomatic Go favors KISS principles, less external dependancies and a more self-contained software. The benefit is that pretty much all the Go source code is more-or-less identical, regardless of an author. It makes it super simple to understand and deep dive into a random complex piece of software. Go is not about abstractions, Go is about solving problems here and now.
barumi 6y ago
> But...you are comparing a web framework with a Go's standard library. I mean, it's not a fair comparison. Why do you feel that the comparison isn't fair? Aren't we talking about modules that provide the features necessary to implement a type of application? Would it make any difference if tomorrow there was a PEP making Flask a standard component? Unless you are aware of any Go module that addresses the downsides of Go with regards to Python, your observation is mute and unhelpful.
curryst 6y ago
There are, but Go's type system doesn't really accommodate them very well. `interface{}` tends to abound, and it tends to feel less magical because you're still generally wiring things up yourself (i.e. you still have to explicitly unmarshal the request JSON). In some ways, that explicitness is better because you know what's happening. In other ways, I'm incredibly tired of typing out 'if err := req.Bind(myStruct); err != nil { return err }'.