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

111–120 of 124 posts

Re: Less is exponentially more

#111

Post by jbellis »

msz-g-w wrote: post #89
jbellis wrote: post #73

Earlier quoted context omitted.

I'm with the grandparent. Every language that I've used that was created after C has included exceptions, and never once have I missed checking errno. I can understand why, coming from a C++ context, you'd want to avoid them like the plague, but other languages (Python, Java, Smalltalk, ...) do a good job of making them a first-class citizen in the language, which saves a LOT of boilerplate typing. Seeing call stacks…

Did you miss the part where he says: "We weren't trying to design a better C++, or even a better C. It was to be a better language overall for the kind of software we cared about."

You're missing the forest for the trees. The topic of the article is about how good was motivated by creating a better language for systems software than C++, and hypothesizing why it's nevertheless getting more traction with the scripting crowd than C++ programmers.

"We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care."

Re: Less is exponentially more

#112

Post by zaphar »

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.

If I had limited my analysis to just those things you would have a point. I didn't though. errnoh provided the justification OP was missing. The pre Go1 api changes where a very fast moving target so reducing that maintenance burden was a valid concern. My response was just consternation at the desire to rewrite something when the language is simultaneously easy to learn, safer to modify, and probably faster and more efficient at the task than the language you rewrote it to.

Re: Less is exponentially more

#113

Post by acqq »

acqq wrote: post #100

The most useful information about Go until now for me: It was not made to replace C++, rather, it seems that it grew out of frustration of using C++ for some specific project inside of Google. That program needed 45 minutes to compile on a computer cluster! However, Rob seems to wonder why more C++ users didn't pick up Go, but Python users did. But I believe it's more than obvious: I'm sure that he still can't use Go…

Now, what would be the ideal language that would be "better than C" in my opinion? Let's call it X. In my opinion, X would be some modification of C with the following properties:

- no headers in C sense -- a limitation that would allow the definitions to be independent of text-based macros.

- the compiling/linking speed of ObjectPascal or Go. That area was the most ignored by "compiler designers" for years, because "hey we're compiler designers" and "linkers are not sexy, compiler are." In reality, the mentioned C++ monster that compiles 45 minutes could be reduced to be compiled to 4 and have all functionality of current C++.

- the full "linkability" to C. If I link a bunch of X files, I can get one OBJ which I can link to the C project. Or I can call from X to C. Both must work. Maybe I would need to link some run-time support additionally, but it must be enough.

- having in compiler "the introspective capabilities" as in D. That is fully ignored by most of compiler writers and I really believe D is on the right track, especially since Andrei Alexandrescu worked for some of such features. If at some point I have some expression and compiler know the type of it, I should be able to query it. If compiler knows the name of something, I should be able to query it and insert the name in my code! If compiler knows some dependency, I should be able to know it in the code, if I need it. Etc.

- built-in ways for decent strings (with counted sizes, not zero terminated), counted arrays, lists etc. I should be able to use them in the declarations/implementations without the overheads of the STL monster that it became. Again I should be able to link the runtime and access elements of these from C too.

