6 ms·

These ports from Python and Ruby (like Martini, for another example) are well-intentioned, but I don't think they're a good idea to use. The original libraries

These ports from Python and Ruby (like Martini, for another example) are well-intentioned, but I don't think they're a good idea to use. The original libraries get a lot of their expressive power from polymorphism - Requests gets a tremendous amount of mileage out of letting you pass in keyword arguments to the `get` method, for example. Go prefers that you be more explicit and use more function declarations, even if it means repetition in the library code. When developers try to get around this, you see awkward constructs like the pointer-to-a-config-struct used here.

evmar 11y ago
I immediately noticed this as well. This API has flags for "asynchronous" requests, but Go style is to provide a blocking API, and let the caller decide to use a goroutine if they need concurrency.
- XorNot 11y ago
  Constructing a channel (as it does though) is just pragmatic though and definitely not any less go-like. You get a channel - you can read from it until it's closed which is always safe. Go-routines are cheap so you don't care about the background details. For simplifying HTTP, this is great.
- levigross 11y ago
  Originally the API was completely asynchronous (every "request" function returned a channel). I got a lot of feedback that I shouldn't do that, so I moved the asynchronous requests to specific functions e.g GetAsync and made the standard API synchronous.
  - sagichmal 11y ago
    You should go further, removing the async methods altogether. In Go, making sync APIs async is trivial and well-understood.
coldtea 11y ago
I personally welcome those kind of ports and hate blind insistent on "idiomatic" code. Idiomatic Java, Perl and other languages were shit for a long time, they only improved when some brave soulds fed up with it and explorer non-idiomatic solutions (like the Play framework). And some things I see in "idiomatic" Go make my hair crawl...
- ORioN63 11y ago
  I'm going to disagree with you there. Idiomatic code is so called, because people familiar with the language can quickly read it. It makes reading code a much lighter task. Frameworks are a different thing. Frameworks build around its host language, but normally are meant to use in a specific way. In its own idiomatic way.
  - coldtea 11y ago
    >Idiomatic code is so called, because people familiar with the language can quickly read it. It makes reading code a much lighter task. In the case of Java circa 2000-2006 it needlessly messed up code, making it more difficult and slow to read EVEN for people familiar with the language. Following conventions doesn't make code better to read automatically just because people are already familiar with them -- those conventions should be good in the first place for that to happen. Node has the callback hell "idiom" many are familiar with. And yet if somebody rewrote the code with async, await, even the people "familiar" with callbacks would be able to read it faster and understand it better.
    - mattkrea 11y ago
      I don't think this is universal as it hasn't applied where I work. Without understanding how promises work they are no easier and it doesn't help that many things exists that do not use the standard .then() and .catch().
      - coldtea 11y ago
        Async/await is not the same as bare promises though with then() and catch.
dvirsky 11y ago
The first project I published in Go almost 3 years ago, was a similar port of the python logger. While today I find this "I want to log like I do in python" approach a bit silly, IMO the Go standard logging package is still lacking, and I'm still using my python-ish port, not because it's similar to python, but because it has things like formatting, context printing and most importantly logging levels.
- levigross 11y ago
  I am not trying to do things in the "Python way". I am trying to bring some of the same flexibility I get when using the Python requests library to Go.
- cat9 11y ago
  What's your take on Logrus? It seems like it would cover your major concerns, and it's widely recommended. https://github.com/Sirupsen/logrus https://github.com/Sirupsen/logrus
  - dvirsky 11y ago
    it's nice, very similar to my API sans the structured messages thing.
tenken 11y ago
There's nothing wrong with porting something to another language so your project Stack is all in 1 language. Nuts to having a million languages and cryptic dependencies. More singular platforms are easier to maintain for sysadmins and developers alike. If the porting language isn't as expressive as the original source -- oh well thats a price i'm willing to pay.

evmar 11y ago

I immediately noticed this as well. This API has flags for "asynchronous" requests, but Go style is to provide a blocking API, and let the caller decide to use a goroutine if they need concurrency.

XorNot 11y ago
Constructing a channel (as it does though) is just pragmatic though and definitely not any less go-like. You get a channel - you can read from it until it's closed which is always safe. Go-routines are cheap so you don't care about the background details. For simplifying HTTP, this is great.
levigross 11y ago
Originally the API was completely asynchronous (every "request" function returned a channel). I got a lot of feedback that I shouldn't do that, so I moved the asynchronous requests to specific functions e.g GetAsync and made the standard API synchronous.
- sagichmal 11y ago
  You should go further, removing the async methods altogether. In Go, making sync APIs async is trivial and well-understood.

coldtea 11y ago

I personally welcome those kind of ports and hate blind insistent on "idiomatic" code. Idiomatic Java, Perl and other languages were shit for a long time, they only improved when some brave soulds fed up with it and explorer non-idiomatic solutions (like the Play framework). And some things I see in "idiomatic" Go make my hair crawl...

ORioN63 11y ago
I'm going to disagree with you there. Idiomatic code is so called, because people familiar with the language can quickly read it. It makes reading code a much lighter task. Frameworks are a different thing. Frameworks build around its host language, but normally are meant to use in a specific way. In its own idiomatic way.
- coldtea 11y ago
  >Idiomatic code is so called, because people familiar with the language can quickly read it. It makes reading code a much lighter task. In the case of Java circa 2000-2006 it needlessly messed up code, making it more difficult and slow to read EVEN for people familiar with the language. Following conventions doesn't make code better to read automatically just because people are already familiar with them -- those conventions should be good in the first place for that to happen. Node has the callback hell "idiom" many are familiar with. And yet if somebody rewrote the code with async, await, even the people "familiar" with callbacks would be able to read it faster and understand it better.
  - mattkrea 11y ago
    I don't think this is universal as it hasn't applied where I work. Without understanding how promises work they are no easier and it doesn't help that many things exists that do not use the standard .then() and .catch().
    - coldtea 11y ago
      Async/await is not the same as bare promises though with then() and catch.

dvirsky 11y ago

The first project I published in Go almost 3 years ago, was a similar port of the python logger. While today I find this "I want to log like I do in python" approach a bit silly, IMO the Go standard logging package is still lacking, and I'm still using my python-ish port, not because it's similar to python, but because it has things like formatting, context printing and most importantly logging levels.

levigross 11y ago
I am not trying to do things in the "Python way". I am trying to bring some of the same flexibility I get when using the Python requests library to Go.
cat9 11y ago
What's your take on Logrus? It seems like it would cover your major concerns, and it's widely recommended. https://github.com/Sirupsen/logrus https://github.com/Sirupsen/logrus
- dvirsky 11y ago
  it's nice, very similar to my API sans the structured messages thing.

tenken 11y ago

There's nothing wrong with porting something to another language so your project Stack is all in 1 language. Nuts to having a million languages and cryptic dependencies. More singular platforms are easier to maintain for sysadmins and developers alike. If the porting language isn't as expressive as the original source -- oh well thats a price i'm willing to pay.