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

The Go Programming Language, or: Why all C-like languages except one suck.

syntax-k.de

Post reply on HN
Print view View original

31–40 of 110 posts

Re: The Go Programming Language, or: Why all C-like languages except one suck.

#31

Post by sbov »

> Go has no exceptions.

I'm not a fan of the verbosity of error handling with exceptions either. It is particularly bad for fine grained error handling.

However, I do like that the default state of a non-handled error is to propagate and eventually crash the thing rather than continue with errors that may subtly corrupt things. I haven't used Go, but from the explanation of error handling Go seems to do the latter rather than the former (please correct me if I'm wrong).

In most languages, exception handling doesn't seem designed for fine grained error handling, which makes one not want to use it for that. Rather than complain about the verbosity of their methods, why not try to fix the issue with a less verbose method?

E.g. something like: handle := openSomeFile() catch err

Or ignore it if you want, letting it automatically propagate: handle := openSomeFile()

Re: The Go Programming Language, or: Why all C-like languages except one suck.

#32

Post by Jabbles »

sbov wrote: post #31

> Go has no exceptions. I'm not a fan of the verbosity of error handling with exceptions either. It is particularly bad for fine grained error handling. However, I do like that the default state of a non-handled error is to propagate and eventually crash the thing rather than continue with errors that may subtly corrupt things. I haven't used Go, but from the explanation of error handling Go seems to do the latter ra…

Go has "panic", which does as you suggest and propagates up the stack to something that can "recover". If nothing can, it will crash the program. Its use is generally reserved for truly exceptional circumstances.

Most errors are handled quite like the way you propose, e.g. handle, err := Open(). You can ignore the error if you wish, but that's up to you, and it's explicit that you're ignoring it: handle, _ := Open().

Panics are not meant to be a way to control the flow of the program, but rather to regain control of it if something disastrous occurs.

Re: The Go Programming Language, or: Why all C-like languages except one suck.

#33

Post by redthrowaway »

chimeracoder wrote: post #15

If C isn't suitable for projects with more than 10K lines, then praytell, what language should my kernel be written in? I've been meaning to try Go for a while (the fast compile times alone intrigued me), but this type of post really just puts me off - if you're telling me that C isn't suitable for large projects, then that tells me you may not know C well enough to make that judgement.

In general, he's right. Kernels and some other applications that require low-level access are an exception to the general rule that C is not a good language for massive projects.

Re: The Go Programming Language, or: Why all C-like languages except one suck.

#34

Post by barrkel »

No, I have never written exception-handling code like that mocked in this article. There's a strong correlation between uses of 'catch' and the probability that you're using exceptions incorrectly. Go's lack of exceptions is probably what pushes me away from it most strongly.

Re: The Go Programming Language, or: Why all C-like languages except one suck.

#35

Post by robot »

