Why Go Is Not Good • Hacker News Board

Re: Why Go Is Not Good

#181

Post by Ygg2 » Mon, Jun 30, 2014, 4:00 AM UTC

cantankerous wrote: post #175

pcwalton wrote: post #124

Earlier quoted context omitted.

Again, what specifically? I ask because this has not been my experience writing several hundreds of thousands of lines of Rust code, nor has this been the experience of anyone I have helped get up to speed. Moreover, I believe there is no feature in Rust that is not necessary to achieve safety without sacrificing performance.

Hundreds of thousands of lines of Rust? Out of curiosity, what kind of software are you writing in Rust? ... And can I get in on some of that? ;-)

> Hundreds of thousands of lines of Rust

Just a very concurrent browser engine ;) One that does everything in parallel. Basically every task that can be parallelized becomes parallel (rendering, JS execution, CSS matcher, etc.).

Also you can, there is Github for Servo (said parallel browser engine project by Mozilla).

https://github.com/mozilla/servo/wiki/Design

Re: Why Go Is Not Good

#182

Post by dbaupp » Mon, Jun 30, 2014, 4:03 AM UTC

cantankerous wrote: post #175

pcwalton wrote: post #124

Earlier quoted context omitted.

Again, what specifically? I ask because this has not been my experience writing several hundreds of thousands of lines of Rust code, nor has this been the experience of anyone I have helped get up to speed. Moreover, I believe there is no feature in Rust that is not necessary to achieve safety without sacrificing performance.

Hundreds of thousands of lines of Rust? Out of curiosity, what kind of software are you writing in Rust? ... And can I get in on some of that? ;-)

The compiler and Mozilla's experimental rending engine Servo:

- https://github.com/rust-lang/rust/

- https://github.com/mozilla/servo/

(The 'contributors' graphs suggest that pcwalton has added/removed more than 1 million lines of code in those two repos combined.)

Re: Why Go Is Not Good

#183

Post by oscargrouch » Mon, Jun 30, 2014, 4:07 AM UTC

codygman wrote: post #169

oscargrouch wrote: post #6

Go, Rust, Haskell, come from diffent ways of thinking about how to solve problems using programming languages.. Go aims to be more simple and concise, in the end you write less code to do the same thing, as you would in C++, Haskell or Rust.. because those 3 languages decided to "cover everything" and are worried about other things, creating more burden to the programmer, but with something else to gain Go is more of…

You made the claim that "in the end you write less code to do the same thing, as you would in C++, Haskell or Rust". Can you provide any examples where the Haskell equivalent isn't more concise than the Go equivalent? As a data point, here are links to the Haskell and Go implementations of the TechEmpower benchmarks: Haskell (78 sloc) https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... Go (164 sloc) https…

Anyone can encapsulate or "hide" the inner workings so the resulting code will look small.. how much of that code in the frontend is already implemented in the standard library of each language??

To see the reality of it.. a better example would be something without any support library...

Cherry picking is easy..

From the same benchmarks Game:

spectral-norm - Go

http://benchmarksgame.alioth.debian.org/u64/program.php?test...

spectral-norm - Haskell

http://benchmarksgame.alioth.debian.org/u64/program.php?test...

Re: Why Go Is Not Good

#184

Post by Peaker » Mon, Jun 30, 2014, 4:10 AM UTC

Dewie wrote: post #89

TheHydroImpulse wrote: post #79

Earlier quoted context omitted.

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.

Programs that crash with null pointer dereferences are not very useful.

Considering that "safe" removes most of the usefulness of the word "safe".

Re: Why Go Is Not Good

#185

Post by asattarmd » Mon, Jun 30, 2014, 4:14 AM UTC

cantankerous wrote: post #175

pcwalton wrote: post #124

Earlier quoted context omitted.

Again, what specifically? I ask because this has not been my experience writing several hundreds of thousands of lines of Rust code, nor has this been the experience of anyone I have helped get up to speed. Moreover, I believe there is no feature in Rust that is not necessary to achieve safety without sacrificing performance.

Hundreds of thousands of lines of Rust? Out of curiosity, what kind of software are you writing in Rust? ... And can I get in on some of that? ;-)

The Rust compiler :) He is part of the Rust team and writes Servo.

Re: Why Go Is Not Good

#187

Post by Peaker » Mon, Jun 30, 2014, 4:17 AM UTC

eloff wrote: post #122

dbaupp wrote: post #116

Earlier quoted context omitted.

That map only works with keys and values both being int32, right?

Correct. I have to duplicate much of the code for in64 keys and values, the lack of generics hurts there.

You seem to be brushing this off as a minor nuisance, when in many cases it is a showstopper.

Need it for floats, duplicate it again.

This is a solved problem -- the fact Go doesn't have the solution reflects very poorly on Go.

Re: Why Go Is Not Good

#188

Post by axman6 » Mon, Jun 30, 2014, 4:19 AM UTC

personZ wrote: post #145

We've seen this same article re-written countless ways. Seriously, this is (intentionally or not) a rewording of every existing criticism of Go, by people who complain that it isn't a language that it isn't. No, Go's solution to generics is not interface{}. The moment you say that, you have lost . You are trying to fight Go and make it a language that it is not. Always remarkable that such critiques always focus on t…

Haskell makes Go's concurrency and composition look primitive and restrictive while also giving you safer code with generics. This isn't an area that Go wins at unless you're comparing it with C, not anything modern. The lack of generics is also not a primitive issue, neither is the ease at which people can write unsafe code. You can write as unsafe code as you like in Haskell, but the pat5h of least resistance also happens to be the safest. this is my biggest issue with go; it insists on using unsafe ideas when it's simply not necessary and puts unnecessary burden on the programmer to ensure things are safe; computers exists to make lives easier, and Go ignores that

Re: Why Go Is Not Good

#189

Post by Peaker » Mon, Jun 30, 2014, 4:24 AM UTC

Laremere wrote: post #179

jeremyjh wrote: post #158

Earlier quoted context omitted.

Since concurrency and composition are important, why doesn't Go have support for immutable variables and monitoring/linking ? These are features proven to make it easier to reason about concurrent systems and to manage failures in a distributed system. From what I can tell it is completely impossible to implement supervisors in Go.

Immutable values will complicate a type system and implementation. The Go creators are very strict about adding features to the language without enough justification, which is one of the biggest features of the language imo. There are more synchronization features than channels in Go. Channels and switches solve most problems very well. However when another synchronization method is just simply required, check out: h…

Refusing to complicate the language is nice, unless it means complicating or making every program in that language less safe.

Repeatedly, Go chooses the latter, and many people hail it while writing programs that crash on nil dereferences or duplicate their code for various basic types.

Re: Why Go Is Not Good

#190

Post by richo » Mon, Jun 30, 2014, 4:27 AM UTC

jjnoakes wrote: post #166

richo wrote: post #147

Earlier quoted context omitted.

that's what mapping an -rwx page at 0x0 does, and as a result it segfaults, which is an access violation.

No, you are wrong. First, mapping that page doesn't cause all null pointer dereferences to segfault. And second, the language doesn't require a segfault. In fact, it explicitly permits the implementation to do whatever it likes. That is the difference between safe and unsafe. It is in the language definition.

"The language" ?

C doesn't define behaviour of a null deref, but most compilers map a -rwx page there to ensure that attempts to deref fault.

In what circumstance do they not?