6 ms·

Some of the harder more time consuming things in high level programming include abstraction/polymorphism, concurrency and dependency management which are all si

by dgb23 10y ago

Some of the harder more time consuming things in high level programming include abstraction/polymorphism, concurrency and dependency management which are all simpler and clearer in Go than in Java. Think about how many hours you have to invest to learn any of these things in either language.

tmpxkdks 10y ago
> abstraction/polymorphism, concurrency and dependency management which are all simpler and clearer in Go than in Java Really? A lot of copy/pasted code, generics replaced with casts on empty interfaces, poor support for collections, only very primitive concurrency tools, and so on... I can understand that simplicity is good for small CLI/network tools, but it is hardly an alternative for really big applications where Java is vastly used
- Thaxll 10y ago
  Your big application shouldn't be that big first?
  - jeremiep 10y ago
    So you're saying we shouldn't have operating systems, browsers, video games and all that good stuff? Most actual engineering is very far from writing a dumb server for yet another CRUD app :)
    - Thaxll 10y ago
      What I'm saying is Golang is a recent programming language so it works best when used for multi tier/services, not to create a giant monolithic Java app that has a huge number of loc.
      - jeremiep 10y ago
        What does Java have to do with big monolithic apps? I think you're confusing complex application domains with bloat. Go is supposed to be a systems programming language. That means a very, very wide range of possible domains, where for many of them even network latency is unacceptable. For example, Photoshop would have a terrible user experience if it wasn't the monolith it is. A game engine wouldn't go above ~20FPS (even 60FPS games have a network loop that is capped around 20FPS). If I can't do systems-level programming in Go, what's its advantage over real systems languages or higher-level languages then? Especially when you consider what Go offers (CSP) comes in opt-in libraries in many other languages. I feel like Go should be put in the same category as C# and Java. They're just above systems languages but just below scripting languages; giving you the worst of both worlds. Not bare-metal, but also not that productive.
        pjmlp 10y ago
        Java does run bare metal and there are commercial JDKs with real-time GCs. PTC is one such those vendors, http://www.ptc.com/developer-tools/perc http://www.ptc.com/developer-tools/perc Go might eventually be used in such scenarios, but the toolchain is not yet there.
  - coldtea 10y ago
    That depends on business needs, not what some programming language designer thinks.
pjmlp 10y ago
Think about how many hours you have to invest in writing workarounds for features available out of the box in other languages.
- weberc2 10y ago
  Think of all the hours you save not having to work around the misfeatures available out of the box in other languages. I know, you don't make mistakes or use those nasty features, but think of your coworkers.
  - pjmlp 10y ago
    My coworkers are savvy enough to handle those features.
    - _ph_ 10y ago
      Then you are a very lucky person. For the rest of us, it is very good to have a manageable language at hand.
      - pjmlp 10y ago
        We can easily manage Java, C#, C++, Swift, Objective-C, JavaScript across our consulting projects....
        _ph_ 10y ago
        Of course you can. None of those languages would be in use, if projects could not be managed at all. The question is: are you benefiting from their "features" or are you able to succeed despite of the challenges brought up to you because of those features and their complexity?
        pjmlp 10y ago
        It was the simplicity of Java 1.0 that lead to some of the famous patterns we see in some frameworks, that were initially created to workaround language limitations. The same path that is being followed by those that rely on libraries to reduce error handling boilerplate and go generate, just as two examples.

by dgb23 10y ago

tmpxkdks 10y ago

> abstraction/polymorphism, concurrency and dependency management which are all simpler and clearer in Go than in Java Really? A lot of copy/pasted code, generics replaced with casts on empty interfaces, poor support for collections, only very primitive concurrency tools, and so on... I can understand that simplicity is good for small CLI/network tools, but it is hardly an alternative for really big applications where Java is vastly used

Thaxll 10y ago
Your big application shouldn't be that big first?
- jeremiep 10y ago
  So you're saying we shouldn't have operating systems, browsers, video games and all that good stuff? Most actual engineering is very far from writing a dumb server for yet another CRUD app :)
  - Thaxll 10y ago
    What I'm saying is Golang is a recent programming language so it works best when used for multi tier/services, not to create a giant monolithic Java app that has a huge number of loc.
    - jeremiep 10y ago
      What does Java have to do with big monolithic apps? I think you're confusing complex application domains with bloat. Go is supposed to be a systems programming language. That means a very, very wide range of possible domains, where for many of them even network latency is unacceptable. For example, Photoshop would have a terrible user experience if it wasn't the monolith it is. A game engine wouldn't go above ~20FPS (even 60FPS games have a network loop that is capped around 20FPS). If I can't do systems-level programming in Go, what's its advantage over real systems languages or higher-level languages then? Especially when you consider what Go offers (CSP) comes in opt-in libraries in many other languages. I feel like Go should be put in the same category as C# and Java. They're just above systems languages but just below scripting languages; giving you the worst of both worlds. Not bare-metal, but also not that productive.
      - pjmlp 10y ago
        Java does run bare metal and there are commercial JDKs with real-time GCs. PTC is one such those vendors, http://www.ptc.com/developer-tools/perc http://www.ptc.com/developer-tools/perc Go might eventually be used in such scenarios, but the toolchain is not yet there.
- coldtea 10y ago
  That depends on business needs, not what some programming language designer thinks.

pjmlp 10y ago

Think about how many hours you have to invest in writing workarounds for features available out of the box in other languages.

weberc2 10y ago
Think of all the hours you save not having to work around the misfeatures available out of the box in other languages. I know, you don't make mistakes or use those nasty features, but think of your coworkers.
- pjmlp 10y ago
  My coworkers are savvy enough to handle those features.
  - _ph_ 10y ago
    Then you are a very lucky person. For the rest of us, it is very good to have a manageable language at hand.
    - pjmlp 10y ago
      We can easily manage Java, C#, C++, Swift, Objective-C, JavaScript across our consulting projects....
      - _ph_ 10y ago
        Of course you can. None of those languages would be in use, if projects could not be managed at all. The question is: are you benefiting from their "features" or are you able to succeed despite of the challenges brought up to you because of those features and their complexity?
        pjmlp 10y ago
        It was the simplicity of Java 1.0 that lead to some of the famous patterns we see in some frameworks, that were initially created to workaround language limitations. The same path that is being followed by those that rely on libraries to reduce error handling boilerplate and go generate, just as two examples.