4 ms·

> I'm becoming increasingly aware of how desperately the Java ecosystem needs genuine competition Do you mind expounding on that? Is Java that much of a major

by copperx 10y ago

> I'm becoming increasingly aware of how desperately the Java ecosystem needs genuine competition Do you mind expounding on that? Is Java that much of a major player on the backend? I didn't think so; especially for new startups.

KirinDave 10y ago
> Is Java that much of a major player on the backend? I didn't think so; especially for new startups. ... Yes? Clojure and Scala are quite popular and normal. Java itself is still extremely common. Even if you end up writing your API endpoint in Node or Go, odds are you'll still end up using sidecar infrastructure that's written or maintained in Java. The competitors are: - Node, which simply has a hard time scaling. This gets better every year, but it is sort of in the "you do this and then commit to a larger capex" category along with Python. You can do it and many do. - Go. Go is a funny language. It's quite good for small projects, but completely fails to scale for large projects due to issues with error handling. - Rust. I don't think this sees wide adoption in the startup space yet, though. - Nim. At least as cool as rust, but even more neglected. - Haskell & OCaml: Lots of TALK but not many actual shipped products use this stack. Some pretty impressive groups do though. Just my opinion though.
- jsmith0295 10y ago
  I'd have to disagree with Go not scaling for large projects. A primary goal of it's design was to be good for large projects, and there's plenty of large and/or complex codebases that have been written in Go. Docker, Kubernetes, and a lot of things in the CoreOS ecosystem specifically.
  - KirinDave 10y ago
    The error handing is terrible and it's well known it's a problem. It's a really bad situation. It's not to say you can't do anything with the language, just that you need to really understand the tools and strategies that mitigate the deficiencies and be prepared from day 1 to exercise them, or your project is in for growing pains. What's more, I do not think the community has "solved" for those strategies. I know google internally has one set of guidelines, but other teams and orgs do other stuff. Quite frankly, there are many aspects of its design that ended up being sub-optimal for large codebases. Look at the profound about-face the language took on bundling as an example. We can bandy about all we want about this, but uh... certainly as a longtime user of Kubernetes I can say, "They have found ways to deal with the language's error handling."
    - jsmith0295 10y ago
      The lack of a good debugger is something that sort of scares me personally. From what I've read it seems like you can sort of use GDB, and there's some experimental tools, which doesn't sound nearly as good as what you can get out of something even as new as Swift.
  - jacques_chester 10y ago
    I dislike Go intensely, but nothing else currently fits its niche as well. For a large or complex codebase, I nominate Cloud Foundry. About 1.5M SLOC of Go (1.8M LOC) in the main cloudfoundry repos[0]. Almost all new development is in Go. There's still about 370KSLOC (470K LOC) of Ruby. Eventually most of it will be replaced, which will drive that Go codebase up a lot. Disclosure: I work for Pivotal. Lots of my colleagues wrote most of that Go. I for one pity them, but they seem to have enjoyed it. [0] https://www.openhub.net/p/cloudfoundry https://www.openhub.net/p/cloudfoundry
    - voltagex_ 10y ago
      What do you dislike about Go?
- bcit-cst 10y ago
  I think ruby/rails are right there after java.
  - KirinDave 10y ago
    I will never voluntarily allow Ruby into any stack I control or work on ever again.
    - mastazi 10y ago
      One of our systems is based on Ruby/Rails. There are things that I like about it but in general I think there are better alternatives. Pros: * Code readability * Concise syntax Cons: * Ruby doesn't perform as well as many other languages. * There is a cultural tendency among Rails devs to rely on a large number of gems. This creates dependency hell, especially a few years down the line when some libraries are not actively maintained. * Unicorn is not the easiest server to manage. However I have to admit that I haven't tried any alternative, there might be better servers in the Ruby world.
      - lawnchair_larry 10y ago
        You accidentally put "readability" in the Pros column, fyi.
    - copperx 10y ago
      I would love to hear why. Also, which stack/language would you choose? Rails left a bad taste on my mouth after using it for one project. Many things about Rails are wonderful, but it feels like the entire project is in shaky ground with so many dependencies. Memory usage and performance aren't nice either. Python sounds tempting, but I want to avoid dynamic typing if possible. That rules out Node (not that I would like to work with js). That leaves me with either Java and .NET, which have the taboo of being enterprisey. Are those the only major players?
      - KirinDave 10y ago
        These are just my opinions. I tend to state them forcefully, but they're not really anything but my idea. I don't like Ruby because it hits a sour spot for me. It used to be very cutting edge, but then stagnated. It has all the problems of a dynamic language, but nothing to really offset it. Its tooling is fairly good for assembling new projects, but not maintaining them. I think if I went somewhere today, on the spot. 1. FSharp & C#. The .NET Core stuff is exciting. I view, "enterprisey" is just, "I have libraries for lots of things I don't want to solve like calendaring." So long as I can quickly develop and deploy code, those kind of social things are immaterial. People worry about .NET core performance even as they ship Node code, so I find that concern somewhat manufactured. 2. OCaml, in the same vein as F#, but I think this lacks a lot of ecosystem stuff so I suspect it will always be secondary. 3. Go or Rust. I could just bite the bullet and do it. It's doable, it just requires a lot of thought.
