201–210 of 329 posts
I've simply never wanted for the things he asks as I've never had them. It's all in the expectations is my point.
Earlier quoted context omitted.
i was shocked by that at first too. Then I came to love it. It's sooooo go. Don't import stuff you aren't using. Don't declare a var and just leave it there un-used. When I go back to ruby and commit that crime, I see why golang did what it did. There's something magical about a golang program that will compile without error. It's worthy of checking in to git. And months later, there will be no unsed imports FOR SURE…
Why on earth would the language hinder you from iterating fast with a flag, and then convert all the warnings to errors when you run the full tests? For example, most JS linters do that check and as a general rule, the build servers would reject the commit when the linter complains. I actually have a (very hacky) plugin to ESLint that automatically removes unused variables before `hg push`. It's totally not optimal,…
There is a cost to this too. It is another option. Another thing to document and maintain. Another thing for developers to learn about. Another thing for newbies to be confused by. Another thing that will asked about on the mailing list.
Earlier quoted context omitted.
This was where I stopped reading. The author clearly hasn't worked with Rust. Not only are the messages very descriptive, but you have an extended explaination for each error in the form of: rustc --explain EXXX Which pulls up a long form explaination, and code samples of what is happening/why it is happening/how to fix it. The blog explaining the author's disdain for Rust mostly just seems to whining about the borro…
> The blog explaining the author's disdain for Rust mostly just seems to whining about the borrow checker. Most (negative) discussions about Rust are about the borrow checker. I sometimes wonder if people dislike it because it makes them feel the same way they felt the first time they learned to program and the compiler would never accept their code.
Earlier quoted context omitted.
> It's a part of the refactoring process of development which is something that must happen during the main development phase How is it refactoring if my code never builds in the first place? > pragmatically that still takes up such an insignificant amount of effort when compared with the overall time spent writing code in any particular language. Which is why many Go advocates are willing to put up with it. It's not…
> How is it refactoring if my code never builds in the first place? Why would you be typing in imports that you've never used? I guess that could happen, but the more likely scenario you had used them at some point, even if just briefly, and then you're refactoring the code. > It's not a time problem. It's a focus problem. I'm working on something and then out of nowhere, receive compilation errors, [...] pushed down…
No, I'm compiling to see if my changes still allow the tests to pass. This is a huge problem if you're doing TDD. The main argument you make is that it's not such a big problem and I think the number of people complaining says otherwise. Or maybe we developers just like being melodramatic. I honestly can't tell. Maybe what triggers such passion is go being very close to a perfect tool for certain things and those annoyances look like small black dots in a perfectly white surface (That sounded dramatic as well, what's wrong with me? :) )
I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with st…
This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point: > It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. Strict type checking? Have you used any other languages besides C ? Go'…
Earlier quoted context omitted.
I used to feel this way. It was my top complaint about the language. But it, and, more importantly, the use requirement for variables, has saved me from bugs repeatedly; I more and more notice the bugs it's protecting me from as I keep coding in the language. I am rapidly coming to the conclusion that this was very, very much the right call. I get the sense that most Go programmers use "goimports" to work around the…
> I get the sense that most Go programmers use "goimports" to work around the annoyance. I have my Emacs configured to use it automatically. I never even think about imports anymore. You haven't yet encountered clashing names? https://golang.org/pkg/crypto/rand/ https://golang.org/pkg/math/rand/ Or? https://golang.org/pkg/text/template/ https://golang.org/pkg/html/template/ goimports is wonderful, but some care is ne…
Earlier quoted context omitted.
This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point: > It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. Strict type checking? Have you used any other languages besides C ? Go'…
Maybe if by "people who know about types languages" you mean "Haskell snobs"
Earlier quoted context omitted.
This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point: > It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. Strict type checking? Have you used any other languages besides C ? Go'…
Why is the type system a joke (genuine question)?
I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with st…
Heh: my initial thought was that Go is nothing like Lisp - Lisp has the most powerful metaprogramming around thanks to its macro system, while Go doesn't even have C-level macros, or any of the type-system features some languages use as an alternative approach to metaprogramming. As a result Lisp is notoriously unopinionated, while Go is very opinionated. Lisp is functional, Go is aggressively imperative. And so on.…
Not really, multi-paradigm.
> and at least Go has reflection.
Go is introspective.
Lisp has both introspection (e.g. find-class allows to look at existing classes) and intercession (e.g. ensure-class creates/modifies a class at runtime).