dynamic_cast>(funky_iterator>(foo::iterator_type(obj)) Yeah. Right. Don't get me wrong, I love templates, but contemporary C++ using STL looks like a classic case of the "If all you have is a hammer"-syndrome. GCC had to implement special diagnostic simplifications just so you can actually find out that that 5-line error message was a simple const'ness mistake when using a std::string method. Even worse, they can be slow as hell. Ever waited for Boost to compile? Good idea, bad realization.

I have been programming (in C) for 12 years, and when I see something like this I still get a shivering feeling. How can one design such a shitty programming language like this?

Re: The Go Programming Language, or: Why all C-like languages except one suck.

#36

Post by barrkel »

antirez wrote: post #27

C, for the level of abstraction it targets is an extremely good language, and this is the reason why it is still alive, and why a lot of big successful projects are written using C. The problem is its standard library. The "get this new language" teams should instead focus on how to incrementally improve C. D was a (bad IMHO) attempt, just retry and make it better, a step after the other. If we will wait the ANSI com…

I don't think so; I think you also need polymorphism and probably exceptions. I think GC would also greatly improve expressiveness, because it makes functional style much easier to implement without redundant copying. But minimally some kind of polymorphism, and no, discriminated unions aren't enough - but Go's interfaces would probably do. Also, some way of hiding data members that doesn't require obscuring casts would be nice too.

The biggest problems I've had with large C codebases are deep assumptions about data structures, spread throughout. The biggest benefits of OOP, IMO, come from firewalling off internal details from client code through the use of an interface; knowing that client code has to call you, rather than simply follow your internal links, gives you a lot of freedom to change things after the fact. A polymorphic reference that the client can't dereference and poke about with gives you that.

Re: The Go Programming Language, or: Why all C-like languages except one suck.

#37

Post by wollw »

antirez wrote: post #27

C, for the level of abstraction it targets is an extremely good language, and this is the reason why it is still alive, and why a lot of big successful projects are written using C. The problem is its standard library. The "get this new language" teams should instead focus on how to incrementally improve C. D was a (bad IMHO) attempt, just retry and make it better, a step after the other. If we will wait the ANSI com…

Agreed completely. I'm doing a decent amount of development with MCUs these days and really like having a minimal abstraction. It's easier to think about what the hardware is doing when you're only slightly removed from the assembly; what would be a convenient abstraction for most application development quickly becomes a liability as knowing the implementation details can be pretty important (due to limited resources).

As for an implicit "this" for function pointers, I've had the same wish myself. I've settled for just a function namespace (ie: myListPush(myList,foo);) due to the verbosity of your example but it's not quite the same. At this point I'm pretty happy without it, and even think it might be hiding too much information, but it makes a nice piece of syntactic sugar for sure. My current unneeded-but-desired change to C would be the addition of lambdas like in C++11.

Re: The Go Programming Language, or: Why all C-like languages except one suck.

#38

Post by freehunter »

wbhart wrote: post #18
cobrausn wrote: post #2

So while C may be as lightweight as it can get, it's not really suitable for projects with more than 10k LOC. I believe John Carmack would have something to say about this. http://en.wikipedia.org/wiki/Id_Tech_3

My own project (FLINT) is about 120k lines, and we're still going with C. I did spend a lot of time looking for a theoretical higher level language which could take us further when C ran out of puff, but we eventually decided to stick with C for the main project. However, I did eventually spot Julia, which is totally awesome for my own personal higher level needs.

For what it's worth, I've done a lot in Lua, dropping to C (on rare occasions) to offload heavy processing elements where a scripting language would choke. Many game developers do their interface and game scripts in Lua then run the engine in C as well. It keeps the C code light and clean and brings down the number of manhours required to build and maintain a project.

I don't know what FLINT is or what Julia is used for (Wikipedia makes it sound like a functional language?) so Lua might not be the best fit, but it's designed from the ground up to mesh with C (to the point where the solution to many otherwise simple things is "write that bit in C")

Re: The Go Programming Language, or: Why all C-like languages except one suck.

#39

Post by boyter »

The Java comments are wrong IMHO. Yes it has some legacy cruft. Yes you can import 10 million libraries and build abstractions on abstractions. Yes you can architect your application to resemble a Rube Goldberg machine.

Guess what? Those same points apply to an language. Heck the evolution of a Python programmer https://gist.github.com/289467 currently on the front page which does the same thing for Python which is usually pretty clean. Even PHP which is mentioned as the alternative can quickly become a spaghetti ball mess of imported code and shared snippets.

I don't love Java, but for certain classes of problems it is an excellent choice and to discount it based on a wrong perception just shows how shallow a technologist you are.

Re: The Go Programming Language, or: Why all C-like languages except one suck.

#40

Post by rpearl »

Unfortunately, the author seems to have misconceptions about a variety of things.

> projects with more than 10k LOC.

Other comments have discussed this. Linux kernel: ~4million lines. Compilers, interpreters, and so on... all well above 10k LOC. While C is not the best language for such things, by no means is it unmanageable.

> But when you try to do the modern funkiness of dynamic languages (lambda functions, map/reduce, type-independence, ...)

All of the features can be used in much stronger type systems than C++ gives you. ML-family languages have all these features and are strictly type.d

> Javascript Javascript's whacky semantics suck, that's for sure, but for a dynamic language that's par-for-course anyway. I don't really understand his argument about embedding. Why is that relevant? Java and C# are not embeddable either. ...So?

Post reply on HN