8 ms·

They both approximately match up on mental effort /friction/hassle for me, which largely seems to be coincidence since they do have dissimilar feature sets. Fo

by jlgreco 13y ago

They both approximately match up on mental effort /friction/hassle for me, which largely seems to be coincidence since they do have dissimilar feature sets. For example, it use to be that I would use Python when I thought that C (my language of choice) was going to be too much of a hassle; now I use Go when I think that C will be too much hassle. I think this accounts for a large portion of the Go<->Python talk you see.

SiVal 13y ago
When app(lication)s meant desktop apps, most of us used C as an app dev language. Over the years, the platform changed and most app developers switched to Java and C# and, more recently, to Python and Ruby. Those who still use C these days mostly use it to deal with unusually demanding constraints (performance, memory, etc.) They use C when only C will do, which usually is not for apps. C is not the default app programming language; it's a special-purpose language of sorts. Go is not very competitive with C at what people mostly use C for these days: tightest constraints and maximum customization. Go is very competitive with Python (& Ruby), though, as a high-productivity app development language, being almost as productive as those two but with much higher performance, lower memory requirements, and no need to install a big runtime. It's biggest shortcoming, vis-a-vis Py & Ruby, is the immaturity of its environment (libraries, toolchains, web frameworks, etc) due to its relative newness. As that changes, many will switch from P&R to Go, but fewer will switch from C to Go, because most who don't absolutely need C have already switched away from it.
- jlgreco 13y ago
  I fear I was unclear; I was not advocating using Go in the place of C. Rather I now using Go in the place of Python, in situations where C was not appropriate (traditionally my hobby projects have been something C is appropriate for, or something that Python is appropriate for).
  - SiVal 13y ago
    No, you were clear, and I seem to be thinking the same way your are. Mine was a more general comment on the common observation that Go is pulling more people away from Python than away from C. App developers who don't need the bit-by-bit customization power of C have already left it for more productive languages such as Python. Those who continue to use C are those who really need the bit-by-bit customization that C provides but Go and Python don't. Those who already left C for the huge productivity boost offered by Python can get back a lot of the performance and size advantages they left behind without giving up much of the productivity by switching to Go. That's an attractive option.
- pjmlp 13y ago
  What I always find interesting is that the Python and Ruby developers are willing to loose abstraction power to delve down in Go, while they would be able to keep it if they would move to PyPy, JVM/.NET based languages or FP languages with native compilers instead.
  - coldtea 13y ago
    Yes, but in return they get something more mature than PyPy, something with less hassle that bringing along a VM (JVM/.NET), and something less alien and marginal than FP languages with native compilers. They might not get the best technical experience, but they DO get: 1) mostly imperative (and most LIKE it that way), 2) nice concurrency support, 3) a lot of niceties (first class functions, implicit interfaces, maps, etc), 4) quite full batteries included, 5) lots of other kids using it 6) regular success posts on HN 7) nice, and mostly predictable, reasoning about speed and memory
    - pjmlp 13y ago
      > Yes, but in return they get something more mature than PyPy, something with less hassle that bringing along a VM (JVM/.NET), and something less alien and marginal than FP languages with native compilers. There are commercial native compilers for Java and .NET if you are willing to pay for them. Language != Implementation As for what one gets, 1) Offered by C++, JVM, .NET languages, D, Rust, ... 2) Scala, Haskell, OCaml, F#, D, Rust, Erlang, .... 3) Almost any modern language with exception of C and Java. 4) Java and .NET have more batteries 5) Yes, because big boys have better tools 6) Fortune 500 companies don't use languages based on HN posts 7) Tooling still behind what big boys use for other languages
      - MetaCosm 13y ago
        You kinda made his point for him didn't you? He said all these are benefits of Go, and you pointed out he would need to use lots of different languages to get them elsewhere. Notice the lack of overlap in your own points(1-4), that right there is the crux of the issue. Beyond that, on (5) I simply respond... what? I think you are flat out wrong about (6) and how they pick languages (I contract for them), they "hear" node.js is super fast and will double output and want to use it. (7) is part of what Go was designed to enable, building tools for it is AWESOME (Go AST!). If anything you made a killer post, maybe just not for the reasons you think.
