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

81–90 of 367 posts

Re: Why Go Is Not Good

#81

Post by tinco »

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?

I don't agree with the GP, but if Go were very similar to C and the only big difference would be that C has no GC it would pretty easy to picture what the C equivalent of Go code would be. Exactly the same but with calls to `free()` at the end of some functions. (or preempted between instructions at unpredictable places)

Don't make GC's a bigger deal then they are. They are a tool to remove the need to call `free()` at the right time, with the downside that you don't get to control what the GC thinks is a right time instead.

Re: Why Go Is Not Good

#82

Post by Silhouette »

wyager wrote: post #31
xxchan wrote: post #16

Earlier quoted context omitted.

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).

>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). I absolutely agree! However, I don't think Rust will continue to go through wild changes for much longer. My guess is that it will settle and become pretty fixed. And Haskell certainly doesn't introduce breaking changes very often.

And Haskell certainly doesn't introduce breaking changes very often.

Actually, I'd say instability is one of the significant challenges with adopting Haskell for long-lived production code. For example, there have been a few discussions in various forums and blogs recently about how much of Real World Haskell no longer even compiles on the latest GHC and current versions of libraries. RWH is a book that rapidly became the go-to text for new Haskell developers only a few years ago, so we're not talking about either bleeding edge functionality or a length of time where software written back then has probably been retired here.

So stability is perhaps an area where Go does have an advantage over the likes of Rust and Haskell today. Rust is still evolving as a new language inevitably will; it has not yet reached the level of stability needed for long-term production use by the general programming community. Haskell is also still evolving, but for a different reason: it is valued as much for being a test bed of bleeding edge programming language design as it is for being a practical programming language.

Re: Why Go Is Not Good

#83

Post by wyager »

vorg wrote: post #76

I've recently tryed out Go for its Unicode integration. What I liked at first sight... * the indexing makes a map[something]boolean act like a set. Sets and maps are so similar it always felt wrong for them to be two separate constructs. * making exported functions/vars/etc begin with a capital letter. When naming important stuff, it's a relief not worrying about naming conflicts with keywords. When naming locals, ju…

>The correct solution is for people to implement languages like Haskell and Clojure in Go, making them execute as fast as possible.

Uh, what? Haskell already compiles to native code, and is faster than Go in many cases.

Also, if you were implementing a programming language, there are much better languages to do it in than Go.

Re: Why Go Is Not Good

#84

Post by andrejewski »

AndreasFrom wrote: post #55
andrejewski wrote: post #15

I am completely in support of Haskell and functional languages in general. There are some gaps in Go and definitely some glaring problems. But this comparison also only lists the bad. Go is good for what it was intended for which is concurrent programming and server/web application. Just a note: I don't think it is fair to say Go has absolutely no immutability as it was defined, it does have "const". See http://golan…

`const` is for compile-time constants where something like `let` in Rust can be used for values generated on the fly. The latter is immensely more powerful and actually provides the described benefits like guaranteeing that data is not changing under your feet. Edit: While `const PI = 3.1415…` is threadsafe, it's not very useful in comparison to runtime-immutability :)

Yes, the guarantees provided by true immutability are not met by "const". I wrote the note loosely using the author's expectations and advantages of immutability, not the exact definition. But thank you for letting me clarify.

Also I just noticed with Go's Unicode support we can write `const π = 3.14..` if we really wanted.

Re: Why Go Is Not Good

#85

Post by Silhouette »

pcwalton wrote: post #80
Silhouette wrote: post #78

Earlier quoted context omitted.

If Go has a slogan that slogan is "Frictionless Development". It's easily the simplest, least annoying, and most "get out of your way" language I've ever used. I suspect this is where many philosophical differences in these discussions originate. I appreciate the value of having quick and easy tools, but for production software where I care about quality, I don't want the language to get out of my way if I'm doing so…

I doubt that null pointers lead to security vulnerabilities. Panics, yes; worse performance, yes; vulnerabilities, unlikely. Null pointers are not dangling or wild pointers, which are the problematic ones.

I suppose that depends on how broadly you define a security vulnerability. Almost anything that can crash a process on a server -- either literally at OS level or figuratively by requiring something to reset itself before it can continue to do its job -- is probably a DoS attack waiting to happen. That might or might not be as dangerous as something like a remote root vulnerability, but I would argue that it is a serious security issue just the same.

(I'm sure it also goes without saying that having code that can crash with a the equivalent of a null pointer dereference is still highly undesirable in a public-facing web server, even if it doesn't actually risk things like data leakage/loss.)

Re: Why Go Is Not Good

#86

Post by dscrd »

wyager wrote: post #31
xxchan wrote: post #16

Earlier quoted context omitted.

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).

>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). I absolutely agree! However, I don't think Rust will continue to go through wild changes for much longer. My guess is that it will settle and become pretty fixed. And Haskell certainly doesn't introduce breaking changes very often.

>And Haskell certainly doesn't introduce breaking changes very often.

Perhaps Haskell the core language doesn't but ghc certainly does, in every major version.

Re: Why Go Is Not Good

#87

Post by pcwalton »

tinco wrote: post #81
MartinMond wrote: post #61

Earlier quoted context omitted.

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?

I don't agree with the GP, but if Go were very similar to C and the only big difference would be that C has no GC it would pretty easy to picture what the C equivalent of Go code would be. Exactly the same but with calls to `free()` at the end of some functions. (or preempted between instructions at unpredictable places) Don't make GC's a bigger deal then they are. They are a tool to remove the need to call `free()`…

There's also the overhead of the mark phase, which has to work out dynamically what could be worked out statically in a system with manual memory management. That's where much of the overhead of GC comes from.

Re: Why Go Is Not Good

#88

Post by jacquesm »

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?

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

Actually, yes. But it's hackish (relies on some pretty complex macros) and requires you to adapt certain conventions. Still, it's doable and a whole lot safer than managing your memory directly in terms of leaks and re-use after free. The cost to me really is that macro magic, that should not be required but it's the only thing I could think of to make this work. To give you an idea of just how ugly this is I re-defined 'return'. Any C hacker will be able to deduce the rest from that one hint ;)

On another note, I felt - and feel - that this was not the proper solution but the various policy choices made this pretty much the only way in which it could be done. And it works.

Re: Why Go Is Not Good

#89

Post by Dewie »

TheHydroImpulse wrote: post #79
Dewie wrote: post #44

Earlier quoted context omitted.

Maybe "unsafe" is being used to mean different things, here. Some may interpret it as to refer to unsafe memory access. Others may use it to mean possibility of crashing at run time (due to null pointer dereference).

Null pointer dereference is unsafe memory access.

Not if you just throw something like an exception when the program tries to do it instead of actually accessing that memory location.

Re: Why Go Is Not Good

#90

Post by twic »

mholt wrote: post #57
autodidakto wrote: post #47

Earlier quoted context omitted.

People use the word "complex" in different ways. Do you mean number of features? Do you mean the size of the compiler? By some measures, operator overloading adds complexity; By another measure, it add simplicity.

I use complexity here the same way the Go community does: it is whatever its authors and users consider it to be. So chances are, if it slows down compilation, it's complexity. If it adds significantly to the grammar or syntax or keyword list, it's complexity. If it does things that can already be done, just differently, it's complexity. If it makes code less clear, it's probably complexity. (You get the idea.)

> I use complexity here the same way the Go community does

To mean anything Go doesn't currently have?

Post reply on HN