5 ms·

I wonder if Go is taking off due to folks coming from Python and Ruby, looking for something that has better perf and concurrency. Sorta like how Python got a l

I wonder if Go is taking off due to folks coming from Python and Ruby, looking for something that has better perf and concurrency. Sorta like how Python got a lot of Java users that were just sick of the boilerplate. The fact he compares Rust and Go is bizarre - they're totally different types of environments. Why not toss in OCaml and Java, too? Go is a managed runtime language and "systems" is only mentioned due to misleading marketing when the language launched. And of course Rust might feel a bit harder - no runtime means you gotta do all that stuff at compile time. Kills the chance for some shortcuts! People go on about how Go is practical and you don't need features, really. But that's a lame excuse. Facebook was built on PHP. Transport Tycoon was written in x86 assembly. Harry Potter was written with pen and paper. So you don't need. The attitude from the Go community is almost like an anti-intellectual one isn't it? F#'s inventor said it was hard getting generics into .NET because Microsoft viewed it as "academic and experimental" despite it being old ideas put into practice. Yet another decade later and Go is further promoting this anti-progress attitude. (I'm not really against Go, just disappointed in how weak available language technology is.)

commentzorro 11y ago
> The attitude from the Go community is almost like an anti-intellectual one isn't it? I hear you. There was a funny post a couple years ago weighing a bunch of languages on republican/conservative vs. democrat/liberal scale. But the author erred with Go. Go is certainly the most republican conservative language out there today. Go not only adopts the anti-intellectual stance but comes across as a language that's controlled by "religious leaders" who dictate not only the the direction of the language but its "morality" too. And those who use the language feel the same hidden pressures from constraints. This leads to a weird state of having to "believe" in a language and defending things: "like less is more", "choices are bad", and having others determining what you want and need. And this is the most annoying part. Because Go is really not a bad language. It's simple and constrained but easy to get into and easy to get stuff done. But Go's the whole attitude comes across as somewhat off-putting to window shoppers who might actually purchase and be fine with it otherwise.
- djhworld 11y ago
  Anti-intellectual seems an off key remark to me, I'd say Go just takes a different school of thought. Intellectualism doesn't mean everything should follow one path.
  - commentzorro 11y ago
    I don't think Go is anti-intellect as a language. I'm saying it's feature set makes it a definite choice to track an austere path. This seems to bring about a certain zeal and, especially for recent converts, a seeming need to proselytize. It's as if those new to Go need to convince themselves by saying out loud that they are, in fact, heading down a good and righteous road. I just haven't seen this sort of quasi faith-based argument coming from the other languages in the Algol tree.
lobster_johnson 11y ago
> folks coming from Python and Ruby, looking for something that has better perf and concurrency Long-time Ruby developer here, relunctant Go developer. Absolutely. I want performance, concurrency, efficient memory usage, and static typing. Ruby is lacking in all these areas. Go is mildly better, but is regressive in many other respects. For me, Go is a step back in terms of productivity, but a step forward in creating stable, fault-tolerant code. It's a compromise. Go feels like a stopgap solution until something better comes along. For example, I've learned to design the internals of my code around a functional style that makes code composable and the data flow simple. Go doesn't support that style, not really. Go promotes simplicity, but a lot of stuff that should be simple in Go isn't "simple". Like mapping and reducing an array. What's interesting is that working in Go reminds me a lot of using Borland's ObjectPascal back in the mid-1990s: A small, natively compiled (and super fast to compile), not-functional language with built-in reflection and a stupidly strict, cumbersome type system. Go makes very few innovations over ObjectPascal, and inherits many of its problems; Go's notorious lack of generics, for example, caused exactly the same issues back then. And nobody should be surprised about that. Currently, the language that looks closest to my ideal is Nimrod. Unfortuantely, it has almost zero mind share, and has a surprising amount of odd, off-putting warts for such a young language (perhaps not too surprising when you realize that for many years it was just one guy hacking away at it, TempleOS-style), disappointing since many design choices just feel just right, like someone has read my mind. Currently I'm on the fence with Nimrod. Jonathan Blow's jai also looks promising.
- acconsta 11y ago
  >I've learned to design the internals of my code around a functional style that makes code composable and the data flow simple. Curious: why not go all the way and use Scala, F#, Clojure, maybe even Haskell?
  - lobster_johnson 11y ago
    I've considered most of them, actually. One consistent, niggling problem with all of these languages is that they are still obscure compared to everything else, with all that this entails: It's harder to find developers who already know the languages well enough to be true masters, let alone find juniors who are interested and capable of picking them up; the languages are often complicated and unfriendly, so junior developers will again struggle. Something I've learned the last few years is that while having only wizards on your team is great, it's useful to have access to a less advanced contingent of developers who can still contribute productively. In the end, if you buy into something that not every shop uses, there will be a lot of sunk cost into having brought everyone into the fold, and you end up being an "OCaml shop" or "Haskell shop" or whatever. Productivity will probably normalize, but I'm not sure I want to go down that route. OCaml looks to me like the most promising functional language with the fewest warts, the most pragmatic approach to real-world apps, and possibly the best performance. But it's not a simple language, with a learning curve that's similar to Haskell. I also have to say that like Erlang, the toolset and syntax occasionally feels antiquated (for example, there's no excuse not to provide a modern readline-enabled REPL). OCaml still is not good at concurrency. Scala has some good parts, but is overdesigned and way too complex, in my opinion. Last I checked, performance was worse Java. It also runs on the JVM, which means its memory usage is inherently inefficient. F# is a language that I like a lot; in some ways it looks like a more pragmatic Haskell, or Ocaml with a cleaner syntax. I don't like the fact that it's tied to .NET, which (like Java) means it inherits all the issues from that platform. The performance on Mono looks unsatisfying. Haskell is also a language I like a lot — at least in theory. I've been disappointed with performance and memory usage (and the ability to reason about those things). The tools for concurrency (and OTP-type distributed networking) also seem very much lacking. Whenever I see an example of parallel async code in Haskell, I feel like I'm reading an advanced physics paper. While I like and understand the approach to purity, I feel like the tools get in the way of programming; that I have to work at getting in and out of effectful code just so that I can stay pure, and for what reason? Bugs caused by side effects is something I encounter only a few times a year, if that; Haskell builds a huge wall to solve something that isn't a problem for me. Nor do I enjoy that laziness is the default. Finally, there are parts of the language that seem immature; the well-known data record namespacing issue (being fixed?), and the sheer awkwardness that comes with trying to implement certain things (like polymorphic collections and directed graphs) that should be simple, but aren't. Still, it's a beautiful language, but not one I would use for everything. Clojure is the JVM, again. It's also not statically typed. From everything I've seen, performance is worse than Java.

