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

Simplicity and the ideas Go left behind

sourcegraph.com

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Simplicity and the ideas Go left behind

#71

Post by lmm »

SixSigma wrote: post #68
lmm wrote: post #60

Earlier quoted context omitted.

Static binaries are bad design as soon as a library has a security flaw. Remember when there was a double free in zlib and Apple had to release a 1.3GB patch to update everything that linked it in statically - and even that only fixed the problem for Apple-official programs, not for anything the user had installed?

recompiling all of plan9 takes about 15 minutes

Well yeah, but plan9 has so little code because it doesn't really do anything. Recompiling any consumer-grade system takes much longer.

Re: Simplicity and the ideas Go left behind

#72

Post by rakoo »

kmontrose wrote: post #9

This oversells golang's simplicity I think. Not a lot, but enough to rub me the wrong way a tiny bit. --- > Go programs are built from just their source, which includes all the information needed to fully build the program. Still have to deal with GOPATH, vendor your dependencies, and have everything a `go generate` comment wants to invoke. It's certainly better than makefiles, but it's hardly just the source. > C# i…

> Still have to deal with GOPATH

Once, when you install Go.

Then for each project, put your stuff where you want and symlink from $GOPATH to where it is. Once per project.

There really is minimum hassle to integrate the recommended flow.

Re: Simplicity and the ideas Go left behind

#73

Post by codygman »

Padding wrote: post #61
Daishiman wrote: post #12

This answer is slightly infuriating: > Q: Lack of generic collection classes like in Java’s Guava library?A: For 90% of cases, slices and maps do what you need. For the other 10%, you might consider whether your package should own the logic of those special containers, instead of using an external package. I read this as: "We're not willing to put in the hard work on thinking of a decent generics implementation, desp…

> despite decades of working solutions Which "working" solutions? Has anyone solved creating a type system that offers OO/inheritance, generics, mutability and isn't mind-bogglingly complex? What is your definition for a "working" solution? I don't think any of the current languages we have fit this description, since all of them are capable of producing type errors that are way too complex to comprehend. > with a my…

> Which "working" solutions? Has anyone solved creating a type system that offers OO/inheritance, generics, mutability and isn't mind-bogglingly complex?

Pretty sure OCaml would match your definition of "not mind-bogglingly complex" as well as "type system that offers OO/inheritance, generics, mutability".

Re: Simplicity and the ideas Go left behind

#74

Post by rakoo »

qznc wrote: post #43

I'd argue that in most cases "easy > simple" with the definitions of Rich Hickey. Easy means you understand it quickly. Simple means it uses few concepts. Go doesn't want to use the concept of generics. However, if your code uses "List " instead of "List", it is easier to understand, because it additionally tells you it is about IPs. Python is a language which tries to be easy by resembling pseudo code. If you really…

> Go doesn't want to use the concept of generics.

How many times do we have to read this... It's not that Go doesn't want to use generics, it's that the use of generics doesn't come for free.

For generics to be introduced, the gain have to overcome the costs. It seems we're not there yet (I'll be honest, I didn't follow all the arguments closely)

Re: Simplicity and the ideas Go left behind

#75

Post by NateDad »

rakoo wrote: post #72
kmontrose wrote: post #9

This oversells golang's simplicity I think. Not a lot, but enough to rub me the wrong way a tiny bit. --- > Go programs are built from just their source, which includes all the information needed to fully build the program. Still have to deal with GOPATH, vendor your dependencies, and have everything a `go generate` comment wants to invoke. It's certainly better than makefiles, but it's hardly just the source. > C# i…

> Still have to deal with GOPATH Once , when you install Go. Then for each project, put your stuff where you want and symlink from $GOPATH to where it is. Once per project. There really is minimum hassle to integrate the recommended flow.

note that symlinking is not actually the recommended flow ;) Just put everything in gopath.... I even put non-go code in my gopath... it's just a nice way to organize - by the VCS url.

Re: Simplicity and the ideas Go left behind

#76

Post by NateDad »

bsder wrote: post #11
kmontrose wrote: post #9

This oversells golang's simplicity I think. Not a lot, but enough to rub me the wrong way a tiny bit. --- > Go programs are built from just their source, which includes all the information needed to fully build the program. Still have to deal with GOPATH, vendor your dependencies, and have everything a `go generate` comment wants to invoke. It's certainly better than makefiles, but it's hardly just the source. > C# i…

I like the fact that the Go guys continue to avoid talking in detail about Rust and Clojure. That tells me that the don't think they can win the comparison.

The core goals behind Rust and Clojure are very different from those behind Go. This article/presentation would not be appropriate for those languages. I don't think anyone would say that Rust or Clojure are simple languages, or that simplicity is a core goal for them. Rust's core goals are performance, memory safety, and lack of race conditions (AFAICT). And clojure is a LISP which puts it in its own category, really.

It's like saying a jeep can't compare to a ferrari or a minivan - other than having 4 wheels, they're really not at all designed to do the same kinds of things... Sure, maybe driving to the corner store they're all pretty much the same, but which do you want in 8" of mud? Which do you want in a car chase on the highway? Which do you want to bring your 4 kids to soccer practice?

Re: Simplicity and the ideas Go left behind

#78

Post by kazagistar »

masklinn wrote: post #53
qznc wrote: post #43

I'd argue that in most cases "easy > simple" with the definitions of Rich Hickey. Easy means you understand it quickly. Simple means it uses few concepts. Go doesn't want to use the concept of generics. However, if your code uses "List " instead of "List", it is easier to understand, because it additionally tells you it is about IPs. Python is a language which tries to be easy by resembling pseudo code. If you really…

> If you really want simple, you could as well use SML, TCL, or Lua. And if you truly want simple, you use Smalltalk, Scheme or Forth.

I dunno about smalltalk, but Scheme and Forth start off simple until a programmer writes tens of thousands of lines of code, at which point it gets harder to read and follow the code exactly.

Re: Simplicity and the ideas Go left behind

#79

Post by justincormack »

SixSigma wrote: post #67
SixSigma wrote: post #57

Earlier quoted context omitted.

That is worlds apart.

OpenBSD's ktrace is similar 31144 date CALL readlink(0x3c001c16,0xcfbe7048,0x3f) 31144 date NAMI "/etc/malloc.conf" 31144 date RET readlink -1 errno 2 No such file or directory 31144 date CALL open(0x3c001967,0 ) 31144 date NAMI "/etc/localtime" 31144 date RET open 3 31144 date CALL open(0xcfbde9d4,0 ) 31144 date NAMI "/usr/share/zoneinfo/posixrules 31144 date RET open 3

Yes, in many ways Musl is a BSD style libc for Linux (even down to the license). Add pkgsrc and it is pretty BSD-like.

Re: Simplicity and the ideas Go left behind

#80

Post by qznc »

kazagistar wrote: post #78
masklinn wrote: post #53

Earlier quoted context omitted.

> If you really want simple, you could as well use SML, TCL, or Lua. And if you truly want simple, you use Smalltalk, Scheme or Forth.

I dunno about smalltalk, but Scheme and Forth start off simple until a programmer writes tens of thousands of lines of code, at which point it gets harder to read and follow the code exactly.

No matter how much convoluted code your write, it is still a "simple language". Your code however is not necessarily simple or easy.
Post reply on HN