I think this accounts for a large portion of the Go<->Python talk you see.
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.
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).
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
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
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.
Not really, I just found out it was easier to reply to his bullet points like that using languages that are known for certain features.
Actually most of those languages cover all Go features.
Anyone with background in compiler design can easily provide a paper like article that picks up every single feature and describes which languages offered them initially and their evolution across programming languages.
However something like that would only contribute for flame war discussions without any productive result.
I also work for Fortune 500 companies with multi-site offshoring projects, so I do have some experience on that world.
I was attracted to Go, because it is a Google language, but I got disappointed with its features, after using the language during 2010-11 timeframe.
It remains to be seen how the language will evolve in the marketplace, but would HN care if it wasn't a Google language?
For C or C++ and a few others, maybe. For most other languages, language and implementation are very much tied, for practical reasons (size of community, maturity, degree of compatibility, etc etc).
As for using some Java/.NET "commercial native compiler" is not a real (or desired) option for most people/companies. For one, it delves into non standard waters, and can bring obscure bugs, restrictions (e.g reflection related), etc. Second, you have to pay. Third, it's one more thing to pile on top of your language choice. Where my argument was that Go gives some people using it LESS things to worry about.
For the rest of your list: the point was that they get ALL of them from Go at the same time. Being able to get one or another feature from this or that language is not comparable to that.
I also don't understand why you bring Rust into this. Rust is not production ready -- even the project leaders advise AGAINST using it for anything production related. It's also in flux, and the syntax is still changing. So, nice language as it shapes to be, isn't it obvious that it's not in any way an alternative to Go for at least one more year?
I just wanted to enumerate a few languages where those features are present.
If you feel like, I can present an extensive list of every Go feature and which languages offer similar support.
But what would be the point besides fueling a flamewar?
I jumped into Go at the begging, because I was looking for something with the features of today's mainstream languages and the language's Oberon influence interested me. Given the time I spent with Native Oberon back in the 90's.
In the end I became disappointed as the language is not much more than Limbo (1995) reborn.
> I also don't understand why you bring Rust into this. Rust is not production ready
So what, Go also wasn't when I was using it, and it did not prevent companies like Canonical to use the language in production.
I just get the feeling if Go authors weren't working at Google, the language wouldn't be given front page presence on HN every day, given its design.
On the other hand, I wish Go becomes success as it might help decrease even more the use cases where C is still relevant.
Go was far more production ready even when it first appeared (after internal development). For Rust, we are at the stage or internal development at this point, only it happens publicly. So the two are in no way comparable in that respect -- and that's why Canonical had no problem using it in production.
>I just get the feeling if Go authors weren't working at Google, the language wouldn't be given front page presence on HN every day, given its design.
Yes, but they are and so it is. Which reminds of a Jimmy Carr joke, about his girlfriend.
"People would say to me: she's only with you cause you're famous. And I'd tell them, well, I AM famous, so what's your point?".
So, even if people are using Go because of Google, well, it IS Google that is behind the language, so this also helps it.
def f(a=11, b="some default", c=55.5, d=D()):
#...
f(c=44.4)
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})
}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)
// ...
}
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?
Only insofar as your approach puts the values back into a struct that can subsequently be used in a type safe manner. Arguably that's better than having no type safety at all.
But I think my main gripe with your design is that it is not just less type safe and slower, it also comes with more mental friction and verbosity than what Python does.
Granted, it's a lot less verbose than my Go code, which makes it a good solution in some scenarios. But in my view it's not a good general replacement for default keyword args and you didn't claim it was.
The application I'm currently working on is mostly a direct port of Python code to Go. Python code I originally wrote. You needn't tell me it fails to accomplish all the things Python's default args do.
Test case:
func main() {
f(&Config{a: 0, b:"", c:0.0, d:nil})
}
=> It is even harder to replicate that Python idiom (I wouldn't know how, but I have only glanced at the go language spec. It would help if you could auto-initialize structure members with values only known the the structure itself, or if one could replace that &Config above by a function call, like this: makeConfig(){c: 44.4})
That doesn't necessarily mean the code is broken. It may or may not be possible in a particular situation to treat the zero value as semantically special as I have done. But if it's not, then you are of course right that this creates an additional problem.
Using a seperate function to initialize a Config is fine, but you would actually have to create a makeConfigForF function because the defaults are specific to f and not to Config. It's all messy. That's why I like keyword default arguments.
type Config struct {
a int
b string
c float
d interface{}
}
var defaultConfig = Config{
a: 11,
b: "some default",
c: 55.5,
d: new(D),
}
func f(cfg Config) {
// ...
}
func main() {
cfg := defaultConfig
cfg.c = 44.4
f(cfg)
}