4 ms·

So, if Go is as bad as the comments so far make it out to be, what are some alternative languages? Specifically, a compiled language that can be deployed withou

by jerrac 11y ago

So, if Go is as bad as the comments so far make it out to be, what are some alternative languages? Specifically, a compiled language that can be deployed without worrying about dependencies. That's the feature that has had me looking into learning Go. I want to be able to just copy one file to my server and run it, no need to install anything extra on the server to make my program work. Actually, can Go even do that? I think it can...

kasey_junk 11y ago
You mean any compiled language with static linking? Don't they all support that? I mean you can even get the jvm/java apps bundled as a single binary if you really want to.
stonewhite 11y ago
Statically linked binaries is not a new thing. You can do that on many languages.
chadaustin 11y ago
Haskell is my preferred statically-compiled-but-with-coroutines-and-channels language. It's harder to learn and the tooling is not as good as Go's, but its type system is far more powerful and useful. You can build useful generic abstractions over all types of channels and use them in every context. In Go you either have to use interface{} and pay the perf hit or write a code generator.
jerf 11y ago
"So, if Go is as bad as the comments so far make it out to be, what are some alternative languages?" While a good question anyhow, it's not as bad as the comments make it out to be. Anything can be made to look bad by only looking at the negatives, anything can be made to look good by only looking at the positives. And the balance shifts depending on what sort of application you're writing. There's a reason that Go has seen a lot of success writing network servers. There's a reason why Go has no penetration into the scientific computing community, and I tend to warn away anybody even thinking about it. In particular, a lot of the people screaming about Go do not consider some of the positives. For instance, thanks to the implicit satisfaction of interfaces, I find it one of the easiest mainstream imperative languages to still create a separation between IO and pure code, by wrapping all IO behind an interfaced object, one that I may not even have to create (i.e., Files already implement io.Reader and io.Writer, io.Reader & io.Writer also already have several test implementations available in the stdlib and it's easy to adapt them to a few more), which then allows me to write some really good testing code, almost as good as Haskell. (In fact, swapping in alternate implementations is probably easier than in Haskell.) This can be done in other languages, but it often involves jumping through hoops to create your own objects that mirror other object's methods so they can implement an interface or something; in Go it's trivially easy. Between that and the way errors are handled, I find it relatively easy to write very bullet-proof code. And while I also consider it annoying that Go lacks half of generics (interfaces are actually half of generics, but it's missing generic types), there are also often ways of spelling your APIs so it matters less. My code actually doesn't end up with very many interface{}s in it, and many of the ones that do are "real", in that the code in question really doesn't care what's there. If you don't put those positives onto the balance, you don't get a proper view. It doesn't help that, frankly, this was not a very good article and I strongly agree it has tone issues. This brought out a lot of people who might otherwise have just clicked over without commenting.
- pcwalton 11y ago
  > For instance, thanks to the implicit satisfaction of interfaces, I find it one of the easiest mainstream imperative languages to still create a separation between IO and pure code, by wrapping all IO behind an interfaced object, one that I may not even have to create (i.e., Files already implement io.Reader and io.Writer, io.Reader & io.Writer also already have several test implementations available in the stdlib and it's easy to adapt them to a few more), which then allows me to write some really good testing code, almost as good as Haskell. (In fact, swapping in alternate implementations is probably easier than in Haskell.) I'm confused. How does not having to write "implements Reader, Writer" (25 characters to type) have anything to do with purity and IO effects? > interfaces are actually half of generics Interfaces aren't generics at all. Java had interfaces and Object as a supertype before it had generics, and it still had zero support for generics. I do agree with you that Go has maybe 50% of the use cases for generics covered, but not because it has interfaces. Those don't count. It's because it has maps and growable arrays built in.
  - whacker 11y ago
    You can add methods on a type you don't control, without casting/subclassing that type. - the original interface does not have to even know that your interface exists.
  - jerf 11y ago
    "Interfaces aren't generics at all." It's a definition game. One component of "generic" is "generic algorithm". Go has that covered; the Sort package provides a "generic" algorithm via an interface specification. A lot of C++ template code is built around implementing generic algorithms at compile time rather than Go's run time, for instance. If you choose to call that "not generics", that's a valid choice of definition, and certainly makes sense in a Rust context, but it's not universally valid. For context, I'm not trying to bend a definition to "defend Go"... I generally have a low opinion of software engineer's ability to create universal definitions of terms that apply across all languages, and I observe that pretty much any term you can imagine varies across language communities. I'm not the one creating terminology vagueness. And I have observed that every time someone contradicts me and insists some term really is rigorously defined and agreed to by all major language communities, you can count on two or three disagreements from not-me in the replies...
pjmlp 11y ago
> Specifically, a compiled language that can be deployed without worrying about dependencies. That's the feature that has had me looking into learning Go. Any language with a compiler for native code. All of them support static linking, that is nothing special in the Go toolchain.
- jerrac 11y ago
  It's been a few years since my last C++ class, and I haven't done any compiled programming since. So I either completely forgot about static linking, or it just didn't get covered. Why have I seen several go apps that use static linking, but every C or C++ app I see uses dynamic linking? A quick google makes me think that the main downsides to static linking are resources and upstream bugs. Those issues would apply to go the same way they'd apply to C. Right? So why does it seem (from my limited experience) that go uses static linking more than other languages do?
  - pjmlp 11y ago
    The authors are very vocal against dynamic linking. http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/ Modern applications use dynamic linking most of the time, because despite the possible headache with versions, it offers a much more flexible architecture.
GFK_of_xmaspast 11y ago
C++.

by jerrac 11y ago

kasey_junk 11y ago

You mean any compiled language with static linking? Don't they all support that? I mean you can even get the jvm/java apps bundled as a single binary if you really want to.

stonewhite 11y ago

Statically linked binaries is not a new thing. You can do that on many languages.

chadaustin 11y ago

Haskell is my preferred statically-compiled-but-with-coroutines-and-channels language. It's harder to learn and the tooling is not as good as Go's, but its type system is far more powerful and useful. You can build useful generic abstractions over all types of channels and use them in every context. In Go you either have to use interface{} and pay the perf hit or write a code generator.

jerf 11y ago

"So, if Go is as bad as the comments so far make it out to be, what are some alternative languages?" While a good question anyhow, it's not as bad as the comments make it out to be. Anything can be made to look bad by only looking at the negatives, anything can be made to look good by only looking at the positives. And the balance shifts depending on what sort of application you're writing. There's a reason that Go has seen a lot of success writing network servers. There's a reason why Go has no penetration into the scientific computing community, and I tend to warn away anybody even thinking about it. In particular, a lot of the people screaming about Go do not consider some of the positives. For instance, thanks to the implicit satisfaction of interfaces, I find it one of the easiest mainstream imperative languages to still create a separation between IO and pure code, by wrapping all IO behind an interfaced object, one that I may not even have to create (i.e., Files already implement io.Reader and io.Writer, io.Reader & io.Writer also already have several test implementations available in the stdlib and it's easy to adapt them to a few more), which then allows me to write some really good testing code, almost as good as Haskell. (In fact, swapping in alternate implementations is probably easier than in Haskell.) This can be done in other languages, but it often involves jumping through hoops to create your own objects that mirror other object's methods so they can implement an interface or something; in Go it's trivially easy. Between that and the way errors are handled, I find it relatively easy to write very bullet-proof code. And while I also consider it annoying that Go lacks half of generics (interfaces are actually half of generics, but it's missing generic types), there are also often ways of spelling your APIs so it matters less. My code actually doesn't end up with very many interface{}s in it, and many of the ones that do are "real", in that the code in question really doesn't care what's there. If you don't put those positives onto the balance, you don't get a proper view. It doesn't help that, frankly, this was not a very good article and I strongly agree it has tone issues. This brought out a lot of people who might otherwise have just clicked over without commenting.

pcwalton 11y ago
> For instance, thanks to the implicit satisfaction of interfaces, I find it one of the easiest mainstream imperative languages to still create a separation between IO and pure code, by wrapping all IO behind an interfaced object, one that I may not even have to create (i.e., Files already implement io.Reader and io.Writer, io.Reader & io.Writer also already have several test implementations available in the stdlib and it's easy to adapt them to a few more), which then allows me to write some really good testing code, almost as good as Haskell. (In fact, swapping in alternate implementations is probably easier than in Haskell.) I'm confused. How does not having to write "implements Reader, Writer" (25 characters to type) have anything to do with purity and IO effects? > interfaces are actually half of generics Interfaces aren't generics at all. Java had interfaces and Object as a supertype before it had generics, and it still had zero support for generics. I do agree with you that Go has maybe 50% of the use cases for generics covered, but not because it has interfaces. Those don't count. It's because it has maps and growable arrays built in.
- whacker 11y ago
  You can add methods on a type you don't control, without casting/subclassing that type. - the original interface does not have to even know that your interface exists.
- jerf 11y ago
  "Interfaces aren't generics at all." It's a definition game. One component of "generic" is "generic algorithm". Go has that covered; the Sort package provides a "generic" algorithm via an interface specification. A lot of C++ template code is built around implementing generic algorithms at compile time rather than Go's run time, for instance. If you choose to call that "not generics", that's a valid choice of definition, and certainly makes sense in a Rust context, but it's not universally valid. For context, I'm not trying to bend a definition to "defend Go"... I generally have a low opinion of software engineer's ability to create universal definitions of terms that apply across all languages, and I observe that pretty much any term you can imagine varies across language communities. I'm not the one creating terminology vagueness. And I have observed that every time someone contradicts me and insists some term really is rigorously defined and agreed to by all major language communities, you can count on two or three disagreements from not-me in the replies...

pjmlp 11y ago

> Specifically, a compiled language that can be deployed without worrying about dependencies. That's the feature that has had me looking into learning Go. Any language with a compiler for native code. All of them support static linking, that is nothing special in the Go toolchain.

jerrac 11y ago
It's been a few years since my last C++ class, and I haven't done any compiled programming since. So I either completely forgot about static linking, or it just didn't get covered. Why have I seen several go apps that use static linking, but every C or C++ app I see uses dynamic linking? A quick google makes me think that the main downsides to static linking are resources and upstream bugs. Those issues would apply to go the same way they'd apply to C. Right? So why does it seem (from my limited experience) that go uses static linking more than other languages do?
- pjmlp 11y ago
  The authors are very vocal against dynamic linking. http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/ Modern applications use dynamic linking most of the time, because despite the possible headache with versions, it offers a much more flexible architecture.

GFK_of_xmaspast 11y ago

C++.