commentzorro 11y ago

> The attitude from the Go community is almost like an anti-intellectual one isn't it? I hear you. There was a funny post a couple years ago weighing a bunch of languages on republican/conservative vs. democrat/liberal scale. But the author erred with Go. Go is certainly the most republican conservative language out there today. Go not only adopts the anti-intellectual stance but comes across as a language that's controlled by "religious leaders" who dictate not only the the direction of the language but its "morality" too. And those who use the language feel the same hidden pressures from constraints. This leads to a weird state of having to "believe" in a language and defending things: "like less is more", "choices are bad", and having others determining what you want and need. And this is the most annoying part. Because Go is really not a bad language. It's simple and constrained but easy to get into and easy to get stuff done. But Go's the whole attitude comes across as somewhat off-putting to window shoppers who might actually purchase and be fine with it otherwise.

djhworld 11y ago
Anti-intellectual seems an off key remark to me, I'd say Go just takes a different school of thought. Intellectualism doesn't mean everything should follow one path.
- commentzorro 11y ago
  I don't think Go is anti-intellect as a language. I'm saying it's feature set makes it a definite choice to track an austere path. This seems to bring about a certain zeal and, especially for recent converts, a seeming need to proselytize. It's as if those new to Go need to convince themselves by saying out loud that they are, in fact, heading down a good and righteous road. I just haven't seen this sort of quasi faith-based argument coming from the other languages in the Algol tree.

lobster_johnson 11y ago

