Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go Is Not Good

yager.io

Post reply on HN
Print view View original

61–70 of 367 posts

Re: Why Go Is Not Good

#61

Post by MartinMond »

mustpax wrote: post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

Doesn't Go have a GC? How can you then "picture what the C equivalent would look like"?

Yes there are GCs for C, but is anyone successfully doing "systems programming" (whatever that may be) in C with GCs?

Re: Why Go Is Not Good

#62

Post by EpicEng »

wyager wrote: post #54
mustpax wrote: post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

>But, for systems programming, abstractions suck. Could you clarify what you mean by "systems programming"? To me, that means working with embedded systems, which Go is certainly not appropriate for.

Systems does not necessarily imply embedded. I work in systems and, as far as I am aware, the term simply means software which primarily services the hardware (as opposed to the user). Drivers, HW interfaces, anything which has to make assumptions about the underlying hardware it is running on/servicing.

Re: Why Go Is Not Good

#63

Post by Dewie »

mustpax wrote: post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

> These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen."

They also tell me "now you don't have to wait for the language designers or compiler writers in order to 'implement another feature'." Not that _I_ would necessarily be this "brilliant" guy that implements these features. Most likely I will just find some third party library that does it.

Re: Why Go Is Not Good

#64

Post by mustpax »

wyager wrote: post #54
mustpax wrote: post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

>But, for systems programming, abstractions suck. Could you clarify what you mean by "systems programming"? To me, that means working with embedded systems, which Go is certainly not appropriate for.

By systems programming I mean writing the code that applications and distributed systems run on top of. Raft (https://github.com/goraft/raft) and groupcache (https://github.com/golang/groupcache) come to mind as examples.

That's a good point though. A lot of people mean different things by systems programming.

Re: Why Go Is Not Good

#65

Post by woah »

xxchan wrote: post #16
pcwalton wrote: post #10

Earlier quoted context omitted.

> or risk having an unstable API like Rust did for a while there. Every language, including all the languages described in this article, goes through a period of instability while it figures out what works and what doesn't.

Sure, I'd just say that Go has been extremely stable since before 1.0 (~2 years). Author's point was that we should not use "not good" languages for the fear that we might be stuck with them for next 20 years. I'd rather be stuck with a language whose designers are very resistant to change vs one that gets features haphazardly bolted on every few years (PHP comes to mind).

Swatch internet time in PHP: http://www.php.net/manual/en/function.idate.php

Re: Why Go Is Not Good

#66

Post by mustpax »

MartinMond wrote: post #61
mustpax wrote: post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

Doesn't Go have a GC? How can you then "picture what the C equivalent would look like"? Yes there are GCs for C, but is anyone successfully doing "systems programming" (whatever that may be) in C with GCs?

That's true. It's not just GC actually. Slices and goroutines don't have a direct analogues in C either. But it is fairly easy to reason about the runtime complexity of these conveniences.

But like I said, if I didn't care about GC or concurrency, I'd be writing C.

Re: Why Go Is Not Good

#67

Post by woah »

zkirill wrote: post #14

Haskell (with third party library) http://snapframework.com/docs/tutorials/snap-api main :: IO () main = quickHttpServe site site :: Snap () site = ifTop (writeBS "hello world") route [ ("foo", writeBS "bar") , ("echo/:echoparam", echoHandler) ] dir "static" (serveDirectory ".") echoHandler :: Snap () echoHandler = do param ----- Rust (with third party library) https://github.com/chris-morgan/rust-http/blob/master/sr…

Node.js, native:

    var http = require('http');
    http.createServer(function (req, res) {
      res.writeHead(200, {'Content-Type': 'text/plain'});
      res.end('Hello World\n');
    }).listen(1337, '127.0.0.1');
What's the point here?

Re: Why Go Is Not Good

#68

Post by wyager »

mseepgood wrote: post #38

So he wants Haskell. Haskell already exists and has all the features he wants. He should have written his blog in Haskell, but he didn't, and I know why: because a language, which throws all these features together is no longer a practical language. He only sees the benefits of features, not the cost they introduce.

>He should have written his blog in Haskell, but he didn't, and I know why: because a language, which throws all these features together is no longer a practical language.

Actually, it's because I like Go's standard library HTTP server implementation!

I'm not claiming that Haskell or Rust are magic bullets, or that Go is useless. Far from it!

Re: Why Go Is Not Good

#69

Post by Mr_P »

mustpax wrote: post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

These two statements made me cringe:

> But, for systems programming, abstractions suck. They always, always have a cost.

> Generics? Here's another if statement, put it inside your for loop.

If you care about speed (and many systems programmers do), this is exactly the opposite of what you want to do. Unlike your proposal of putting potentially-costly if-statements inside of for loops, generics/templates in c++ provide zero-cost abstraction (in terms of execution time. If you think dealing with the error messages presents too high cost in terms of developer-time, switch to clang).

Re: Why Go Is Not Good

#70

Post by krakensden »

s_kilk wrote: post #3

This was a good read. Can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development? From my initial dabblings with the language, it feels like its constraints may not actually be a big deal in practice, and may even be more of a help than a hindrance in large projects. It would be nice to get some commentary from more experienced go users.

The generics thing turns out to not really be a problem. Yes, writing 100% Abstract Data Types is unsatisfying. However, when I'm actually writing custom data structures, I generally have an interface that I want to use because I want the data structure to take advantage of a peculiarity of the data being stored.

But, you know, bad for a teaching language.

Post reply on HN