6 ms·

Although i'm still very unsure about rob pike's argument that go don't need generics since it has interface, a recent experience : After having implemented a m

by bsaul 12y ago

Although i'm still very unsure about rob pike's argument that go don't need generics since it has interface, a recent experience : After having implemented a mini web services in go and being fed up with its limited type system, i decided to stop coding in go and start recoding my project in java using what is often advertized here as the most minimal framework : dropwizard. Well, i downloaded the framework, configured maven, started the hello world tutorial, and quickly found myself dealing with 2 xml files, 1 yaml file, multiple classe files ecerywhere, and couldn't get the whole stuff work immediately. Then i realized that my golang implementation was already working, and that i completely understood my code and its potential performance characteristic, without having to have deep knowledge about the jvm internals, things like sevlet containers, or how the whole stack would deal with my global variables in a multi-threaded context. All my code was just one simple program. My temporary conclusion right now is that golang type system is indeed extremely shite, but that if what you need is to develop simple yet efficient web services, it doesn't matter that much.

tinco 12y ago
Although I am a Ruby programmer and would hate to have to work in Java, I do adore C# (it is a near-perfect language). And I feel I need to defend this certain aspect of statically typed pre-compiled languages. 1. Dropwizard is not a minimal web service library, it's a minimal web service framework. You could've used just a library, for example this[0] one, and be done in 10ish lines boilerplate that you fully understand. 2. That would also mean you wouldn't need Maven or any XML configuration. Just a bash script or a Makefile that invokes your compiler. 3. There's 3 ways to deal with global variables in the world. The first is plain allow them, and let everything go to shit when two threads access them at the same time. That's how most languages, including Java, do it. The second is allow them, but never allow more than one line of execution at the same time, this is how many scripting languages like Javascript and Ruby do it. The third is 'not' allow global variables at all, and instead only expose shared state through mechanisms that explicitly deal with concurrency like pipes/messages/locks, this is how Haskell and other pure languages do it. (There's also STM, but that's a bit more complex) Once you know which of the three your language does, you'll know exactly how to deal with it. No need to be uncertain about it. 0] http://docs.oracle.com/javase/7/docs/jre/api/net/httpserver/spec/com/sun/net/httpserver/HttpServer.html http://docs.oracle.com/javase/7/docs/jre/api/net/httpserver/...
lmm 12y ago
I don't think Java will get many defenders here. But try that in Scala, with Spray. There're a couple of lines of boilerplate to create the actor system, but that's about all. And you get a system that's flexible enough to let you write route definitions that look like a config file, but everything's typesafe. Your routes are just functions, you can refactor them like ordinary code. So too are the kind of "cross-cutting concerns" like authentication or async calls that you'd have to either have built into your framework, or use some kind of "magic" (AOP, monkeypatching) to add to all the methods where they were needed. https://github.com/spray/spray/tree/release/1.1/examples/spray-can/simple-http-server/src/main/scala/spray/examples https://github.com/spray/spray/tree/release/1.1/examples/spr...
- kasey_junk 12y ago
  > use some kind of "magic" No it doesn't use magic, but it does take a language that is burdened with a complex type system and throws it out the window. You also are glossing over a huge host of complexity around build/deployment. What jvm are you targeting? Is it on the servers you are deploying to? Are you going to make a fat jar? If not, how are you doing dependency resolution? Is your build artifact something that sbt does out of the box or slightly different (lord help you if it is)? Are you going to do ivy, s3, or maven resolution? All of that complexity falls away with golang and this is a conscious choice of the golang team. I have lots of things I love about Scala and lots of things I hate about golang, but from a "get simple web service out the door in a scalable way" golang wins hands down.
  - lmm 12y ago
    > No it doesn't use magic, but it does take a language that is burdened with a complex type system and throws it out the window. What are you talking about? Spray works hand-in-glove with the Scala type system; would, in fact, be impossible in a language without it. > You also are glossing over a huge host of complexity around build/deployment. What jvm are you targeting? Is it on the servers you are deploying to? Are you going to make a fat jar? If not, how are you doing dependency resolution? Is your build artifact something that sbt does out of the box or slightly different (lord help you if it is)? Are you going to do ivy, s3, or maven resolution? If you're just playing around, you push the button in your IDE and it runs. If you're a serious business you make these decisions once and reuse them in every project. (To answer your questions explicitly: the default is to build for java 1.6, which has been on servers since before go even existed; if you're building for a newer version it's because you know what you're doing. My personal choice would be the maven appassembler plugin, but using the shade plugin to make a fat jar works fine too. I wouldn't touch SBT, it's too complex). Yes, you do have to make some choices, put a bit of effort into deployment. But I think that's a necessary cost, because it's the only way to allow tooling to evolve. Imagine if ant had been built into the JVM back in 2000; maven would never have been able to replace it, so we'd be stuck with it forever. Look at the Python standard library; when Python first got big, it was this great selling point full of really useful tools. Now, it's where modules go to die, because things that are built into the language can't evolve at the same place as things that are outside it. I fear exactly the same thing will happen to the Go tooling (though of course, we won't know one way or the other for ten years). If I can think of one language that really emphasised an "easy deployment model", it's PHP. Not only did that approach lead to terrible deployment practices, but now that the landscape has shifted and Apache is no longer universal the way it once was, it's not even particularly easy to deploy PHP any more.
