Hacker News new | past | comments | ask | show | jobs | submit login

It's interesting that the pendulum has swung the other way in favoring readability over features. In many ways, Go seems to have something Pascalian lurking under its surface - WOCA with static compilation (and fast compile times), readability favored over terseness/expressiveness, and deliberately trying to limit what can be done (i.e., no pointer arithmetic) so that there is a 'sane subset' by default.

I've played around with Go (worked through the Go Tour and implemented some trivial site scraping/JSON client stuff). It's an enjoyable, straightforward language, and it makes it very easy to get started, but I fear that it will be (like Pascal) eventually overtaken by something hairier. (Go : Rust(?) :: Pascal : C++)




It's a miscalibration to compare Rust to the complexity of C++. Rust is more complex than Go, absolutely and unequivocally, but that's because Go is hanging out with Lua waaaay out over on the simple side of the spectrum of programming language complexity. Given the enormity of its task, Rust is actually a rather minimal language itself (though there are definitely still a few features that I think could be made simpler).

FWIW, I think it's misplaced to fear that Go will be "overtaken" by Rust. They both excel at different domains, and the systems software that you'd write in one is probably not the systems software that you'd write in the other.


In what way are any of these examples more readable than "proper" generics? A copy pasted solution with 3 different specializations is three times the code! The replace-"T"-solution is hardly any better in terms of readability than a modern (D/C#/Rust/Java) generic Collection<T> would be?


What you are forgetting is that the Pascal community also had Ada, Delphi, Modula-3, Active Oberon, Zonnon as languages in the Pascal family with some form of support for generics.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: