10 ms·

I have to wonder - when you're digging down into this level of complexity in order to discover issues with the language you're using, wouldn't something like C

• daenney 10y ago
  Better in what way? Performance wise, perhaps but that's only one aspect of why someone might pick one language over another. Even distilling better down to just the max throughput you can get for a solution in a language vs another is hard to do as a lot also depends on how the code ends up being written and how easy you want to be able to debug that solution. You can solve this stuff in C many ways with different performance characteristics.
• jjnoakes 10y ago
  At scale it may be more efficient to write the system in a higher level language (saving time) and then spending some time tuning only the slowest parts, instead of building everything from the start to be highly optimized, even the parts which may not need it (investing time where it may not produce results). And the improvements to Go that they drove will help everyone. I happen to prefer C, but I understand why they did it the way they did it.
• karma_vaccum123 10y ago
  Then we might be in some alternate reality talking about how Twitch could never deliver a viable service because the developers kept creating segfaults. C is the last language I would choose in a race to a viable service.
  • joejev 10y ago
    Too bad no one can deploy linux servers because of all the segfaults.
    • serge2k 10y ago
      I'm flabbergasted that people are able to post to this thread at all, what with all the segfaults their C++ based browsers must be experiencing all the time.
    • tracker1 10y ago
      I experienced quite a few kernel panics in the earlier days... Generally from poor drivers, but just the same.
  • coldtea 10y ago
    >C is the last language I would choose in a race to a viable service. And yet, the majority of services the world relies on everyday, from OSes and drivers, to Google search, NASA code, medical devices, etc are written in C/C++.
• weberc2 10y ago
  C is not a very nice language for concurrent programming.
• bkeroack 10y ago
  In some ways it's accurate to think of Go as a more convenient version of C with modern facilities like automatic memory management, concurrency primitives and data structures (i.e. maps), with the minimal level of runtime scaffolding included to support them. Interop with C is very easy, and Go is miles away (stylistically) from some of the more esoteric and abstract languages that are used these days.
  • jbooth 10y ago
    Interop with C is easy to code but deceptively expensive from a machine standpoint, due to correctness guarantees when you're switching from green threads to no-green-threads. It involves interacting with the go scheduler and possibly/probably blowing your cache and TLBs. And the automatic memory management is great, but the above commenter was saying that if you're going to extreme lengths to work around the automatic memory management, maybe you needed a non-GC language in the first place.
  • Keyframe 10y ago
    Which ones though? How about Rust? To me, as a C programmer, Go looked like the closest one to my taste, but not enough or blitz to switch/consider.
• topspin 10y ago
  Reading this causes me to experience déjà vu; years and years of reading stories and watching presentations about someone struggling with GC in the JVM. It's happening all over again with Go. The same 'discoveries', the same trade-offs, the same discussions about hardware resources, the same 'concurrent mark and sweep', the same 'more to do' conclusions. You could replace every occurrence of 'Go' with 'Java' and it would probably go undiscovered. Maybe it's all worth it and this is how developers are supposed to spend their time, but it's no longer interesting to me.
  • BinaryIdiot 10y ago
    I completely agree and with so much tuning required in past frameworks for their GC it makes me wonder why more don't simply adopt the C++ / Rust models of resource management. I remember way back when people said you couldn't use the JVM for real time applications because of the GC pauses but it's been improved significantly since then and now all the same topics are coming up with GO.
    • Skinney 10y ago
      Because the C++/Rust way of memory management is better for some things, but worse for others. I've worked with several different projects during my career, and not once did we require manual memory management. A GC based language was simpler for us to use, and the few times we had problems with GC, they were possible to overcome by writing better code, as is the case with any language. This is not to say that no project benefits heavily form C++/Rust. But I would argue that for many, GC is the best trade off.
      • BinaryIdiot 10y ago
        I'm not sure where you got manual memory management from. I was strictly referring to RAII. Manual memory management is such a pain but the C++ and Rust ways are very similar with RAII.
        • Skinney 10y ago
• zamalek 10y ago
  > wouldn't something like C be better? Jim is an intermediate-level coder, by and far the average guy that you are going to get. He writes his IRC server in C. It performs acceptably and can be scaled horizontally. There are a few threading bugs and exploits (buffer overflows etc.). Sally is an advanced coder, it took a year of recruitment to find her. She also writes her server in C. It's blazingly fast. Virtually nobody else understands how it works. She's a human, so it's still littered with the same types of bugs that Jim's server has. Jack is at the same level as Jim. He starts off in Go 1.4. While his server is nowhere as fast as Sally's, its much faster than Jim's. Race conditions and exploits tend toward zero. Everyone on the team can approach the code and maintain it. Go 1.6 is installed on prod and suddenly Jack's server is now negligibly slower than Sally's. Jim notices this and has to spend a few weeks on his to catch it up. Sally is stuck debugging a race condition that occurs once a month. Jack is adding more emoticons, more features and decommissioning servers in the cluster. Edit: IRC is a simple problem and that begets a simple solution. While C may be significantly simpler than C++, Go requires far less cognitive effort: it is actually simpler than C.
  • DanWaterworth 10y ago
    I find it hard to believe Sally is so advanced if she writes code that others have difficultly reading. It shouldn't take a year to find someone who writes unmaintainable soup.
    • kctess5 10y ago
      Correct, fast, and maintainable C code is a very tall order. Good luck finding ANYONE who can do that consistently for a reasonable paycheck.
      • DanWaterworth 10y ago
        Apparently it didn't have to be C or blazing fast.
      • vvanders 10y ago
        Huh, it's almost as if the foundation of all the devices we use on a daily basis are written in some language that apparently isn't possible to write correctly.
• anonymoushn 10y ago
  If you want to hire 300 people to write reliable software in a language they don't know yet, Go is a good choice. You might also have like half a dozen people who are so deep into Go that they do the stuff in this post.
  • coldtea 10y ago
    >Go is a good choice Until you ask them to do stuff with channels -- where Go offers 100s of subtle ways to shoot yourself in the foot.