So the logic would be: you can shoot yourself in the foot like with C, but you can have a "safer subset" (the compiler should have the switch "compile as unsafe" which would be off, in order to live you the chance to do low level when you must, but to keep most of the code "clean." When most of the "common" arrays, strings, maps, trees are part of the language, in most common cases, the whole programs could be "safe."

Etc. As you see this probably excludes some of cool features of Go like "segmented stack" and concurrency but it can give something much more convenient than C++ and still be as fast and "low-level-to-the-last-byte" usable like C.

I know, it wouldn't appear too creative, it would appear even less "interesting" than Go but I believe it would make a change: the C basis is sound, we still need the language that we know that it cleanly maps to the assembly.

Go is "something above," therefore not so attractive for those that need the "to-the-assembly" level.

Re: Less is exponentially more

#114

Post by munificent »

enneff wrote: post #23
munificent wrote: post #19

I think as working programmers, we end up torn between two opposing perspectives with our tools (i.e. programming languages, editors, language features): On one side, there's the aesthetic of minimalism. Visualize the master Japanese calligrapher seated in an otherwise empty room, table before him. One parchment, one pot of ink, one brush. And he creates the most flawless art one could imagine. Mastery means removing…

I think you make a good point, but I would argue that Go finds that balance. Sure, Go's design is more ideologically motivated than, say, C++, but it is not ideological to a fault. (And I think Rob hints at this in the article.)

I think Go hews to the minimal side, but I agree that it definitely aims to be practical and full-featured. The language itself is small, but not painfully tiny (unlike, say, Scheme), and the standard library is quite nice from what I've seen.

Re: Less is exponentially more

#115

Post by luriel »

mcculley wrote: post #108
capisce wrote: post #94

Earlier quoted context omitted.

> 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?

Actually the Go team has mentioned what happened with Java is a reason why they have not added generics, they have said they wont add them unless they are 100% certain that they are happy with the design and that they will not damage the language.

Re: Less is exponentially more

#116

Post by krarick »

pessimist wrote: post #97
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…

> So the situation is perhaps a little cumbersome, but no worse than C. Actually, this is not totally true. C has pre-processor and void * which allows for simple generic data structures with no performance impact. go ties your hands here since you have to use type-assertions which are not free, unlike C casts. > 4. I think you're wrong. Think of any time you've written an event loop or had to rally multiple threads.…

> I'll also note that for both complaints 1 and 2, you think its trivial for programmers to just do the work, but I though go was all about saving programmer time?

Go is "penny foolish and pound wise", to subvert the maxim.

It is indeed trivial for programmers to just do the work, and in return you get an amazingly regular system that saves huge swathes of time grappling with larger issues.

I've noticed this realization occurring to other programmers. It's not at all obvious until you've written a significant amount of Go code.

Re: Less is exponentially more

#117

Post by ken »

munificent wrote: post #19

I think as working programmers, we end up torn between two opposing perspectives with our tools (i.e. programming languages, editors, language features): On one side, there's the aesthetic of minimalism. Visualize the master Japanese calligrapher seated in an otherwise empty room, table before him. One parchment, one pot of ink, one brush. And he creates the most flawless art one could imagine. Mastery means removing…

The main difference between your "zen" languages and your "kitchen-sink" languages seems to be whether they've standardized their basic libraries, or whether everybody brings their own. I don't think it's controversial to say that virtually all programmers use libraries (both built-in and third-party).

Javascript and Scheme programmers don't build everything from first principles, and C# and Lisp programmers don't need to study for years more just to figure out which wrench to use. The working-set of programmers in either kind of language is comparable in size and functionality.

Re: Less is exponentially more

#118

Post by greggman »

luriel wrote: post #37
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 exam…

Define "most". It's not suitable for any app I've written in the last 25 years. But I don't do server work, I do client work. Native apps on Windows, Mac, Linux and consoles.

It might be useful for some command line tools I've written but since nearly every command line tool I've written in the last 25 years has been to make data for my C++ client side apps there's a benefit to being able to share code.

Of course I know that's just one anecdote, mine. If it fits most of your use cases awesome.

For me, one thing that might go a long way to use Go is are cross platform client side libraries like WinForms. Once of the things that makes C# so popular with my crowd is how easy it is to make tools with GUIs. Of course C# also interfaces with native data pretty well. No idea how well Go handles that case

Re: Less is exponentially more

#119

Post by batista »

nightski wrote: post #102
batista wrote: post #96

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. 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.

Sure, and in some next generation language yet to be invented you might not even need the error monad!

But we're talking Go here.

Re: Less is exponentially more

#120

Post by michaelcampbell »

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…

> harder to reason about.

I hear this from Rich Hickey about Clojure all the time. I'm certainly not at the brain-power level to fully absorb all the implications of that phrase, but I'm starting to "get it". I think this is probably one of the most compelling things to strive for in a medium that is used to "make stuff", like a programming language.

Post reply on HN