deleted 13y ago
[deleted]
fauigerzigerk 13y ago
Keyword arguments with default values is the one Python feature that makes my Go code more verbose than my Python code. def f(a=11, b="some default", c=55.5, d=D()): #... f(c=44.4) becomes type Config struct { a int b string c float d interface{} } func f(c *Config) { a := 11 if c.a != 0 { a = c.a } b := "some default" if c.b != "" { b := c.b } c : = 55.5 if c.c != 0.0 { c := c.c } d := new(D) if c.d != nil { d := c.d } //... } func main() { f(&Config{c: 44.4}) }
- nknighthb 13y ago
  I just solved a similar problem in a slower but fairly general way. It's not appropriate everywhere, but it works well for the use-case I built it for. I can't share the actual code, unfortunately, but by using struct field tags, reflect, and json, you can end up with code that looks something like this: type FArgs struct { A int `def:"11"` B string `def:"\"some default\""` } func f(margs map[string]interface{}) { var args FArgs SetupArgs(margs, &args) // ... } If f() is being called in a tight loop, your overhead can be enormous, but outside performance-critical code, it's probably good enough.
  - fauigerzigerk 13y ago
    You're not just losing performance but also static type checking.
    - nknighthb 13y ago
      Not really. If the passed-in or default value doesn't convert to the field's type, SetupArgs panics. Edit: Variations on this that offer compile-time type checking of passed-in values are possible, too. My use case wouldn't work well with that, though, because the function needs to be called by other functions that would have no clue about the FArgs struct. You could instead do a version that just swaps in a default for any nil fields. And in any case, you've got a lot more safety than the original Python code, no?

by jlgreco 13y ago

SiVal 13y ago

When app(lication)s meant desktop apps, most of us used C as an app dev language. Over the years, the platform changed and most app developers switched to Java and C# and, more recently, to Python and Ruby. Those who still use C these days mostly use it to deal with unusually demanding constraints (performance, memory, etc.) They use C when only C will do, which usually is not for apps. C is not the default app programming language; it's a special-purpose language of sorts. Go is not very competitive with C at what people mostly use C for these days: tightest constraints and maximum customization. Go is very competitive with Python (& Ruby), though, as a high-productivity app development language, being almost as productive as those two but with much higher performance, lower memory requirements, and no need to install a big runtime. It's biggest shortcoming, vis-a-vis Py & Ruby, is the immaturity of its environment (libraries, toolchains, web frameworks, etc) due to its relative newness. As that changes, many will switch from P&R to Go, but fewer will switch from C to Go, because most who don't absolutely need C have already switched away from it.

jlgreco 13y ago
I fear I was unclear; I was not advocating using Go in the place of C. Rather I now using Go in the place of Python, in situations where C was not appropriate (traditionally my hobby projects have been something C is appropriate for, or something that Python is appropriate for).
- SiVal 13y ago
  No, you were clear, and I seem to be thinking the same way your are. Mine was a more general comment on the common observation that Go is pulling more people away from Python than away from C. App developers who don't need the bit-by-bit customization power of C have already left it for more productive languages such as Python. Those who continue to use C are those who really need the bit-by-bit customization that C provides but Go and Python don't. Those who already left C for the huge productivity boost offered by Python can get back a lot of the performance and size advantages they left behind without giving up much of the productivity by switching to Go. That's an attractive option.
pjmlp 13y ago
What I always find interesting is that the Python and Ruby developers are willing to loose abstraction power to delve down in Go, while they would be able to keep it if they would move to PyPy, JVM/.NET based languages or FP languages with native compilers instead.
- coldtea 13y ago
  Yes, but in return they get something more mature than PyPy, something with less hassle that bringing along a VM (JVM/.NET), and something less alien and marginal than FP languages with native compilers. They might not get the best technical experience, but they DO get: 1) mostly imperative (and most LIKE it that way), 2) nice concurrency support, 3) a lot of niceties (first class functions, implicit interfaces, maps, etc), 4) quite full batteries included, 5) lots of other kids using it 6) regular success posts on HN 7) nice, and mostly predictable, reasoning about speed and memory
  - pjmlp 13y ago
    > Yes, but in return they get something more mature than PyPy, something with less hassle that bringing along a VM (JVM/.NET), and something less alien and marginal than FP languages with native compilers. There are commercial native compilers for Java and .NET if you are willing to pay for them. Language != Implementation As for what one gets, 1) Offered by C++, JVM, .NET languages, D, Rust, ... 2) Scala, Haskell, OCaml, F#, D, Rust, Erlang, .... 3) Almost any modern language with exception of C and Java. 4) Java and .NET have more batteries 5) Yes, because big boys have better tools 6) Fortune 500 companies don't use languages based on HN posts 7) Tooling still behind what big boys use for other languages
    - MetaCosm 13y ago
      You kinda made his point for him didn't you? He said all these are benefits of Go, and you pointed out he would need to use lots of different languages to get them elsewhere. Notice the lack of overlap in your own points(1-4), that right there is the crux of the issue. Beyond that, on (5) I simply respond... what? I think you are flat out wrong about (6) and how they pick languages (I contract for them), they "hear" node.js is super fast and will double output and want to use it. (7) is part of what Go was designed to enable, building tools for it is AWESOME (Go AST!). If anything you made a killer post, maybe just not for the reasons you think.

deleted 13y ago

[deleted]

fauigerzigerk 13y ago

Keyword arguments with default values is the one Python feature that makes my Go code more verbose than my Python code. def f(a=11, b="some default", c=55.5, d=D()): #... f(c=44.4) becomes type Config struct { a int b string c float d interface{} } func f(c *Config) { a := 11 if c.a != 0 { a = c.a } b := "some default" if c.b != "" { b := c.b } c : = 55.5 if c.c != 0.0 { c := c.c } d := new(D) if c.d != nil { d := c.d } //... } func main() { f(&Config{c: 44.4}) }

nknighthb 13y ago
I just solved a similar problem in a slower but fairly general way. It's not appropriate everywhere, but it works well for the use-case I built it for. I can't share the actual code, unfortunately, but by using struct field tags, reflect, and json, you can end up with code that looks something like this: type FArgs struct { A int `def:"11"` B string `def:"\"some default\""` } func f(margs map[string]interface{}) { var args FArgs SetupArgs(margs, &args) // ... } If f() is being called in a tight loop, your overhead can be enormous, but outside performance-critical code, it's probably good enough.
- fauigerzigerk 13y ago
  You're not just losing performance but also static type checking.
  - nknighthb 13y ago
    Not really. If the passed-in or default value doesn't convert to the field's type, SetupArgs panics. Edit: Variations on this that offer compile-time type checking of passed-in values are possible, too. My use case wouldn't work well with that, though, because the function needs to be called by other functions that would have no clue about the FArgs struct. You could instead do a version that just swaps in a default for any nil fields. And in any case, you've got a lot more safety than the original Python code, no?