11 ms·

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concept

> “There is nothing new under the sun” rings true in all languages since the 80’s. Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go. Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler? Go made the decision to allow for Null, even after nearly every other modern language and other older ones are trying to kick it to the curb; Swift, Rust, Scala, Kotlin, no nulls (the JVM ones have a compatability problem, as does swift with ObjC, but still). Is it simpler to delay discovery of Null data to runtime? Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Like lambdas, it can be a complicated concept to learn, but once you unlock this in you code, you write less code and accomplish more. So yes, it's simpler, but at too high a cost IMO. To me the innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. This is a million times better than JVM, Ruby, Python, Perl, etc. This is a huge improvement over Java, and something every language should have an option for. Ironically this is also the least innovative feature, because this is how static binaries in C and C++ have worked for years. I think this article is very well written, but I don't think it's fair to the innovation going on in other languages. (Disclaimer: I used Go, discovered the three primary flaws as I listed above, and then searched for a better language. It would be fair to call me a hater, usually I try to avoid this, but in this case that's fine with me)

catnaroek 10y ago
> Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program. Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taking subtyping for granted. But what if subtyping isn't always a good idea? Say, because it forces you to reason about variance (which humans always seem to do wrong!). (inb4: Yes, Go has subtyping. When a struct conforms to a given interface, that's subtyping.)
- knucklesandwich 10y ago
  The biggest irony of Go is that they have invariant parametric types for channels, arrays, etc. and indeed primops like channel sends, make, len, etc. are parametric functions. So for all the defensiveness about how parametric polymorphism is "difficult to understand", Go programmers seem to deal just fine with it on a day-to-day basis. What they lack is the ability to let programmers introduce their own parametric types and functions, presumably because we're too dumb to be anything but consumers of this functionality.
  - Jtsummers 10y ago
    If we consider Go in the context of a systems (their definition) engineering language within Google's enterprise, limiting choice is not about how dumb the programmers are, but about ensuring conformity. Rewriting code is expensive. As my office knows well. We maintain lots of old embedded systems and have to periodically rewrite or rehost it because the old hardware platforms aren't available or aren't performant enough for new features. These become multi-year, multi-million dollar projects, for relatively little gain. By ensuring that developers and architects conform to certain conventions, it means (in theory) that this code maintenance is much cheaper, and that rewrites can be avoided or minimized. This is a good thing and lets organizations be more flexible and productive, as their time and money is no longer wasted on the old things, but can be spent on the new things.
    - catnaroek 10y ago
      > By ensuring that developers and architects conform to certain conventions Enforcing conventions is of course a good thing! The problem is how Go enforces conventions: (0) When Go enforces a convention mechanically, it's a triviality that can be adequately handled by external tools (e.g., naming, formatting, unused variables, etc.). (1) When a convention is actually useful (e.g., the correct way of using an interface), Go's type system is too dumb to understand it, let alone enforce it. > aren't performant enough for new features Second-class parametric polymorphism (“generics”) is purely a compile-time feature. It can be completely eliminated (that is, turned into the non-generic code you would've written otherwise) using a program transformation called “monomorphization”, before any target machine code is generated. So there's no runtime price to be paid.
omni 10y ago
> There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler? This may be considered cheating since it isn't baked into the language but there are tools to do this at build time, here's one: https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck
- iends 10y ago
  There are lots of tools in Go that make up for issues people have with the language. Another example is the IDE macros people use for the standard if err != nil {} block.
  - spriggan3 10y ago
    > Another example is the IDE macros people use for the standard if err != nil {} block Which doesn't make code easy to read when there are 10th of these blocks in a single function.
    - skybrian 10y ago
      It may be 4 lines of code where 1 or 2 would do, but I don't find it hard to read.
ehsan_akbari 10y ago
Hey, Are `integration tests` potato here!?
dominotw 10y ago
>innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. Is rust the only good alternative here to golang if you one doesn't want to write c/c++ ?
- dom96 10y ago
  Nim is another good alternative. Small, dependency-less binaries are one of its strong points.
