231–240 of 329 posts
Earlier quoted context omitted.
Yes, but it requires that the victim has no way out. Stockholm syndrome is not just any unexpected change of preferences.
The victim has no way out short of switching languages which may or may not be under their control.
Earlier quoted context omitted.
I am really curious about the kind of tasks that are easily done in Go but for which Lisp doesn't quite fit.
Sometimes I like to have a fully statically typechecked program. You can do that in Lisp, its easier in Go. Also, it directly produces statically linked executables. You can do a lot of this in SBCL, it also produces executables, has type checking etc. But for some of this, you have to wrestle a bit with the Lisp system. The Common Lisp numeric tower is great - until you want to write low level programs where you jus…
Earlier quoted context omitted.
This may work for you code. But are you sure that all the libraries you use also follow that rule? Are you going to audit all of those projects and their dependencies to validate they follow the same best practices as you? The end result of Go's opinion on warnings is that you know a certain class of bugs in not present anywhere in both your code and all of your dependencies. While it's true that people and teams tha…
This is an easy problem to solve. The Go compiler could simply include a bit in the resulting binary/library that indicates whether or not it was built with the "disable-unused-variable-error" flag. If you're using a library that was built with that flag the compiler can simply refuse to compile your code without that flag, forcing you to acknowledge the problem head-on.
The result will be that everyone compiles with that flag on so they can use the libraries they want/need. It's in fact actively worse than just allowing warnings. At least if you allow warnings that way you aren't forced to lower your own codes protection just because one of your dependencies does.
The most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this be…
Basically, as soon as I save my file, it gets formatted, linted, unused imports are removed, the project is then compiled and unit tests are ran. I couldn't be happier.
Earlier quoted context omitted.
You don't know what you are talking about. Have you seen any Swift backend used in production? Would you use C++ for a web API? Go was developed because C++ is a horibble language and I'm glad it didn't adopt the expressiveness and abstraction from C++.
> You don't know what you are talking about. Have you seen any Swift backend used in production? He said "hell, use Swift" -- which didn't imply that he's considering it the first or best recourse. That said: 1) There's far more Swift in production (on iOS devices as native apps, not as backend, but still production code) than Go. 2) Merely 4-5 years ago nobody had seen Go in backend (web/server) production either. O…
I've got that but it was too late... the comment was already posted. I've up-voted his response.
The rest of your points are invalid. Development is not only about a http server(which I'm sure is subpar compared with Go). You will burry your time and energy in making basic things work. As developer that's great because you can use your experience on your "next" project but as a start-up you are very likely to fail. There may be some IBM developers that played around with the language but I'm sure IBM has no swift powered service in production. Swift is still a language in flux with many changes pending in the next 2 -3 versions. Big corporations don't really like to invest in unstable environments. Maybe in 3-4 years from now Swift will be able to compete with Go but today there is really no reason to use Swift over Go for a backend service.
> Go was developed because some old C/UNIX hackers didn't much like C++/Java and wanted to do their own thing
I must say it again: C++ is a horrible language. It may perform well and it may be widely spread but that doesn't change much as far as its design is concerned. C++ competes mostly on its reach not on its merits. Hopefully that will change as new platforms emerge(i.e Rust).
> In fact Facebook itself used to transpile PHP to C++ and run that (through their HipHop project).
Yeah, that's a pretty picture for what C++ is really good for. I rest my case.
Edit: I would also say "experienced hackers" instead of "old hackers". The C++ or Swift hackers are not younger anyway.
Earlier quoted context omitted.
It's a simple reflection of the fact that the Go creators have never used a modern IDE. Anyone using a modern IDE pretty much never even thinks about imports, which are (and should be) automatically managed by the tool, not by the programmer.
This statement is probably true but that's kind of irrelevant. IMO it is actually a virtue of the language if it is perfectly usable without a modern IDE. Contrast that with Java and you'll see what I mean. Go follows the Unix philosophy where things like imports or formatting can be supplied by any external tool. If you wish to bundle all these small tools into a single IDE you can do it, too.
In this particular case, the IDE could automatically remove the imports when you remove the corresponding symbol from your source, or automatically add the import when you introduce a new symbol.
The "can be supplied by any external tool" is a cop out that was acceptable in the 20th century but this is 2016, we have a higher bar for developer productivity.
Earlier quoted context omitted.
Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. Better to inflict some pain during development if it keeps the Go source corpus hygienic. One under-appreciated consequence is that this policy limits Go to one implementation. Say I write an alternative implementation of Go, that has…
> Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. Isn't it implied that programmers are adults?
I can't say I blame Rob Pike for not trusting developers, and I've definitely seen more than one case of a C/C++ codebase riddled with thousands of compiler warnings that were just ignored en masse during compilation.
There is another side of the coin, which is that experienced and disciplined developers who think they can take care of themselves, thankyouverymuch, would end up feeling limited by Go.
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.
Goimports doesn't help when the name is ambiguous. >I'm glad there are not such compiler flags. Because if they were there people would force you to use them? Or are you just unhappy that people could have a different debugging workflow than you?
> Goimports doesn't help when the name is ambiguous. You can fork it and set it to only remove unused imports. In fact I've done just that few days ago but for different reasons(i.e. I generate some small programs and I use goimports as a quick and dirty way to to clean-up the unused imports). Here is the line where you need to return https://github.com/golang/tools/blob/master/imports/fix.go#L... > Because if they w…
This seems like it removes half the value of the tool, though. I can comment out a line of code, compile and test the program. But if I uncomment that line, I'm now missing an import.
edit- how does a tool like this sound?
* If it sees an unused import, it comments it out
* If it sees an import is needed, and there's a commented-out import which would fit, it uncomments it.
* It can run in a "check for commented-out imports" mode, so that commit hooks can reject such a state.
I guess (making some assumptions about go's import semantics) this would avoid the ambiguous name problem; it would mean you avoid having to edit both the import and the usage at the same time; and it makes it easy to tell if a file should be cleaned up.
Maybe it would cause issues if you're trying to choose between two libraries which both provide the same symbols?
Earlier quoted context omitted.
Adding a dummy var won't work, because then the dummy var will trip the "no unused variables" check. 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…
I have seen both suggestions in this thread: var _ = unusedImport If you can't even agree among yourselves what is the right thing to do then I think that this is another sign that this go behaviour is not the proper solution.
If you comment out code that uses an import, comment out the import too. It's not just the recommended way, it's the only logical way of doing things.
And how is having 2 opinions on how to do something a sign that this is not the proper solution? People still can't agree on tabs vs spaces (and probably never will be able to), that doesn't mean that all programming isn't a proper solution. There are also people that think using version control is a bad idea, but that doesn't mean that all version control is broken...