- tracker1 10y ago
  Node scales pretty well in my experience, out of the box performance on a single instance is pretty good... The down side is you need to factor in scaling sooner, as running multi-process takes some of the same techniques as scaling mutli-server... It just means if you need a scalable app, that you need to bring those bits in sooner, as opposed to starting off with single-server in mind... Of course, as I said single instance runs very well.

by copperx 10y ago

KirinDave 10y ago

> Is Java that much of a major player on the backend? I didn't think so; especially for new startups. ... Yes? Clojure and Scala are quite popular and normal. Java itself is still extremely common. Even if you end up writing your API endpoint in Node or Go, odds are you'll still end up using sidecar infrastructure that's written or maintained in Java. The competitors are: - Node, which simply has a hard time scaling. This gets better every year, but it is sort of in the "you do this and then commit to a larger capex" category along with Python. You can do it and many do. - Go. Go is a funny language. It's quite good for small projects, but completely fails to scale for large projects due to issues with error handling. - Rust. I don't think this sees wide adoption in the startup space yet, though. - Nim. At least as cool as rust, but even more neglected. - Haskell & OCaml: Lots of TALK but not many actual shipped products use this stack. Some pretty impressive groups do though. Just my opinion though.

jsmith0295 10y ago
I'd have to disagree with Go not scaling for large projects. A primary goal of it's design was to be good for large projects, and there's plenty of large and/or complex codebases that have been written in Go. Docker, Kubernetes, and a lot of things in the CoreOS ecosystem specifically.
- KirinDave 10y ago
  The error handing is terrible and it's well known it's a problem. It's a really bad situation. It's not to say you can't do anything with the language, just that you need to really understand the tools and strategies that mitigate the deficiencies and be prepared from day 1 to exercise them, or your project is in for growing pains. What's more, I do not think the community has "solved" for those strategies. I know google internally has one set of guidelines, but other teams and orgs do other stuff. Quite frankly, there are many aspects of its design that ended up being sub-optimal for large codebases. Look at the profound about-face the language took on bundling as an example. We can bandy about all we want about this, but uh... certainly as a longtime user of Kubernetes I can say, "They have found ways to deal with the language's error handling."
  - jsmith0295 10y ago
    The lack of a good debugger is something that sort of scares me personally. From what I've read it seems like you can sort of use GDB, and there's some experimental tools, which doesn't sound nearly as good as what you can get out of something even as new as Swift.
- jacques_chester 10y ago
  I dislike Go intensely, but nothing else currently fits its niche as well. For a large or complex codebase, I nominate Cloud Foundry. About 1.5M SLOC of Go (1.8M LOC) in the main cloudfoundry repos[0]. Almost all new development is in Go. There's still about 370KSLOC (470K LOC) of Ruby. Eventually most of it will be replaced, which will drive that Go codebase up a lot. Disclosure: I work for Pivotal. Lots of my colleagues wrote most of that Go. I for one pity them, but they seem to have enjoyed it. [0] https://www.openhub.net/p/cloudfoundry https://www.openhub.net/p/cloudfoundry
  - voltagex_ 10y ago
    What do you dislike about Go?
bcit-cst 10y ago
I think ruby/rails are right there after java.
- KirinDave 10y ago
  I will never voluntarily allow Ruby into any stack I control or work on ever again.
  - mastazi 10y ago
    One of our systems is based on Ruby/Rails. There are things that I like about it but in general I think there are better alternatives. Pros: * Code readability * Concise syntax Cons: * Ruby doesn't perform as well as many other languages. * There is a cultural tendency among Rails devs to rely on a large number of gems. This creates dependency hell, especially a few years down the line when some libraries are not actively maintained. * Unicorn is not the easiest server to manage. However I have to admit that I haven't tried any alternative, there might be better servers in the Ruby world.
    - lawnchair_larry 10y ago
      You accidentally put "readability" in the Pros column, fyi.
  - copperx 10y ago
    I would love to hear why. Also, which stack/language would you choose? Rails left a bad taste on my mouth after using it for one project. Many things about Rails are wonderful, but it feels like the entire project is in shaky ground with so many dependencies. Memory usage and performance aren't nice either. Python sounds tempting, but I want to avoid dynamic typing if possible. That rules out Node (not that I would like to work with js). That leaves me with either Java and .NET, which have the taboo of being enterprisey. Are those the only major players?
    - KirinDave 10y ago
      These are just my opinions. I tend to state them forcefully, but they're not really anything but my idea. I don't like Ruby because it hits a sour spot for me. It used to be very cutting edge, but then stagnated. It has all the problems of a dynamic language, but nothing to really offset it. Its tooling is fairly good for assembling new projects, but not maintaining them. I think if I went somewhere today, on the spot. 1. FSharp & C#. The .NET Core stuff is exciting. I view, "enterprisey" is just, "I have libraries for lots of things I don't want to solve like calendaring." So long as I can quickly develop and deploy code, those kind of social things are immaterial. People worry about .NET core performance even as they ship Node code, so I find that concern somewhat manufactured. 2. OCaml, in the same vein as F#, but I think this lacks a lot of ecosystem stuff so I suspect it will always be secondary. 3. Go or Rust. I could just bite the bullet and do it. It's doable, it just requires a lot of thought.
tracker1 10y ago
Node scales pretty well in my experience, out of the box performance on a single instance is pretty good... The down side is you need to factor in scaling sooner, as running multi-process takes some of the same techniques as scaling mutli-server... It just means if you need a scalable app, that you need to bring those bits in sooner, as opposed to starting off with single-server in mind... Of course, as I said single instance runs very well.