211–220 of 329 posts
Earlier quoted context omitted.
> Have you seen any Swift backend used in production? Lots of iOS applications use it already. > Would you use C++ for a web API? Facebook and Google apparently do use it.
And Google is actively replacing a lot of those with Go because using C++ for a web api is painful .
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 author clearly hasn't worked with Rust. The author links to a previous post on the subject, from mid-2015, so they clearly have at least tried Rust in the past. And while many Rust messages are OK, one should be careful not to confuse familiarity with Rust's error messages[0] with Rust's error messages being good (being inherently informative and good). Here's a clearer example (fixed since): http://dbeck.githu…
Earlier quoted context omitted.
No, there is no encouragement here. Go forces you to treat things that have always been just warnings in other languages as errors. And I wouldn't call a virtue something that doesn't give you a choice. I will be really pissed off if the language thinks that I'm so idiot that I need errors instead of simple warnings for the cases discussed here.
You are human, humans forget, humans get distracted, humans think that their situation is the exception that makes the rule. A program doesn't suffer from that. Forcing these things to be showstoppers makes sure they NEVER become a problem, and the "cost" (in terms of the developer) is pretty small in the grand scheme of things.
Earlier quoted context omitted.
> 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…
> Please don't be so melodramatic. It doesn't happen "out of nowhere". You've purposely broken your development focus to compile and unit test. 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…
Earlier quoted context omitted.
> ignoring years of research and good ideas And people are falling over themselves to use Go in places that seem inappropriate. Most of Go's strengths shine in a large team of mediocre developers: Low build times, low abstraction, quick ramp-up, etc. So why do startups choose Go? You're just shooting yourself in the foot. Use OCaml, use C++, use Clojure, hell, use Swift or Rust, just use something that at least prete…
I run a few side projects with a pool of about a dozen developers. Some love Java but others won't touch it, some are C developers, one of them only has experience with PHP, there are lispers, an Erlang zealot and even a Delphi refugee. I personally like Perl and OCaml but couldn't convince them to even consider them. It was a nightmare to agree and settle up with something. Enter Go, and while we all agreed that the…
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.
And more modern features than Go, even if designed in the 90s...
Out of genuine interest: could you elaborate on those? I have mainly worked with Pascal/Modula-2, and only shortly glanced at Oberon, so I am a bit shaky on his "later works".
Check Active Oberon:
http://www.ocp.inf.ethz.ch/wiki/Documentation/Language
Component Pascal is a Oberon-2 derivative but Wirth hasn't collaborated much there:
http://www.oberon.ch/blackbox.html
They made the very last version available for free. It was a kind of Delphi like, with the Oberon ideas of full stack OS.
www.pas.rochester.edu/~skulski/Presentations/BB_Class.pdf
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…
"But it […] 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 […] 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." If you don't think of imports anymore, how can they save you from bugs? (I do (somewhat) understand the "more important…
Highlighting dead code is not a trivial matter, at least for anything that could be referenced external to the module.
Earlier quoted context omitted.
> 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…
I have been using it since I switched to VSCode about 4 months ago and thus far, knock on wood, it's always found the one I intend. I however do think it considers what public members/methods you are calling.
It just finds a match and goes with it, and that does cause issue. Both of the above have potential security implications.
Filippo suggests preferring crypto/rand over math/rand as a softfix in this twitter conversation: https://twitter.com/filosottile/status/752210041709719552
I'd probably prefer html/template over text/template as it's better to have someone ask why their output was HTML escaped than to have someone render HTML in plain text without explicitly wanting to do so.
Earlier quoted context omitted.
You are human, humans forget, humans get distracted, humans think that their situation is the exception that makes the rule. A program doesn't suffer from that. Forcing these things to be showstoppers makes sure they NEVER become a problem, and the "cost" (in terms of the developer) is pretty small in the grand scheme of things.
How in the world forcing someone to put an underscore before the import name or adding a dummy variable to use the import (both should be removed after the debugging) helps to avoid bugs instead of making easier to introduce them?
Adding a _ to the front of an import is not the correct way to get around this "problem" during development, commenting out the whole import is the correct way. That way if you forget, it's not in your code anywhere (as it shouldn't be since it isn't used).
The underscore system is meant only to be used when you need to import for side effects (something that i've never actually needed to use).