vegabook 12y ago
I have to say that I am tempted by Go precisely because I see a lot of comments like yours, namely, it seems just to "work" in a very simple way. I find myself somewhat overwhelmed by the avalanche of new language opportunities I am supposed to invest time in. Most seem to have this huge kitbag of functionality and they seem to merge into each other making it quite confusing which I should go to, and with technologies such as the LLVM it seems to me we're only at the beginning of the new language storm, where every CS postgrad wants to create a new language that does everything. Go seems to have a very clear and unique proposition in this environment: sparsity. This seems to me to be a very good differentiator, and to the extent that the language were to move towards all the other languages and try to add features, I personally would be disappointed. This is not spoken at all as an expert in Golang, quite the opposite. I simply love the clean imperative aspect which Golang seems to have and is why I am very tempted to learn it.
- bojo 12y ago
  Go is the most boring language I have ever coded in, and that is why I love it. Sure, it doesn't have some fancy bells and whistles people seem to want, but when you can sit down and write something functional, portable, and readable fairly quickly, I'd say that is a huge win.
  - nine_k 12y ago
    "Functional"? I suppose you meant "procedural" :)
    - seunosewa 12y ago
      Something that works.
  - threeseed 12y ago
    You know you could replace "Go" with "Java 1.0" and your comment would still be accurate. Funny that.
    - 12y ago
vardump 12y ago
Not to mention deployment. No JVM to configure. Or application server... Minimally, just drop the binary and an init.d script. Feel free to use something fancier for manageability etc., the point was the simple option is available.
- threeseed 12y ago
  You don't need to configure the JVM as in many cases the defaults are fine. And most of the frameworks in use today do not require an application server. Go is definitely simple. But I wouldnt characterise modern day Java development as being that complicated.
  - vardump 12y ago
    Well, you don't need the JVM and any dependencies it pulls. That's also worth something in the era of "cloud" services. Less to install. Less to update. Ideally you only need to update the deployed application. Which in case of Go is that one binary. Another big thing is that same app written in Go just takes (significantly) less RAM than when written in Java. Go has arrays (and slices) of structs, not just struct pointers (in Java-speak: object references). This also dramatically reduces short lived garbage. Additionally Golang strings consume less memory, as they are UTF-8 by default in memory. In Java, you can start JVM with -XX:+UseCompressedStrings option, but that adds branches and still falls back to UTF-16 when string contains non-ascii characters.
    - Xorlev 12y ago
      Java also has arrays. And on heap/off heap RAM allocation. We deploy all our services as uberjars, we have a single Amazon AMI with JDK 8 installed. It's pretty frictionless. It goes from a simple Gradle project, to a single jar on S3, and pulled from S3 by our AMI. Automatically launches via an upstart script. I'll give you less RAM usage for sure. But when I'm launching a whole VM for a service anyways, I don't care that much. I tend to lean toward Go when I want a low-footprint coprocess for another service, or other small apps.
kyrra 12y ago
Another big benefit of Go over Java is licensing costs. While it may not matter to company that is just a website, it does matter if you are shipping hardware with services running on it. Java you have to pay per device shipped. Golang from top to bottom is BSD licensed, no costs to ship apps with it.
kyrra 12y ago
There have been some fairly involved discussions about generics recently on the Golang mailing list[0][1]. I think at this point the Go team isn't really opposed to Generics, but high-level ideas about it have basically all been proposed at this point. The only way a generics (however you choose to define it) will be added to Go is if someone puts together an in-depth proposal about how it works, beyond just syntax. This means how it will work with the compiler/linker. How it will work with the runtime and GC. Due to the amount of time it will take to put together such a proposal without the guarantee that it would be added, no one has gone down that path yet. You also need a deep understanding of many parts of the language to be able to produce such a proposal, which is another barrier. [0] https://groups.google.com/forum/#!topic/golang-nuts/L-2OTItScJk https://groups.google.com/forum/#!topic/golang-nuts/L-2OTItS... [1] https://groups.google.com/forum/#!topic/golang-nuts/smT_0BhHfBs https://groups.google.com/forum/#!topic/golang-nuts/smT_0BhH...

