10 ms·

>Sorry, but in what way is Go "revolutionizing"? By offering simplicity. Taking a step back to before C++. And providing a better C. C + strings + GC + map + s

• vvanders 10y ago
  > And providing a better C. I keep seeing this come up and I wonder if people have actually used C in the domains where it matters. Go is not a C replacement/better C. You don't have control over what goes on the stack/heap which means you can't control memory layout. If you can't do that you're throwing away one of the key reasons you'd use C. Memory layout is critical to getting that 10-50x performance that you can't get in a managed language. There's a bunch of domains where Go excels but if you're on constrained hardware where you really need the last bit of perf/memory it would not be the tool I reach for.
  • dragonwriter 10y ago
    > Go is not a C replacement/better C. Its not a replacement for C in most of the places where C is far and away the best existing choice for a whole project, it is a replacement for C in the zone where C's performance and static typing are attractive and would decided the choice in its favor, but Python's expressiveness, batteries-included stdlib, etc. also make it attractive and make it a little bit painful that the other factors weigh in C's favor. For a system that you might be otherwise do polyglot Python (or some similar dynamic language)/C development for that reason (or where you might do C-only somewhat reluctantly for that reason), Go could be a reasonable replacement for C (and, in the case where the alternative would be polyglot, Python or whatever else.)
    • vvanders 10y ago
      Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements. If you're not taking advantage of data locality then it's possible to approach C's performance in any of those languages. If your primary concern is performance(which is the only reason I'd reach for C today, esp w/ security concerns) then Go is not going to replace C in that domain.
      • dragonwriter 10y ago
        > Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements. Well, Swift certainly wasn't when Go was introduced, but, yes, Java and C# were competitors in that role when Go was introduced (Java, even moreso at the time, tended to fall short on expressiveness -- which some argue Go does too, though in different ways -- and C# was deeply tied to .NET, which only had a first-class implementation on Windows; both of those have improved somewhat since Go was introduced.)
      • johncolanduoni 10y ago
        Swift probably, but Java and C# still suffer in a lot of situations from the lack of good AOT compilation options. There are implementations for both, but they're incredibly primitive compared to the JIT reference implementations.
        • pjmlp 10y ago
          Not .NET Native, which uses the same backend as Visual C++.
          • johncolanduoni 10y ago
            Unfortunately .NET Native is still for UWP only, so for most places you'd use Go it's pretty useless. Microsoft appears to have no plans to even bring it to ASP.NET: https://github.com/aspnet/Home/issues/285 https://github.com/aspnet/Home/issues/285
            • 10y ago
  • weberc2 10y ago
    > You don't have control over what goes on the stack/heap You do have this control. There is escape analysis, but I've never had to dance with it to make it put things on the stack when I need them to. I can get very close to C speeds with Go without much effort.
    • vvanders 10y ago
      Can I say X is a value-type(or better annotate it in declaration)? If not then I don't have that control. Your compiler doesn't know your data access patterns, dataset size or a myriad of other factors that you need to tune if you really want to get full utilization from your hardware. To be clear I'm talking about ~5% of software out there, but when you need it you really need it.
      • _ph_ 10y ago
        Yes, the distinction between value and pointer types is explicit in the language, so you have all the control. This is, why you also have more control about the memory layout than in Java, which makes a huge difference in performance.
        • pjmlp 10y ago
          For the time being, until Java 10 gets released. But how things are going regarding Java releases, Go could even get generics before Java 10 gets released.
      • weberc2 10y ago
        Yes, it has value and pointer types, just like C (except without pointer arithmetic).
    • pcwalton 10y ago
      In that sense, Java and C# both have control too. There are lots of cases in which escape analysis falls down. In particular, higher order control flow (closures/interfaces) will always cause it to fail, until Go implements some sort of higher order control flow analysis (which I doubt it will). Go uses interfaces a lot.
  • pjmlp 10y ago
    If the constrained hardware is more powerful than a Xerox PARC Dorado (Mesa/Cedar), a ETHZ Ceres Workstation (Oberon), DEC Firefly (Modula-3), then Go is certainly a better C. Nothing prevents you to make use of statically allocated data structures, hands off from the GC if really needed. In spite of lacking a few features that I consider any modern language should have, ability to create memory friendly data structures isn't one them.
    • pcwalton 10y ago
      > Nothing prevents you to make use of statically allocated data structures, hands off from the GC if really needed. Only if you give up closures, interfaces, defer, strings, the entire standard library, and all sorts of other things that don't immediately come to mind. Programming without the GC in Go is technically possible, but impractical. The language just wasn't designed for that (and this isn't a knock against the language--it just was a non-goal).
      • pjmlp 10y ago
        I didn't say to not use the GC at all, rather to use it less. We can use the GC for the 90% of the code that isn't performance critical, enjoying the programming productivity of using a GC enabled language. After profiling the application and find out where those 10% performance/memory critical hotspots are, re-architect the data structures to use static allocation, either via the stack (compiling with escape analysis validation) or the global memory. Or even doing off-GC Heap allocation via syscalls. Then make use of pointers or array indexes to access the static allocated data. Plenty of examples in Modula-3, Oberon, Mesa/Cedar research papers. There are plenty of languages that I would rather use for systems programming instead of Go, but the language is certainly capable of being used in the same scenarios as Oberon. For example Astrobe, which sells bare metal Oberon compilers for ARM Cortex-M4, Cortex-M3 and Xilinx FPGA Systems. If anything, comparing Oberon's SYSTEM with Go's unsafe packages, Go could use a few more intrinsics like CPU register access, but those as also doable with a bit of Assembly help. Which ANSI C also doesn't support. My goal is just creating awareness that alternatives are possible, it doesn't need to be always C.
  • aws_ls 10y ago
    Just to make myself clear, on the point of 'providing a better C'. I just made that comment from language evolution point of view. And did not at all mean that Go is better than C, in all respects. I dare not say that. What I meant was taking a step back to a point before C++ was created. And looking ahead, and choosing what works and is essential (strings, GC,... and some modern Internet usage things...concurrency...etc), and getting rid of all the bloat, which actually comes in the way, especially the opinionated bloat on how software should be done e.g. OO. And making a language based on that. For some reason, this discussion reminds me of Linus Torvald's angry defense of using C, for git[1] :-) [1] http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
    • candiodari 10y ago
      How do you know this isn't just a new language thing ? All of the advantages you say always result from essentially any redesign, and they never last. A quote from "Java in a Nutshell", from (I believe, 2002): "Because Java is a simple and elegant language with a well-designed, intuitive set of APIs, programmers write better code with fewer bugs than for other platforms, again reducing development time." Reads pretty similar to your argument for Go. I remember similar quotes for Modula-2, ML, (a lot of versions of) LISP, C itself, and I'm sure there's many more. It seems to me pretty likely that we're seeing the same evolution : Go currently is a simple, easy language that matches the current hotness (microservices) pretty well, because it was directly written to support that. The current hotness will go away and Go will have effectively-mandatory bloated libraries to support the next hotness, just like today it's becoming close to embarassing to use Go's standard library's http server for anything non-trivial. Additionally, many of the criticisms of C apply to Go. It's looooooooooooooooooong simple code doing "a; if error { ... }; b; if error { ... }; c; if error { ... } ...". Many abstractions just don't work, and have to be "fixed" with crutches (like sorting, logging, ...)
      • aws_ls 10y ago
        Aah, Seeing such a good reply, so late. Does HN need notification? Probably not :-) So, I agree with you a lot. There are no guarantees that Go will remain good for ever. It would be a challenge and need effort on the part of the language developers. That said, I believe, when a language evolves over a period of 20 years. You get the benefit of hindsight to introduce the good things in a new language. So, Java's garbage collection is a big success. And Go developers incorporated it. Its a tradeoff with extreme (C like) performance, and devs went with convenience and security. Good call, in my opinion. But the object oriented part of Java, in my opinion, is just a C++ inheritance, as at that point of time (mid 1990s). OO was the silver bullet, to all your sofware spaghetti problems. But as it turns out, it got more complex, if the design/architecture was bad. And good engineers design good enough without the OO. So Go has taken that approach, which gels with me and lot other developers. Your comment regarding the error handling part. Yes, it is cumbersome. But surprisingly, it seems to look better than exception handling when you write couple of modules with it. And for some reason, which others have articulated better than I can at this time, your programs are more stable as a result. So overall what I like about Go, is the minimalist approach of just having the proven things which are good. And avoiding which are grey area or bad.