- tinco 10y ago
  There are many compiled languages with embedded runtimes. Haskell is among the best of them.
  - soulbadguy 10y ago
    > haskell is among the best of them There is little need for this kind of absolutism. Citing a haskell as one the best language in a contest where op ask about rust and c++ is dangerous. To op : if your domain calls for modeling relatively 'type stable computation', and need strong correctness garanty, haskell is a great match.
    - tinco 10y ago
      How is it dangerous? Your qualifying remarks with regards to Haskell's domain make no sense. If you need a fast, compiled language with managed memory, high ease of development and a strong ecosystem then you can't go wrong with Haskell. 'Type stable computation' and a strong correctness guarantee are some added benefits of Haskell, though any strongly typed language (like for example Rust) will have these qualities. A nice benefit of Haskell that most other languages don't have is that it is explicit about side effects which gives you some extra confidence in the behaviors of your code. Related to this is its unusually powerful type system, which allows you to make some abstractions for generic code that are not possible in most other languages.
      - 10y ago
namelezz 10y ago
> This is a huge improvement over Java, and something every language should have an option for. I am not sure what improvement you are talking about. Deploying Go apps requires recompiling for the target platform. On JVM, you only need to install the JVM. There are also tools to wrap JVM apps in executable files that will automatically download and install a suitable JVM.
- bluejekyll 10y ago
  I'm specifically talking about the classpath, jars, separate jvm install. These are a pain to manage across environments. I'm a longtime Java engineer, it's a great language, but I do think the compile once thing isn't as big an advantage anymore. With the advent of the LLVM, it's easy to target specific machines. rustup, even makes it possible to build binaries for every target environment you have. And let's be honest, how many people target more than Linux/x86_64 on the server side? Even if you target FreeBSD or Windows, my bet is that your still generally only targeting one platform. Btw, Rust has a great std lib that is very portable across all major platforms. https://doc.rust-lang.org/book/getting-started.html https://doc.rust-lang.org/book/getting-started.html
  - namelezz 10y ago
    > I'm specifically talking about the classpath, jars, separate jvm install. These are a pain to manage across environments. I agree with the classpath issue and hopefully it will be fix in Java 9. Separate jvm install? Why? JVM is backwards compatibility. > And let's be honest, how many people target more than Linux/x86_64 on the server side. Those that develop non server apps since Java is a general-purpose language.
    - bluejekyll 10y ago
      Yes. I'm serverside generally. The JVM is, but sometimes there are things that require specific bug fixes in the GC for example where it's just a big issue combining the jars with the JVM etc. My only put is that a single thing to deploy is easier than multiple.
  - 10y ago
iends 10y ago
What better language did you settle on?
- zatkin 10y ago
  Probably Rust.
  - bluejekyll 10y ago
    Yep, but I think there are others that will fit people's needs as well. Rust suits my needs/wants perfectly.
    - iends 10y ago
      Rust really impresses me because the community and the ecosystem, but I've not looked at it too much.
      - f2f 10y ago
        nobody has.
deleted 10y ago
[deleted]
berkay 10y ago
"Like lambdas, it can be a complicated concept to learn, but once you unlock this in you code, you write less code and accomplish more" With the caveat that anyone who may be maintaining/using/enhancing your code will also need to be able to "unlock" this. Keeping the language simpler has benefits beyond the initial code development.
- Ericson2314 10y ago
  Or, you know, we could actually learn something in accordance with the nice pay most of us get.
  - groovy2shoes 10y ago
    This is one of my biggest frustrations when these sorts of discussions come up. It seems a great many programmers -- amateurs, students, and even professionals -- resist learning anything new. As programmers, we deal primarily in abstractions. Our programming languages offer formal tools for creating and manipulating abstractions. In my view, any language that offers more tools for abstractions is better than another language that offers fewer such tools. As a professional whose primary job is to deal with abstractions, any new kind of abstraction is of interest. All programmers should be not only willing to be constantly learning new techniques and new abstractions, but we should be eager to learn and apply these things. Bigger toolbox => better quality of life w.r.t. work. Even at my day job, I've heard things like "that's too computer sciency for mere mortals". I'm sorry, are we not computer scientists? Are we in the habit of employing people who are not professional programmers to write our software? And to think I'm the only developer in the office without a master's degree, as if they all decided that once they graduated they were finished learning... Heaven forbid you should have to learn something! To educate yourself! To grow in terms of knowledge and skill! Do we have "development goals" every year for no reason at all? As if spending an hour or two learning something would kill you! AAARRRRRRRRGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHH!!!
    - Ericson2314 10y ago
      And to think we then preach "disruption" to everyone else. It's just jawdropping. Allow me to disrupt your null and Interface {}.
