8 ms·

I think there is a better explanation for why people dislike Go. All programming languages currently used for the web have gigantic downsides. They're slow. The

• fooster 11y ago
  > A web service is not a device driver where every edge case has to be carefully considered. Bailing out with an exception is fine. Go disagrees. If all you want is a bail out mechanism then panic.
• sievebrain 11y ago
  "All" languages used for the web have those downsides? This is part of why Go culture scares me a bit. You seem to be overlooking the huge amounts of software written in .NET and on the JVM, none of which suffers from the problems you just outlined: there are great IDEs, decent type systems, good interactive debuggers, strong standard libraries, reasonable package management etc. This mental blind spot towards the tools and practices that a massive part of the software industry has been using for years is really odd.
  • gizmo 11y ago
    I deliberately didn't mention specific programming languages because I knew that would lead to bickering about the relative merits of Python vs Java vs .NET vs Clojure, which would just distract from the greater point. Your curious assertion that I'm somehow part of "Go culture" only confirms this. I think we can do a lot better than .NET or Java. .NET isn't even cross platform and Java has a lot of legacy cruft. Not to mention both platforms are pretty bloated and not even designed with the modern web in mind.
    • sakopov 11y ago
      So much bias in this thread in general. Have you missed the news on .Net Core?
    • talles 11y ago
      A sample from the newer stuff in the .NET world: http://nancyfx.org http://nancyfx.org How modern is that for you?
      • gizmo 11y ago
        Same old same old? If you think nancyfx represents a leap forward I don't know what to say.
        • sievebrain 11y ago
          It's not clear what you would accept as a good language for the web. Could you elaborate?
        • talles 11y ago
          Comparing to the old ASP.NET web sites with "view states" and "user controls"? Sounds like leaving behind the "legacy cruft" you talk about to me.
  • cballard 11y ago
    "Decent" is being very kind to any language that has a type system where every reference type is implicitly a Maybe (okay, Scala exists).
• bsaul 11y ago
  I can really relate to your post. I heard about go at a time when i was angry against python for having no type hinting and started to see people build tools parsing types in code comments, and at the same time being furious against the gigantic bloat that the java enterprise web frameworks had become. So, as you said, when i looked at go being a smart and small with a modern standard lib, and being modern in a way with its approach to interface programming i thought i would fall in love with it. Then i saw go didn't have a single generic function for comparing two numbers, because the language wasn't generic enough, and i felt hugely disappointed.
  • infogulch 11y ago
    Why would you even want that? I mean, I've heard the generics argument before, and I'll accept that they are important for some applications (esp custom data structures). But lack of a generic `Cmp` is the straw that broke the camel's back?
  • sievebrain 11y ago
    If you avoid Spring, you can find some pretty nice and straightforward web frameworks in the Java space. The reason they often seem bloated is simply because they've been around a long time and so have accumulated many features. If you want something similar to the Go standard library HTTP server, there is this one that comes with the JDK out of the box. Most people don't know it's there though, as technically it's not a part of the Java platform, it's just something that comes bundled with the standard JDK: https://docs.oracle.com/javase/8/docs/jre/api/net/httpserver/spec/com/sun/net/httpserver/HttpServer.html https://docs.oracle.com/javase/8/docs/jre/api/net/httpserver... If you're building a serious app you will want support for more advanced stuff. That's when you can upgrade either to a better HTTP server like Jetty, or to a full web framework that bundles templating, authentication, database access, session management and all the rest. Play! Framework is quite well known. It ignores all the standard enterprise Java conventions in order to be a lot more opinionated. If you like their opinions, that sort of approach can be way lighter.
• innocentoldguy 11y ago
  Elixir is fast, has good package management, has a good standard library, exceptions are easy to read and debug, etc. Elixir doesn't have static typing, but it is functional, so it doesn't really matter as long as your initial assignment is correct. I can't really comment on IDE integration, since I never use anything but Vim. Maybe the static typing and IDE support are enough to make Go awesome for some, but they don't really matter to me as much as concurrency, hot-plug code deployments, the actor model, and stability.
  • phieromnimon 11y ago
    Elixir has optional typespecs that can be statically analyzed with a tool called dialyzer: http://learnyousomeerlang.com/dialyzer http://learnyousomeerlang.com/dialyzer
  • deleted 11y ago
    [deleted]
  • deleted 11y ago
    [deleted]
  • deleted 11y ago
    [deleted]
