3 ms·

> I think the language they designed has the properties they desired That's a tautology though :) Of course any language designer will design a language accord

by apta 6y ago

> I think the language they designed has the properties they desired That's a tautology though :) Of course any language designer will design a language according to the properties he/she desires. > you run into bugs like this early on Not necessarily. Race conditions are hard to find. It's established that "simplicity" is not a straight forward metric to measure. Having a simplistic language just means that complexity is being pushed on the programmer, since most non-trivial programs are complex by definition. Regardless of what the goals of golang were (they kept changing their definition of "systems language"), the fact that it's being pushed for almost everything, due to hype and fad driven development, and the inexperience of many programmers, is an issue. It's almost ironic that golang is used more outside of google than in.

ben0x539 6y ago
> That's a tautology though :) Of course any language designer will design a language according to the properties he/she desires. Eh, you can just fail, too, no? Like I could sit down and set myself the goal of designing a language that achieves goal X while staying under complexity limit Y (by whatever measurement), and then end up having to compromise on either of them because I can't quite figure out a good way to achieve a particularly tricky part of X without adding a lot more complexity than I initially expected. Or I could decide I want to design a language that's portable across many CPU architectures but inadvertently bake in a lot of x86isms that make it awkward/inefficient to implement elsewhere. > Not necessarily. Race conditions are hard to find. It's established that "simplicity" is not a straight forward metric to measure. Having a simplistic language just means that complexity is being pushed on the programmer, since most non-trivial programs are complex by definition. Ah, I didn't mean that concurrency bugs are quickly found or solved. I definitely agree with the just-moving-the-complexity-around part. I just meant that soon after getting started with Go, you'll probably have run into a bunch of concurrency bugs already and developed the kind of mental scarring and automatic averse reactions to certain concurrency situations that'll let you cope and still get things done despite it being clearly suboptimal. > the fact that it's being pushed for almost everything, due to hype and fad driven development, and the inexperience of many programmers, is an issue. But this is a kind of success too, isn't it? Presenting your solution to a problem in a way that appeals to enough "inexperienced" people to create the hype/fad isn't trivial, so they must have been doing something right. I don't think it's just a case of "$bigcorp does it, so it's cool", plenty of $bigcorp languages or technologies don't really catch on, let alone on Go's scale. I think there really is a niche where Go is the best solution (or at least a significant local maximum), even if that is only "'inexperienced' programmers can get started with, say, highly concurrent http services", it's still _something_. (Again, disclaimer: I use Go at work and I like to give my (non-google) employer and my coworkers enough credit to think that it's not just because of hype/fad, so I may be biased.)

by apta 6y ago

ben0x539 6y ago

> That's a tautology though :) Of course any language designer will design a language according to the properties he/she desires. Eh, you can just fail, too, no? Like I could sit down and set myself the goal of designing a language that achieves goal X while staying under complexity limit Y (by whatever measurement), and then end up having to compromise on either of them because I can't quite figure out a good way to achieve a particularly tricky part of X without adding a lot more complexity than I initially expected. Or I could decide I want to design a language that's portable across many CPU architectures but inadvertently bake in a lot of x86isms that make it awkward/inefficient to implement elsewhere. > Not necessarily. Race conditions are hard to find. It's established that "simplicity" is not a straight forward metric to measure. Having a simplistic language just means that complexity is being pushed on the programmer, since most non-trivial programs are complex by definition. Ah, I didn't mean that concurrency bugs are quickly found or solved. I definitely agree with the just-moving-the-complexity-around part. I just meant that soon after getting started with Go, you'll probably have run into a bunch of concurrency bugs already and developed the kind of mental scarring and automatic averse reactions to certain concurrency situations that'll let you cope and still get things done despite it being clearly suboptimal. > the fact that it's being pushed for almost everything, due to hype and fad driven development, and the inexperience of many programmers, is an issue. But this is a kind of success too, isn't it? Presenting your solution to a problem in a way that appeals to enough "inexperienced" people to create the hype/fad isn't trivial, so they must have been doing something right. I don't think it's just a case of "$bigcorp does it, so it's cool", plenty of $bigcorp languages or technologies don't really catch on, let alone on Go's scale. I think there really is a niche where Go is the best solution (or at least a significant local maximum), even if that is only "'inexperienced' programmers can get started with, say, highly concurrent http services", it's still _something_. (Again, disclaimer: I use Go at work and I like to give my (non-google) employer and my coworkers enough credit to think that it's not just because of hype/fad, so I may be biased.)