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

Less is exponentially more

commandcenter.blogspot.com

Post reply on HN
Print view View original

31–40 of 124 posts

Re: Less is exponentially more

#31

Post by wvenable »

_delirium wrote: post #27
wvenable wrote: post #21

Earlier quoted context omitted.

> In a language with closures and Go-style goroutines and channels... Is that also filed under doing less? I believe C/C++ programmers aren't flocking to Go because it isn't strictly less. Every language that has tried to replace C/C++ always ends up doing too much. I'd love to see a replacement for C that solves the obvious flaws but doesn't add to much to the basic premise.

There are several of those languages too, but they suffer from the opposite problem: not enough differentiation to overcome the inertia, tool support, and installed base of C. The most developed attempt that comes to mind is Cyclone http://en.wikipedia.org/wiki/Cyclone_(programming_language) .

I agree. In the end, it's not really surprising that C/C++ continue on. Replacements either include too much to be a strict replacement or do too little to warrant the change.

Re: Less is exponentially more

#32

Post by rogerbinns »

I'm still of the opinion they made a mistake by not having exceptions. When programming in Python exceptions are wonderful because they let me put error handling code in the appropriate place without having to litter all the intermediary code to where errors happen with error flags. (Panic is not the same thing.)

The usual complaint about exceptions is "expense", but the same claims can be made about gc. The Go FAQ is more concerned about people labelling non-exception things as exceptions (so what?) or that try/except/finally is ugly. I agree with the latter, but even worse is littering code with if statements doing the manual equivalent of try/except/finally.

Re: Less is exponentially more

#33

Post by pufuwozu »

luriel wrote: post #14
larsberg wrote: post #11

It would be interesting to know if Rob and company would be using the language if they weren't also the compiler developers. It's one thing to trust a language with "less" features when you own the compiler and runtime, but another entirely when you do not. Rob and company have the backdoor that any time the compiler is not generating code that is as good as they expect, they can fix it _quickly_! Speaking as a compi…

There seems to be plenty of people that trust Go even if they are not the main compiler and runtime developers, Canonical, Heroku, the BBC, not to mention many startups that have completely bet their business on Go: http://go-lang.cat-v.org/organizations-using-go

Atlassian is on that list but I know that last year we rewrote our Go code to Python after our main Go developer left.

Re: Less is exponentially more

#34

Post by luriel »

rogerbinns wrote: post #32

I'm still of the opinion they made a mistake by not having exceptions. When programming in Python exceptions are wonderful because they let me put error handling code in the appropriate place without having to litter all the intermediary code to where errors happen with error flags. (Panic is not the same thing.) The usual complaint about exceptions is "expense", but the same claims can be made about gc. The Go FAQ i…

After using Go for a while (and Python and Java and many other languages with exceptions for years), lack of exceptions is one of my favorite things about Go.

Handling errors is not something magical that you have to worry might happen when and where you least expect it.

Exceptions are specially bad in Python, because often they are not even documented as part of the API, so you are never sure when you call a library what it might or might not throw and when.

And that is without going into how they are abused for convoluted control flow.

Re: Less is exponentially more

#36

Post by enneff »

rogerbinns wrote: post #32

I'm still of the opinion they made a mistake by not having exceptions. When programming in Python exceptions are wonderful because they let me put error handling code in the appropriate place without having to litter all the intermediary code to where errors happen with error flags. (Panic is not the same thing.) The usual complaint about exceptions is "expense", but the same claims can be made about gc. The Go FAQ i…

The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about.

In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief.

In short, we didn't include exceptions because we don't need them. Why add all that complexity for such contentious gains?

Re: Less is exponentially more

#37

Post by luriel »

greggman wrote: post #30

Go looks very cool but it solves only a subset of C++ better than C++. For example, I doubt very much Crysis, Battlefield or Modern Warfare could be written in Go on consoles assuming Go even existed on consoles. Similarly I'm not sure how great it is at client side apps where you need certain code for OSX and different code for Linux and yet different code for Windows. Or how about iOS and Android games, two places…

Go is certainly not (yet) ready for every task C++ has taken over during the last 25 years.

But I would say that for most tasks, it is more than good enough already.

> Similarly I'm not sure how great it is at client side apps where you need certain code for OSX and different code for Linux and yet different code for Windows.

This is very easy in Go, just name your file foo_windows.go, foo_linux.go, etc. See for example:

https://github.com/howeyc/fsnotify

Re: Less is exponentially more

#38

Post by [deleted] »

pufuwozu wrote: post #33
luriel wrote: post #14

Earlier quoted context omitted.

There seems to be plenty of people that trust Go even if they are not the main compiler and runtime developers, Canonical, Heroku, the BBC, not to mention many startups that have completely bet their business on Go: http://go-lang.cat-v.org/organizations-using-go

Atlassian is on that list but I know that last year we rewrote our Go code to Python after our main Go developer left.

[deleted]

Re: Less is exponentially more

#39

Post by rubashov »

greggman wrote: post #30

Go looks very cool but it solves only a subset of C++ better than C++. For example, I doubt very much Crysis, Battlefield or Modern Warfare could be written in Go on consoles assuming Go even existed on consoles. Similarly I'm not sure how great it is at client side apps where you need certain code for OSX and different code for Linux and yet different code for Windows. Or how about iOS and Android games, two places…

I don't see any reason to prefer Go to the D programming language. D achieves all the major claimed benefits of Go and yet has vastly more abstraction power and better type safety and error handling. The interest in Go is a mystery to me.

Re: Less is exponentially more

#40

Post by luriel »

enneff wrote: post #36
rogerbinns wrote: post #32

I'm still of the opinion they made a mistake by not having exceptions. When programming in Python exceptions are wonderful because they let me put error handling code in the appropriate place without having to litter all the intermediary code to where errors happen with error flags. (Panic is not the same thing.) The usual complaint about exceptions is "expense", but the same claims can be made about gc. The Go FAQ i…

The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about. In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief. In short, we didn't include exceptions becaus…

> In short, we didn't include exceptions because we don't need them.

I would say that not only I don't need exceptions, I absolutely don't want them.

A really annoying thing about languages with exceptions is how they contaminate code, exceptions are (often hidden and badly documented) part of the interface of libraries and packages which you have to deal with when you least expect it.

Post reply on HN