by bsaul 12y ago

tinco 12y ago

Although I am a Ruby programmer and would hate to have to work in Java, I do adore C# (it is a near-perfect language). And I feel I need to defend this certain aspect of statically typed pre-compiled languages. 1. Dropwizard is not a minimal web service library, it's a minimal web service framework. You could've used just a library, for example this[0] one, and be done in 10ish lines boilerplate that you fully understand. 2. That would also mean you wouldn't need Maven or any XML configuration. Just a bash script or a Makefile that invokes your compiler. 3. There's 3 ways to deal with global variables in the world. The first is plain allow them, and let everything go to shit when two threads access them at the same time. That's how most languages, including Java, do it. The second is allow them, but never allow more than one line of execution at the same time, this is how many scripting languages like Javascript and Ruby do it. The third is 'not' allow global variables at all, and instead only expose shared state through mechanisms that explicitly deal with concurrency like pipes/messages/locks, this is how Haskell and other pure languages do it. (There's also STM, but that's a bit more complex) Once you know which of the three your language does, you'll know exactly how to deal with it. No need to be uncertain about it. 0] http://docs.oracle.com/javase/7/docs/jre/api/net/httpserver/spec/com/sun/net/httpserver/HttpServer.html http://docs.oracle.com/javase/7/docs/jre/api/net/httpserver/...

lmm 12y ago

I don't think Java will get many defenders here. But try that in Scala, with Spray. There're a couple of lines of boilerplate to create the actor system, but that's about all. And you get a system that's flexible enough to let you write route definitions that look like a config file, but everything's typesafe. Your routes are just functions, you can refactor them like ordinary code. So too are the kind of "cross-cutting concerns" like authentication or async calls that you'd have to either have built into your framework, or use some kind of "magic" (AOP, monkeypatching) to add to all the methods where they were needed. https://github.com/spray/spray/tree/release/1.1/examples/spray-can/simple-http-server/src/main/scala/spray/examples https://github.com/spray/spray/tree/release/1.1/examples/spr...

kasey_junk 12y ago
> use some kind of "magic" No it doesn't use magic, but it does take a language that is burdened with a complex type system and throws it out the window. You also are glossing over a huge host of complexity around build/deployment. What jvm are you targeting? Is it on the servers you are deploying to? Are you going to make a fat jar? If not, how are you doing dependency resolution? Is your build artifact something that sbt does out of the box or slightly different (lord help you if it is)? Are you going to do ivy, s3, or maven resolution? All of that complexity falls away with golang and this is a conscious choice of the golang team. I have lots of things I love about Scala and lots of things I hate about golang, but from a "get simple web service out the door in a scalable way" golang wins hands down.
- lmm 12y ago
  > No it doesn't use magic, but it does take a language that is burdened with a complex type system and throws it out the window. What are you talking about? Spray works hand-in-glove with the Scala type system; would, in fact, be impossible in a language without it. > You also are glossing over a huge host of complexity around build/deployment. What jvm are you targeting? Is it on the servers you are deploying to? Are you going to make a fat jar? If not, how are you doing dependency resolution? Is your build artifact something that sbt does out of the box or slightly different (lord help you if it is)? Are you going to do ivy, s3, or maven resolution? If you're just playing around, you push the button in your IDE and it runs. If you're a serious business you make these decisions once and reuse them in every project. (To answer your questions explicitly: the default is to build for java 1.6, which has been on servers since before go even existed; if you're building for a newer version it's because you know what you're doing. My personal choice would be the maven appassembler plugin, but using the shade plugin to make a fat jar works fine too. I wouldn't touch SBT, it's too complex). Yes, you do have to make some choices, put a bit of effort into deployment. But I think that's a necessary cost, because it's the only way to allow tooling to evolve. Imagine if ant had been built into the JVM back in 2000; maven would never have been able to replace it, so we'd be stuck with it forever. Look at the Python standard library; when Python first got big, it was this great selling point full of really useful tools. Now, it's where modules go to die, because things that are built into the language can't evolve at the same place as things that are outside it. I fear exactly the same thing will happen to the Go tooling (though of course, we won't know one way or the other for ten years). If I can think of one language that really emphasised an "easy deployment model", it's PHP. Not only did that approach lead to terrible deployment practices, but now that the landscape has shifted and Apache is no longer universal the way it once was, it's not even particularly easy to deploy PHP any more.