spraak 10y ago
What is the better language that you found?
- bluejekyll 10y ago
  (Copied from below): Rust, but I think there are others that will fit people's needs as well. Rust suits my needs/wants perfectly.
danmux 10y ago
Thank you, and may I say what a well written comment. Poor old Tony Hoare (algol was mentioned earlier (rightly) as an exemplar of innovation) but Null in a safe memory managed context is a different beast to a true Null reference. Null appears then as something between a known state and an not quite an exception, it carries different semantics from either, and whilst this could be seen as more complexity, I think the "I just don't know" case in practicality is useful, if harder to reason about. Your point about the runtime is very true. Partly because of this - error checking is overrated! Yes I said it! We have go code that has been running in a reasonably high scale production environment for over two years and there are `if:...;err != nil` blocks that have never been touched in millions of calls per day, for 2 years. We have redundant services and trap panics in the rpc handlers, the nil becomes very clear and the rest of the system makes good progress. We save lines, save tests, and release a single binary fast. One example of where Go helps us deliver value faster, by being able to choose to ignore exceptions. Many people find this very uncomfortable. I say they are mistaking where the true project risks lie.
- bluejekyll 10y ago
  > being able to choose to ignore exceptions. Many people find this very uncomfortable. I say they are mistaking where the true project risks lie. It's funny, every language I know gives you an option to basically ignore the error and just pray. I get what your saying, but if this is the type of code you want to produce, you can still do that in other languages that have strong types around Null and Errors. In Rust for example: my_possible_error.unwrap() In places where you are explicitly making that choice. And to me that's the big difference. Is it explicit or implicit/unknown?
  - danmux 10y ago
    Fair point, just differing levels of hoops to jump through, or general expectations of best practice. In that sense I would say Java and C# do not allow you to 'ignore' exceptions. I suspect your "pray" == monitor closely and fix fast (often never). I agree it can be problematic that there is nothing in the language that indicates that the author is explicitly in 'pray' mode. It could well be that even a brief defence of a missing error check during a PR code review is not worth avoiding (un-triggered) err handling.

catnaroek 10y ago

> Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program. Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taking subtyping for granted. But what if subtyping isn't always a good idea? Say, because it forces you to reason about variance (which humans always seem to do wrong!). (inb4: Yes, Go has subtyping. When a struct conforms to a given interface, that's subtyping.)

knucklesandwich 10y ago
The biggest irony of Go is that they have invariant parametric types for channels, arrays, etc. and indeed primops like channel sends, make, len, etc. are parametric functions. So for all the defensiveness about how parametric polymorphism is "difficult to understand", Go programmers seem to deal just fine with it on a day-to-day basis. What they lack is the ability to let programmers introduce their own parametric types and functions, presumably because we're too dumb to be anything but consumers of this functionality.
- Jtsummers 10y ago
  If we consider Go in the context of a systems (their definition) engineering language within Google's enterprise, limiting choice is not about how dumb the programmers are, but about ensuring conformity. Rewriting code is expensive. As my office knows well. We maintain lots of old embedded systems and have to periodically rewrite or rehost it because the old hardware platforms aren't available or aren't performant enough for new features. These become multi-year, multi-million dollar projects, for relatively little gain. By ensuring that developers and architects conform to certain conventions, it means (in theory) that this code maintenance is much cheaper, and that rewrites can be avoided or minimized. This is a good thing and lets organizations be more flexible and productive, as their time and money is no longer wasted on the old things, but can be spent on the new things.
  - catnaroek 10y ago
    > By ensuring that developers and architects conform to certain conventions Enforcing conventions is of course a good thing! The problem is how Go enforces conventions: (0) When Go enforces a convention mechanically, it's a triviality that can be adequately handled by external tools (e.g., naming, formatting, unused variables, etc.). (1) When a convention is actually useful (e.g., the correct way of using an interface), Go's type system is too dumb to understand it, let alone enforce it. > aren't performant enough for new features Second-class parametric polymorphism (“generics”) is purely a compile-time feature. It can be completely eliminated (that is, turned into the non-generic code you would've written otherwise) using a program transformation called “monomorphization”, before any target machine code is generated. So there's no runtime price to be paid.