• dozzie 11y ago
  > Then Google announces Go. A cross-platform systems programming languages for high quality web services. Did they actually advertise it as a language for web services? I thought it was designed for command line tools mostly, not for serving HTTP/HTML.
  • gizmo 11y ago
    Looks like you're right. This is the original announcement: http://google-opensource.blogspot.com/2009/11/hey-ho-lets-go.html#links http://google-opensource.blogspot.com/2009/11/hey-ho-lets-go...
  • SyneRyder 11y ago
    The first version of the Golang web site doesn't mention the web: "A systems programming language: expressive, concurrent, garbage-collected." However one of the first programming examples on the Effective Go page is a web server. https://web.archive.org/web/20091112094121/http://golang.org/ https://web.archive.org/web/20091112094121/http://golang.org...
  • techiferous 11y ago
    I came here to say this. It's not fair to criticize Go as not optimal for web services if it wasn't designed to be optimal for web services.
• jb613 11y ago
  "The lack of exceptions makes writing correct code really tedious." Tedious up front often translates into time saved down the road. Exceptions are often an easy way out while accruing future debt. Unfortunately, our industry cannot easily measure the time saved down the road and so cannot properly value it. However, many with long term interests in a project will often spend on the "tedious" costs up front to avoid potential future costs.
  • pacala 11y ago
    > Exceptions are often an easy way out while accruing future debt. Is there perhaps a concrete illustration on how using exceptions causes technical debt, especially in a GCed language like Go?
    • spyspy 11y ago
      The advantage with go is that errors have to be handled right away by the thing that may have caused it. The is versus, say a try/except with a dozen lines of code in the try, and then something like `except KeyError: pass`. You may have no idea which line caused the error or why it did so.
      • mononcqc 11y ago
        The general principles for fault tolerance require Separation of Concerns vis. Error Encapsulation (make sure that the contagion doesn't spread), Fault Detection (make sure that you know that someone is infected), and Fault Identification (you have ebola!). Error encapsulation (and this applies equally to modules, components, systems, architectures, organizations) is invariably best done at the lowest level possible, which invariably breaks #3 and #4 (fault detection and identification). what if you have different classes of exception handling mechanisms available for each of these cases? What about languages that may support exceptions, option types, tagged values, multiple return values, signals, continuations and/or whatever mix of them that exists? The problem with handling everything right away is that it lacks flexibility to handle things in what could be the optimal manner. "One true form of exception handling", to me, sounds as reductionist of an approach as "one true form of concurrency", "one true programming language paradigm", or whatever. Treating all error conditions / exceptions with the same mechanism will generally ensure that you pick similar stances on encapsulation vs. detection and identification for all error conditions / exceptions, unless you decide to be extra careful about all of that. Using multiple mechanisms will allow you to pick, case by case, which one you feel is worth breaking depending on the nature of the fault and what your specific application or system requires. I feel Go is doing a pretty bad job at this.
• zippoxer 11y ago
  A web service has to consider errors more carefully than you might think.
• EdiX 11y ago
  > The lack of exceptions makes writing correct code really tedious Go does have exceptions.
• fixermark 11y ago
  > A web service is not a device driver where every edge case has to be carefully considered. Yikes, that's an assumption that is going to bite you hard in your career. I recommend escaping it as soon as possible. ;) The web is full of horror stories from people who assumed their part of a web-accessible product wasn't on a critical security / safety / reliability path. I used to use Python and Ruby on Rails for web services; this is precisely why I left them. I got tired of dealing with typos becoming runtime exceptions. > Bailing out with an exception is fine. Go disagrees. Go makes it trivial to bail out with an exception: You panic. But panic is reserved for real exceptions, not common and expectable situations (like "file not found") and its defaults are therefore set to crash the whole process (which is fine if you're doing microservices and therefore can handle failures by crashing and restarting). I find other languages treat exceptions as not sufficiently exceptional.
  • fidz 11y ago
    > I used to use Python and Ruby on Rails for web services; this is precisely why I left them. I got tired of dealing with typos becoming runtime exceptions. That is why you must do 100% code coverage on all non-compiled language.