vegabook 12y ago

I have to say that I am tempted by Go precisely because I see a lot of comments like yours, namely, it seems just to "work" in a very simple way. I find myself somewhat overwhelmed by the avalanche of new language opportunities I am supposed to invest time in. Most seem to have this huge kitbag of functionality and they seem to merge into each other making it quite confusing which I should go to, and with technologies such as the LLVM it seems to me we're only at the beginning of the new language storm, where every CS postgrad wants to create a new language that does everything. Go seems to have a very clear and unique proposition in this environment: sparsity. This seems to me to be a very good differentiator, and to the extent that the language were to move towards all the other languages and try to add features, I personally would be disappointed. This is not spoken at all as an expert in Golang, quite the opposite. I simply love the clean imperative aspect which Golang seems to have and is why I am very tempted to learn it.

bojo 12y ago
Go is the most boring language I have ever coded in, and that is why I love it. Sure, it doesn't have some fancy bells and whistles people seem to want, but when you can sit down and write something functional, portable, and readable fairly quickly, I'd say that is a huge win.
- nine_k 12y ago
  "Functional"? I suppose you meant "procedural" :)
  - seunosewa 12y ago
    Something that works.
- threeseed 12y ago
  You know you could replace "Go" with "Java 1.0" and your comment would still be accurate. Funny that.
  - 12y ago

vardump 12y ago

Not to mention deployment. No JVM to configure. Or application server... Minimally, just drop the binary and an init.d script. Feel free to use something fancier for manageability etc., the point was the simple option is available.

threeseed 12y ago
You don't need to configure the JVM as in many cases the defaults are fine. And most of the frameworks in use today do not require an application server. Go is definitely simple. But I wouldnt characterise modern day Java development as being that complicated.
- vardump 12y ago
  Well, you don't need the JVM and any dependencies it pulls. That's also worth something in the era of "cloud" services. Less to install. Less to update. Ideally you only need to update the deployed application. Which in case of Go is that one binary. Another big thing is that same app written in Go just takes (significantly) less RAM than when written in Java. Go has arrays (and slices) of structs, not just struct pointers (in Java-speak: object references). This also dramatically reduces short lived garbage. Additionally Golang strings consume less memory, as they are UTF-8 by default in memory. In Java, you can start JVM with -XX:+UseCompressedStrings option, but that adds branches and still falls back to UTF-16 when string contains non-ascii characters.
  - Xorlev 12y ago
    Java also has arrays. And on heap/off heap RAM allocation. We deploy all our services as uberjars, we have a single Amazon AMI with JDK 8 installed. It's pretty frictionless. It goes from a simple Gradle project, to a single jar on S3, and pulled from S3 by our AMI. Automatically launches via an upstart script. I'll give you less RAM usage for sure. But when I'm launching a whole VM for a service anyways, I don't care that much. I tend to lean toward Go when I want a low-footprint coprocess for another service, or other small apps.

kyrra 12y ago

Another big benefit of Go over Java is licensing costs. While it may not matter to company that is just a website, it does matter if you are shipping hardware with services running on it. Java you have to pay per device shipped. Golang from top to bottom is BSD licensed, no costs to ship apps with it.

kyrra 12y ago

There have been some fairly involved discussions about generics recently on the Golang mailing list[0][1]. I think at this point the Go team isn't really opposed to Generics, but high-level ideas about it have basically all been proposed at this point. The only way a generics (however you choose to define it) will be added to Go is if someone puts together an in-depth proposal about how it works, beyond just syntax. This means how it will work with the compiler/linker. How it will work with the runtime and GC. Due to the amount of time it will take to put together such a proposal without the guarantee that it would be added, no one has gone down that path yet. You also need a deep understanding of many parts of the language to be able to produce such a proposal, which is another barrier. [0] https://groups.google.com/forum/#!topic/golang-nuts/L-2OTItScJk https://groups.google.com/forum/#!topic/golang-nuts/L-2OTItS... [1] https://groups.google.com/forum/#!topic/golang-nuts/smT_0BhHfBs https://groups.google.com/forum/#!topic/golang-nuts/smT_0BhH...