Philosophy and "for" loops — more from Go and Rust [LWN.net]

Philosophy and "for" loops — more from Go and Rust

Posted Jul 3, 2013 18:52 UTC (Wed) by b7j0c (guest, #27559)
Parent article: Philosophy and "for" loops — more from Go and Rust

yes, Go limits choice in some areas, limits features, and opts for too-simple in many situations....but the upside to this is that the language can be learned quickly. go look around godoc.org, there are already a huge number of libraries available...thats due to the fact that the language can be picked up quickly.

Go won't expand your mind but it is very effective as an industrial tool. anyone using python or java should at least take a look at it.

Rust looks nice but is still evolving, and may fall in to the haskell trap of having a high barrier to entry

to post comments

Philosophy and "for" loops — more from Go and Rust

Posted Jul 3, 2013 19:40 UTC (Wed) by Frej (guest, #4165) [Link] (3 responses)

Is haskell really more complex, or is it just (especially) industry inertia?

Philosophy and "for" loops — more from Go and Rust

Posted Jul 3, 2013 20:17 UTC (Wed) by b7j0c (guest, #27559) [Link] (1 responses)

well, where there's smoke there's fire. enough people talk about the barrier to entry that we might as well admit it is there.

learning about the real implications of lazy evaluation, monadic IO, currying, AGDTs etc are a stretch for most developers. this is not to say they aren't valuable lessons that will help anyone become a better coder, but they do require a time commitment.

Philosophy and "for" loops — more from Go and Rust

Posted Jul 4, 2013 8:21 UTC (Thu) by Frej (guest, #4165) [Link]

I'm not saying it's haskell is simple, far from. I'm claiming it is just as complex and difficult to learn and master. Control flow is a really complex issue, being it iterative loops or recursion.

I'm sure if you ask those who teach comp.sci introductory courses, they will tell you the same, but maybe they just brainwashed me ;) Many universities have chosen a functional language for the intro course (such as SML) exactly because of this. They claim it is easier to learn, especially for those who haven't programmed before.

For lazy evaluation as the default, yes it might have been a mistake. It makes figuring out time complexity of a program unnecessary hard.

Philosophy and "for" loops — more from Go and Rust

Posted Jul 3, 2013 22:09 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

My experience with Haskell has been that the syntax, execution model, and standard libraries aren't particularly difficult to pick up, but learning to write idiomatic Haskell code (i.e. not all in the IO and/or State monads) to solve common problems can take a long time, particularly when your reference material is assuming a procedural language with mutable variables. Some of the algorithms and data structures frequently used in procedural programs do not translate well to languages where data is immutable by default. The trade-off, of course, is that immutable data eliminates many of the more common kinds of programming errors.

Debugging can also be an issue, a common problem for non-strict languages, though Haskell does have some useful tools in that area--and is known for having less need for debugging to begin with thanks to its expressive type system.