omni 10y ago

> There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler? This may be considered cheating since it isn't baked into the language but there are tools to do this at build time, here's one: https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck

iends 10y ago
There are lots of tools in Go that make up for issues people have with the language. Another example is the IDE macros people use for the standard if err != nil {} block.
- spriggan3 10y ago
  > Another example is the IDE macros people use for the standard if err != nil {} block Which doesn't make code easy to read when there are 10th of these blocks in a single function.
  - skybrian 10y ago
    It may be 4 lines of code where 1 or 2 would do, but I don't find it hard to read.

ehsan_akbari 10y ago

Hey, Are `integration tests` potato here!?

dominotw 10y ago

>innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. Is rust the only good alternative here to golang if you one doesn't want to write c/c++ ?

dom96 10y ago
Nim is another good alternative. Small, dependency-less binaries are one of its strong points.
tinco 10y ago
There are many compiled languages with embedded runtimes. Haskell is among the best of them.
- soulbadguy 10y ago
  > haskell is among the best of them There is little need for this kind of absolutism. Citing a haskell as one the best language in a contest where op ask about rust and c++ is dangerous. To op : if your domain calls for modeling relatively 'type stable computation', and need strong correctness garanty, haskell is a great match.
  - tinco 10y ago
    How is it dangerous? Your qualifying remarks with regards to Haskell's domain make no sense. If you need a fast, compiled language with managed memory, high ease of development and a strong ecosystem then you can't go wrong with Haskell. 'Type stable computation' and a strong correctness guarantee are some added benefits of Haskell, though any strongly typed language (like for example Rust) will have these qualities. A nice benefit of Haskell that most other languages don't have is that it is explicit about side effects which gives you some extra confidence in the behaviors of your code. Related to this is its unusually powerful type system, which allows you to make some abstractions for generic code that are not possible in most other languages.
    - 10y ago

namelezz 10y ago

> This is a huge improvement over Java, and something every language should have an option for. I am not sure what improvement you are talking about. Deploying Go apps requires recompiling for the target platform. On JVM, you only need to install the JVM. There are also tools to wrap JVM apps in executable files that will automatically download and install a suitable JVM.

bluejekyll 10y ago
I'm specifically talking about the classpath, jars, separate jvm install. These are a pain to manage across environments. I'm a longtime Java engineer, it's a great language, but I do think the compile once thing isn't as big an advantage anymore. With the advent of the LLVM, it's easy to target specific machines. rustup, even makes it possible to build binaries for every target environment you have. And let's be honest, how many people target more than Linux/x86_64 on the server side? Even if you target FreeBSD or Windows, my bet is that your still generally only targeting one platform. Btw, Rust has a great std lib that is very portable across all major platforms. https://doc.rust-lang.org/book/getting-started.html https://doc.rust-lang.org/book/getting-started.html
- namelezz 10y ago
  > I'm specifically talking about the classpath, jars, separate jvm install. These are a pain to manage across environments. I agree with the classpath issue and hopefully it will be fix in Java 9. Separate jvm install? Why? JVM is backwards compatibility. > And let's be honest, how many people target more than Linux/x86_64 on the server side. Those that develop non server apps since Java is a general-purpose language.
  - bluejekyll 10y ago
    Yes. I'm serverside generally. The JVM is, but sometimes there are things that require specific bug fixes in the GC for example where it's just a big issue combining the jars with the JVM etc. My only put is that a single thing to deploy is easier than multiple.
- 10y ago

iends 10y ago

