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

101–110 of 124 posts

Re: Less is exponentially more

#101

Post by luriel »

eta_carinae wrote: post #81

> What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types. Rob Pike seems to be doing a kind of programming unlike what most developers do. I fill, empty, filter and analyze values in containers all the time, and I suspect I'm…

> Rob Pike seems to be doing a kind of programming unlike what most developers do. I fill, empty, filter and analyze values in containers all the time, and I suspect I'm not the only one.

I don't think you are disagreeing, there is a reason Go has built in containers like slices and maps: they are very useful.

Rob said he spends very little time struggling with those issues, it doesn't mean he doesn't work with containers, just that (in Go) it is not a struggle, it is rare for you to have to write your own containers, and when you have to it is not particularly difficult (compared to eg., C).

Re: Less is exponentially more

#102

Post by nightski »

batista wrote: post #96
enneff wrote: post #66

Earlier quoted context omitted.

That's funny. I don't mind writing code. The code I like the best is the code I don't have to debug .

> That's funny. I don't mind writing code. The code I like the best is the code I don't have to debug. The code you don't have to write, you also don't have to debug. So you SHOULD mind writing code.

The assumption here being that if you do not have exceptions, one must write all the intermediate code. That exceptions are the only way of avoiding this.

While in Go this may be the case, it is not true in general. One could use an error monad to achieve the exact same thing, albeit in a much safer manner.

Re: Less is exponentially more

#103

Post by luriel »

rogerbinns wrote: post #53
luriel wrote: post #34

Earlier quoted context omitted.

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…

I agree that exceptions done badly are poor. That is especially the case with C++ where they were introduced later, and they are one of the things some people omit when picking the subset of C++ they use. I also don't think exceptions should be done without GC. Java's checked exceptions are very annoying. My experience in Python is the opposite than yours, but then I've only been using it for 12 years :-) Undocumente…

> Undocumented serious exceptions are no different than Go's panic

They are very different, in Go you only panic() for programmer errors: panic() is never part of any API, when you access any API you never have to worry about whatever it will panic() or not.

Meanwhile in Python any function or method might throw an exception for almost any reason imaginable, but of course most people pretend they don't, because exception handling code would swamp your code.

I have done plenty of Python programming, failure to properly handle exceptions is very common.

> And sure they can be abused, but virtually any functionality gives you "power" and that power can be used wrong.

Exceptions are particularly problematic because they are a hidden part of APIs, and you have to be aware of and deal with this hidden part libraries all the time, not just in code you write.

Re: Less is exponentially more

#104

Post by mkup »

batista wrote: post #88
pessimist wrote: post #59

Go has some really great features, I've written a few thousand lines in it and enjoyed it, but there are some strange hangups that the go designers have that in the end make me think its going to go nowhere. 1. Rob Pike is immensely proud that the language has no generics, but this means that in the last 2 years, there isnt a proper implementation of a linked list that can hold an arbitrary type, or a min-heap, an or…

That. It's nice for languages to have a "benevolent dictator", but Go insists in a lot of arbitrary but not that good choices like the above. I would add the bizarro build system (go build et al), that if you want to use you have to follow some rather silly conventions (a little flexibility would go a long way). The GC also leaves a lot to be desired --they will implement something better eventually, but why wasn't t…

Go language has no syntactic difference between owning and non-owning pointers. Therefore, it is impossible to replace stop-the-world GC with reference counting GC eventually. IMHO that's a flaw in the language design and it's too late to fix it, this train is gone.

Nevertheless, we have other good ideas in programming language design these days. Vala, for example, has robust memory management (so it will have predictable memory use on heavily loaded web or db server), and also "async" methods and "yield" statement (borrowed from Python/C#), which effectively turns a function into a class with locals and instruction pointer converted to fields. That way, function execution can be interrupted and restarted at any moment (e.g. HTTP request handler waiting for database to respond).

Channels, coroutines and cactus stack in Go are great, but there are other worthwhile appoarches to solve C10K problem, and who knowns, maybe yield and async over traditional linear stack is better?

Re: Less is exponentially more

#105

Post by dchest »

DeepDuh wrote: post #51
dchest wrote: post #29

Earlier quoted context omitted.

1986 - Brad Cox and Tom Love create Objective-C, announcing "this language has all the memory safety of C combined with all the blazing speed of Smalltalk." http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m... Once you're optimizing the runtime performance of Objective-C code, you're suddenly writing in C. The "close to hardware" thing is an illusion created by the "-C" part.

While that blog post is a fun read, it's a bit of a stretch to quote it in this context don't you think? ;) "Once you're optimizing the runtime performance of Objective-C code, you're suddenly writing in C." 1) in idiomatic obj c you have already more control over runtime behavior than in managed environments, simply because you don't have to worry about a GC kicking in at a bad time (like "user has touched my interf…

I'm not sure what kind of "managed environment" you're talking about, but Go is not one.