> folks coming from Python and Ruby, looking for something that has better perf and concurrency Long-time Ruby developer here, relunctant Go developer. Absolutely. I want performance, concurrency, efficient memory usage, and static typing. Ruby is lacking in all these areas. Go is mildly better, but is regressive in many other respects. For me, Go is a step back in terms of productivity, but a step forward in creating stable, fault-tolerant code. It's a compromise. Go feels like a stopgap solution until something better comes along. For example, I've learned to design the internals of my code around a functional style that makes code composable and the data flow simple. Go doesn't support that style, not really. Go promotes simplicity, but a lot of stuff that should be simple in Go isn't "simple". Like mapping and reducing an array. What's interesting is that working in Go reminds me a lot of using Borland's ObjectPascal back in the mid-1990s: A small, natively compiled (and super fast to compile), not-functional language with built-in reflection and a stupidly strict, cumbersome type system. Go makes very few innovations over ObjectPascal, and inherits many of its problems; Go's notorious lack of generics, for example, caused exactly the same issues back then. And nobody should be surprised about that. Currently, the language that looks closest to my ideal is Nimrod. Unfortuantely, it has almost zero mind share, and has a surprising amount of odd, off-putting warts for such a young language (perhaps not too surprising when you realize that for many years it was just one guy hacking away at it, TempleOS-style), disappointing since many design choices just feel just right, like someone has read my mind. Currently I'm on the fence with Nimrod. Jonathan Blow's jai also looks promising.

acconsta 11y ago
>I've learned to design the internals of my code around a functional style that makes code composable and the data flow simple. Curious: why not go all the way and use Scala, F#, Clojure, maybe even Haskell?
- lobster_johnson 11y ago
  I've considered most of them, actually. One consistent, niggling problem with all of these languages is that they are still obscure compared to everything else, with all that this entails: It's harder to find developers who already know the languages well enough to be true masters, let alone find juniors who are interested and capable of picking them up; the languages are often complicated and unfriendly, so junior developers will again struggle. Something I've learned the last few years is that while having only wizards on your team is great, it's useful to have access to a less advanced contingent of developers who can still contribute productively. In the end, if you buy into something that not every shop uses, there will be a lot of sunk cost into having brought everyone into the fold, and you end up being an "OCaml shop" or "Haskell shop" or whatever. Productivity will probably normalize, but I'm not sure I want to go down that route. OCaml looks to me like the most promising functional language with the fewest warts, the most pragmatic approach to real-world apps, and possibly the best performance. But it's not a simple language, with a learning curve that's similar to Haskell. I also have to say that like Erlang, the toolset and syntax occasionally feels antiquated (for example, there's no excuse not to provide a modern readline-enabled REPL). OCaml still is not good at concurrency. Scala has some good parts, but is overdesigned and way too complex, in my opinion. Last I checked, performance was worse Java. It also runs on the JVM, which means its memory usage is inherently inefficient. F# is a language that I like a lot; in some ways it looks like a more pragmatic Haskell, or Ocaml with a cleaner syntax. I don't like the fact that it's tied to .NET, which (like Java) means it inherits all the issues from that platform. The performance on Mono looks unsatisfying. Haskell is also a language I like a lot — at least in theory. I've been disappointed with performance and memory usage (and the ability to reason about those things). The tools for concurrency (and OTP-type distributed networking) also seem very much lacking. Whenever I see an example of parallel async code in Haskell, I feel like I'm reading an advanced physics paper. While I like and understand the approach to purity, I feel like the tools get in the way of programming; that I have to work at getting in and out of effectful code just so that I can stay pure, and for what reason? Bugs caused by side effects is something I encounter only a few times a year, if that; Haskell builds a huge wall to solve something that isn't a problem for me. Nor do I enjoy that laziness is the default. Finally, there are parts of the language that seem immature; the well-known data record namespacing issue (being fixed?), and the sheer awkwardness that comes with trying to implement certain things (like polymorphic collections and directed graphs) that should be simple, but aren't. Still, it's a beautiful language, but not one I would use for everything. Clojure is the JVM, again. It's also not statically typed. From everything I've seen, performance is worse than Java.