Minor nitpick: I think for is a special case of while more than while is a special case of for.
The Go Programming Language, or: Why all C-like languages except one suck.
81–90 of 110 posts
Re: The Go Programming Language, or: Why all C-like languages except one suck.
#82So, what's fundamentally wrong with JS? Not a lot. At this point the article lost all credibility with me.
Some of the implementations in JS went wrong, but fundamentally it really doesn't have anything horrible going on for what it's meant to do. Unfortunately some of the implementation details do allow for seriously horrible code and some seriously horrible traps. But if you can clear the fog, and use "the good parts", it's actually pretty nice. As for the article, I think it's very well written and seems to have a good…
I am not talking about any APIs in JS or any "implentation in JS". JS, the language, as specified, is wrong at the core. It has a lot of insensible semantics. It's not even at a local maximum. I could just write a list of 10 changes to the language right now that would spur near-unanimous agreement of benefit with no downside.
Re: The Go Programming Language, or: Why all C-like languages except one suck.
#83If 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.
> If C isn't suitable for projects with more than 10K lines, then praytell, what language should my kernel be written in? The Xen hypervisor (which shares a lot of characteristics with an OS kernel) is written in OCaml, which seems to have proven a good choice in practice: http://gazagnaire.org/pub/SSGM10.pdf
The problem with OCaml is that you need to recompile every library you use whenever you update the compiler; even minor versions. You might be able to use it for any program, but not for every program.
Re: The Go Programming Language, or: Why all C-like languages except one suck.
#84Earlier quoted context omitted.
I think the point is "for the level of abstraction it targets". Add all those abstractions that are generally a good thing in a perfect world, and practically you shifted the language enough to be unsuited for many tasks we use it today.
Polymorphism doesn't have to add runtime overhead. You can achieve polymorphism without RTTI through code duplication, as C++ templates do. (You can also use uniform value representations, like C void *, although this is limited in its applicability.)
Code duplication is an overhead. Not as bad as RTTI, but static memory footprint is still important in the embedded/systems world -- sometimes more so than runtime memory footprint!
Re: The Go Programming Language, or: Why all C-like languages except one suck.
#85One concern I have with garbage collected system programming languages is GC pauses. I have worked with several java applications that were simply not capable of handling fast, continuous, time critical processing tasks because every now and then they would pause for garbage collection. Most of the time they were fine, but suddenly you'd get brief but unacceptable drops in performance. Does anyone know if go is likely to suffer from this?
Re: The Go Programming Language, or: Why all C-like languages except one suck.
#86Earlier quoted context omitted.
Polymorphism doesn't have to add runtime overhead. You can achieve polymorphism without RTTI through code duplication, as C++ templates do. (You can also use uniform value representations, like C void *, although this is limited in its applicability.)
Code duplication is an overhead. Not as bad as RTTI, but static memory footprint is still important in the embedded/systems world -- sometimes more so than runtime memory footprint!
You don't need any RTTI or code duplication for polymorphism, so long as you don't need general support for type-checked downcasts. If you do need type-checked downcasts, it can be as cheap as a single pointer on antirez's mylist->ops function table - a pointer pointing to the ancestor function table.
(Specific support for any single downcast is trivial - just write a function for the function table, typed appropriately and implemented appropriately.)
Re: The Go Programming Language, or: Why all C-like languages except one suck.
#87dynamic_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…
Every language has its pathological corner cases. Modern C++ using the STL is almost as terse as modern dynamic languages but runs 100x faster.
Yup. It runs x1000 faster than luajit, on a x1000 faster machine that is...
Re: The Go Programming Language, or: Why all C-like languages except one suck.
#88ctrl-F Rust
...nothing? ok here: http://en.wikipedia.org/wiki/Rust_language
Re: The Go Programming Language, or: Why all C-like languages except one suck.
#89No, 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.
Go doesn't lack exceptions. It just uses some different names (throw -> panic, catch -> recover) and uses a different way to write the code that catches them. http://golang.org/doc/go_spec.html#Handling_panics Edit: Also, here's an interesting pattern to illustrate that Go's panics are a little different. func parse(s string, config *Config) (x Thing, err error) { defer config.RecoveryPlan(&x, &err) x, err = doParse(…
Oh, I know about this already. Trouble is, panics aren't supposed to cross module boundaries.
"The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values"
http://blog.golang.org/2010/08/defer-panic-and-recover.html
But crossing interfaces between modules is, IMO, core to exceptions. They're ideally suited to communicating the underlying cause of failure from the depths of the system to the top-most loop (usually a request/response dispatcher or UI event loop), where the error message can be logged or shown to the user, as required, indicating the nature of the failure.
I expounded further on this point a few years ago, related to Java's misadventure with checked exceptions, but also relevant to module crossing:
http://cafe.elharo.com/programming/bruce-eckel-is-wrong/#com...
Re: The Go Programming Language, or: Why all C-like languages except one suck.
#90Earlier quoted context omitted.
Ok but exceptions also give you alot of context about the error like exactly where it occured. How is that handled in Go?
Do you mean that exceptions, when they bring down your program, indicate the line where the exception was thrown? If so, then `panic` in Go does the same thing. Using goroutines and panic/recover, you can do the same things you do with try/catch/throw.
No; the point is that the information is contextual. For a database failure, the information will be DB specific; for an IO failure, IO specific; for an IO failure in the DB subsystem, it will be information about IO failure wrapped in info about the DB failure.
I think too many people get wrong idea about exceptions from defaults in many environments. Exceptions being thrown should not normally be a sign of a bug; knowing the line number the exception thrown should be irrelevant information almost all the time, save for errors like access violations or null pointer exceptions.
Instead, the information contained in an exception can usually be turned into actionable data to a user or administrator of an app (depending on whether it's on the client or server).