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

I Love Go; I Hate Go

dtrace.org

Post reply on HN
Print view View original

61–70 of 329 posts

Re: I Love Go; I Hate Go

#61

Post by pjmlp »

millstone wrote: post #53
pjmlp wrote: post #27

Earlier quoted context omitted.

Yeah what were/are Xerox PARC, ETHZ, Microsoft, Apple, Google thinking in their language departments!

What interpreters did these orgs write in GCed languages?

A few examples from Oracle/Sun using the Graal VM engine, written in Java:

https://github.com/graalvm

From Microsoft:

http://ironpython.net/

http://ironruby.net/

https://msdn.microsoft.com/en-us/library/dd233052%28v=vs.110...

https://msdn.microsoft.com/powershell

Xerox PARC used Cedar for the software implemented on Xerox 1132 (Dorado) and Xerox 1108 (Dandelion) systems, including interpreters delivered on the system:

http://dl.acm.org/citation.cfm?id=17919.806844

Re: I Love Go; I Hate Go

#62

Post by junke »

dmoy wrote: post #15
_skel wrote: post #10

The most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this be…

I think it depends on what you're using it for. On my day-to-day I'm working with absolutely massive pieces of software that have dependency trees that would literally make me cry if I stopped and thought about it too hard. In that world, this sort of thing enforced strongly makes me much happier. For random one-off hacking, yea, it'd be a pain. Differing use cases lend cause to different tooling.

People are ok with compilers telling them what is wrong, they complain that Go wants to control when you fix the problem: "fix that import NOW, bad developer" is not opinionated, it is stupid.

> Differing use cases lend cause to different tooling.

What?

Re: I Love Go; I Hate Go

#63

Post by thewhitetulip »

dpc_pw wrote: post #49

Oh. Go love-hate relationship post. My turn. So I really like channels and coroutines built into language and used everywhere: it makes some patterns compose nicely and language very productive. But just as in the article - some of Golang choices are opinionated and IMO just stupid. Lack of assertions is one: Sure programmers are prone to ignoring errors, but Go is not helping at all. Just bans assertions and provide…

>and all my contacts with the community were very unpleasant

I can testify to this! I even got banned from the golang subreddit :-D

EDIT: I didn't bully anyone or anything, just told them that they can't call the language as golang, because when I had asked feedback on my work an year ago, the only feedback I got from a certain person and that too very rudely was "to not call the language Golang and call it Go, ruby is called ruby and not rubylang"

Re: I Love Go; I Hate Go

#65

Post by skj »

pjmlp wrote: post #27
the_duke wrote: post #19

Earlier quoted context omitted.

whatevs...

Yeah what were/are Xerox PARC, ETHZ, Microsoft, Apple, Google thinking in their language departments!

Which interpreters are you thinking about that are written in a GC'd language?

Re: I Love Go; I Hate Go

#66

Post by _ph_ »

the_duke wrote: post #19
andrewfromx wrote: post #9

Here's a way to love go, write a language in it https://github.com/grubby/grubby

whatevs...

Why wouldn't it be? Instead of rolling out your own, bad GC, you can rely on the tested built-in. Of course you would be careful to write the interpreter loop so that it does not allocate memory just for interpreting, but that should be easy in a decent language.

Re: I Love Go; I Hate Go

#67

Post by pjmlp »

skj wrote: post #65
pjmlp wrote: post #27

Earlier quoted context omitted.

Yeah what were/are Xerox PARC, ETHZ, Microsoft, Apple, Google thinking in their language departments!

Which interpreters are you thinking about that are written in a GC'd language?

See https://news.ycombinator.com/item?id=12208320

Re: I Love Go; I Hate Go

#68

Post by millstone »

patates wrote: post #52
andrewfromx wrote: post #11

Earlier quoted context omitted.

i was shocked by that at first too. Then I came to love it. It's sooooo go. Don't import stuff you aren't using. Don't declare a var and just leave it there un-used. When I go back to ruby and commit that crime, I see why golang did what it did. There's something magical about a golang program that will compile without error. It's worthy of checking in to git. And months later, there will be no unsed imports FOR SURE…

Why on earth would the language hinder you from iterating fast with a flag, and then convert all the warnings to errors when you run the full tests? For example, most JS linters do that check and as a general rule, the build servers would reject the commit when the linter complains. I actually have a (very hacky) plugin to ESLint that automatically removes unused variables before `hg push`. It's totally not optimal,…

Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. Better to inflict some pain during development if it keeps the Go source corpus hygienic.

One under-appreciated consequence is that this policy limits Go to one implementation. Say I write an alternative implementation of Go, that has a different "unreachable code" detector. If I issue errors on new cases, then I'm incompatible with lots of existing Go code. If I fail to issue errors, then code developed against me may be incompatible with the standard Go. The effect is to suppress alternative implementations.

Better to just put my smarts into a linter, which is then just reinventing compiler warnings under a different guise.

Re: I Love Go; I Hate Go

#69

Post by gkya »

_skel wrote: post #10

The most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this be…

I really would like to see what happens when somebody forks go to create a sort of Go++ (tm) which, while still compiling code written for actual Go, didn't strictly prohibit unused variables and imports but only issued warnings and, added function templating as a means of generics. Regardless of whether these are good ideas or not to have in Golang, it'd be interesting to follow how the community orientates itself in time.

Re: I Love Go; I Hate Go

#70

Post by patates »

millstone wrote: post #68
patates wrote: post #52

Earlier quoted context omitted.

Why on earth would the language hinder you from iterating fast with a flag, and then convert all the warnings to errors when you run the full tests? For example, most JS linters do that check and as a general rule, the build servers would reject the commit when the linter complains. I actually have a (very hacky) plugin to ESLint that automatically removes unused variables before `hg push`. It's totally not optimal,…

Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. Better to inflict some pain during development if it keeps the Go source corpus hygienic. One under-appreciated consequence is that this policy limits Go to one implementation. Say I write an alternative implementation of Go, that has…

> Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried.

I already mentioned that case. To be more clear: Let it not build with default options. Make it not `go get`able.

Let me develop first, and not force me to optimize prematurely.

Post reply on HN