• coldtea 10y ago
  >By offering simplicity. Taking a step back to before C++. And providing a better C. C + strings + GC + map + slice(array) + json/xml parsing + http transport layer (server & client). What else do you need? Language consistency (no magical functions like "make" or magical items like slices), DRYness (generics), better type-safety than C (interface{} is the void * of the 21st century), would be a good start. Due to the mandatory GC, it's also not a C replacement where C is good at. Hence the backtrack on "systems", etc.
  • aws_ls 10y ago
    My question was more rhetorical. But thanks. After posting, I realized its concurrent programming model, is another thing which I (and many others) am a fan of. I found the channel and go based approach, much better compared to explicit spawning of threads in languages like Java and C++.
  • pjmlp 10y ago
    > Due to the mandatory GC, it's also not a C replacement where C is good at. Hence the backtrack on "systems", etc. I tend to complain on Go's design decisions and don't have any actual use for it, but given my experience with Oberon, I do believe there are use cases where it would be possible to use Go as systems language. For sure not in when targeting 8 or 16 bit CPUs with a few KBs, or timing constraints that cannot deal with possible GC pauses. But for more beefy micro-computers like the original PI, it can certainly be an option. This would a good starting point for anyone trying to attempt it http://wiki.osdev.org/Go_Bare_Bones http://wiki.osdev.org/Go_Bare_Bones Also I consider the ability to write compilers to be systems programming use cases and Go is already bootstrapped. Having said this, yes there are better options to do systems programming with less need of Assembly help.