What better language did you settle on?

zatkin 10y ago
Probably Rust.
- bluejekyll 10y ago
  Yep, but I think there are others that will fit people's needs as well. Rust suits my needs/wants perfectly.
  - iends 10y ago
    Rust really impresses me because the community and the ecosystem, but I've not looked at it too much.
    - f2f 10y ago
      nobody has.

deleted 10y ago

[deleted]

berkay 10y ago

"Like lambdas, it can be a complicated concept to learn, but once you unlock this in you code, you write less code and accomplish more" With the caveat that anyone who may be maintaining/using/enhancing your code will also need to be able to "unlock" this. Keeping the language simpler has benefits beyond the initial code development.

Ericson2314 10y ago
Or, you know, we could actually learn something in accordance with the nice pay most of us get.
- groovy2shoes 10y ago
  This is one of my biggest frustrations when these sorts of discussions come up. It seems a great many programmers -- amateurs, students, and even professionals -- resist learning anything new. As programmers, we deal primarily in abstractions. Our programming languages offer formal tools for creating and manipulating abstractions. In my view, any language that offers more tools for abstractions is better than another language that offers fewer such tools. As a professional whose primary job is to deal with abstractions, any new kind of abstraction is of interest. All programmers should be not only willing to be constantly learning new techniques and new abstractions, but we should be eager to learn and apply these things. Bigger toolbox => better quality of life w.r.t. work. Even at my day job, I've heard things like "that's too computer sciency for mere mortals". I'm sorry, are we not computer scientists? Are we in the habit of employing people who are not professional programmers to write our software? And to think I'm the only developer in the office without a master's degree, as if they all decided that once they graduated they were finished learning... Heaven forbid you should have to learn something! To educate yourself! To grow in terms of knowledge and skill! Do we have "development goals" every year for no reason at all? As if spending an hour or two learning something would kill you! AAARRRRRRRRGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHH!!!
  - Ericson2314 10y ago
    And to think we then preach "disruption" to everyone else. It's just jawdropping. Allow me to disrupt your null and Interface {}.

spraak 10y ago

What is the better language that you found?

bluejekyll 10y ago
(Copied from below): Rust, but I think there are others that will fit people's needs as well. Rust suits my needs/wants perfectly.

danmux 10y ago

Thank you, and may I say what a well written comment. Poor old Tony Hoare (algol was mentioned earlier (rightly) as an exemplar of innovation) but Null in a safe memory managed context is a different beast to a true Null reference. Null appears then as something between a known state and an not quite an exception, it carries different semantics from either, and whilst this could be seen as more complexity, I think the "I just don't know" case in practicality is useful, if harder to reason about. Your point about the runtime is very true. Partly because of this - error checking is overrated! Yes I said it! We have go code that has been running in a reasonably high scale production environment for over two years and there are `if:...;err != nil` blocks that have never been touched in millions of calls per day, for 2 years. We have redundant services and trap panics in the rpc handlers, the nil becomes very clear and the rest of the system makes good progress. We save lines, save tests, and release a single binary fast. One example of where Go helps us deliver value faster, by being able to choose to ignore exceptions. Many people find this very uncomfortable. I say they are mistaking where the true project risks lie.

bluejekyll 10y ago
> being able to choose to ignore exceptions. Many people find this very uncomfortable. I say they are mistaking where the true project risks lie. It's funny, every language I know gives you an option to basically ignore the error and just pray. I get what your saying, but if this is the type of code you want to produce, you can still do that in other languages that have strong types around Null and Errors. In Rust for example: my_possible_error.unwrap() In places where you are explicitly making that choice. And to me that's the big difference. Is it explicit or implicit/unknown?
- danmux 10y ago
  Fair point, just differing levels of hoops to jump through, or general expectations of best practice. In that sense I would say Java and C# do not allow you to 'ignore' exceptions. I suspect your "pray" == monitor closely and fix fast (often never). I agree it can be problematic that there is nothing in the language that indicates that the author is explicitly in 'pray' mode. It could well be that even a brief defence of a missing error check during a PR code review is not worth avoiding (un-triggered) err handling.