1) You're right about GC pauses, but you certainly don't have more control over the memory layout in idiomatic Objective-C than in Go. In ObjC you're mostly dealing with heap-allocated objects (by the way, remember that malloc is not deterministic too), and you don't have control over the objects' memory layout.

In the recent SDK, your typical NSNumber may be a tagged pointer or it may be a pointer to a number on heap -- you don't know, it's an implementation detail.

Hell, you don't even know the big O of NSArray! http://ridiculousfish.com/blog/posts/array.html

Oh, and autoreleasing. Do you know how many objects will be released at the end of your NSAutoreleasePool? Nope -- you don't know how many were allocated by other people's code you called.

2) Again, I don't know what "manage environment" you're arguing against, but from Go you certainly can call C functions. But nobody does this for speed, only for compatibility with existing C libraries, if needed. You're programming in Go, not in two languages.

Go is not a 'managed language', whatever this Microsoft's term means, so I'm not even sure what to answer to your last paragraph.

Re: Less is exponentially more

#106

Post by errnoh »

pufuwozu wrote: post #75
zaphar wrote: post #56

Earlier quoted context omitted.

I've never understood this kind of action. Go is so small you could hold the spec in your hand and it's going to be faster and more efficient than python as well as safer to modify thanks to type safety. If it were haskell, or a similarly difficult language to wrap your head around, I could see wanting to rewrite to something easier to understand. But Go has none of those problems. What could possibly motivate a rewr…

Hopefully we'd never rewrite Haskell - there's enough people here that know it and Haskell is extremely easy to understand. The team rewrote from Go to Python for various reasons: * Tool support (debugging, etc) was supposedly poor * The standard library wrappers were supposedly buggy * They had to write a lot of wrappers and libraries themselves * People on the team were already familiar with Python - after Atlassia…

Not blaming you, since there were people familiar with Python, it's probably good thing to continue using it.

Just thought I'd point out to people that this rewrite was done "last year", which was before Go1 was released march this year. The API was in constant change and it all projects needed constant updating to keep up with weekly releases. (or stick with the r60 with totally different and soon-to-be deprecated API)

API is frozen now and life is good.

Re: Less is exponentially more

#107

Post by sp332 »

eta_carinae wrote: post #82
zaphar wrote: post #56

Earlier quoted context omitted.

I've never understood this kind of action. Go is so small you could hold the spec in your hand and it's going to be faster and more efficient than python as well as safer to modify thanks to type safety. If it were haskell, or a similarly difficult language to wrap your head around, I could see wanting to rewrite to something easier to understand. But Go has none of those problems. What could possibly motivate a rewr…

> Go is so small you could hold the spec in your hand and it's going to be faster and more efficient than python as well as safer to modify thanks to type safety. I think it's very naive to think that the value of a language in a corporation is limited to its syntax or compilation speed.

Not just compilation (which is apple-to-oranges since python is bytecode-compiled and then interpreted/JIT compiled), but also execution speed, which means that you need less hardware to do the same job. That's definitely worth something in some cases.

Re: Less is exponentially more

#108

Post by mcculley »

capisce wrote: post #94
enneff wrote: post #62

Earlier quoted context omitted.

Allow me to respond to your points. 1. Your characterization of Rob's position on generics is not at all accurate. The Go team's view, in a nutshell, is that generics would offer some exciting possibilities for Go (particularly when combined with its concurrency model) but that it is also extremely hard to do generics well. We have put a huge amount of work into defining and refining Go, and we don't want to break it…

> The Go team's view, in a nutshell, is that generics would offer some exciting possibilities for Go (particularly when combined with its concurrency model) but that it is also extremely hard to do generics well. We have put a huge amount of work into defining and refining Go, and we don't want to break it with a bad generics implementation. Wouldn't it have been a good idea to take generics into account from the ver…

This is one of my concerns. Java clearly suffers from having generics bolted on much later and the underlying type system would be different if generics were contemplated from the start. Will Go have similar problems when they eventually add generics?

Re: Less is exponentially more

#109

Post by sp332 »

it wrote: post #61
zaphar wrote: post #58

Earlier quoted context omitted.

I don't think anyone is going to say that Haskell's type classes in any way fit the traditional notion of a type. It's more the exception that proves the rule in this case.

I know it's a common saying, but I've never understood how exceptions can prove rules.

Pointing out how flexible Haskell's type system is just proves how inflexible type systems generally are. It doesn't really demonstrate that most type systems are useful.

Re: Less is exponentially more

#110

Post by papsosouid »

eta_carinae wrote: post #84
enneff wrote: post #36

Earlier quoted context omitted.

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 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. I'm sorry but you are on the wrong side of history on this question (and I happen to think you're also wrong in your characterization of exceptions). Forcing callers to deal with error numbers right here right now only gives you the illusion of clarity and…

I just want to point out that just because go lacks a good way of handling error conditions, doesn't mean exceptions are the best way. Haskell has exceptions, and I wish it didn't. Because it has better options for dealing with error conditions, like Maybe and Either. If you are checking for an error condition every ten lines, those are by far nicer than using exceptions.
Post reply on HN