311–320 of 367 posts
Earlier quoted context omitted.
How different are people :) I personally prefer raw db queries as more flexible and performant way :) "Typing is not the bottleneck" (c) GeePawHill
As long as you don't want your queries parameterized/precompiled and inputs escaped, rolling your own SQL by hand should work.
Earlier quoted context omitted.
Can you explain why using a plain text editor for a typesafe language is a bit daft?
That may be stated too strongly, but the argument is in a statically typed language you go to all the trouble to provide the compiler with sufficient amounts of information, but then don't leverage that in your editor. E.g. if you call a statically resolved function, your IDE should be able to take you to the function's definition.
And it's pretty trivial to get Vim super integrated with go: https://github.com/fatih/vim-go/blob/master/README.md
Earlier quoted context omitted.
You're looking for go-plus [0]. Set the Format Tool to goimports, check Run Lint Tool on Save, check Run Go Vet Tool on Save, and add these vet arguments: "-shadow=true -shadowstrict=true". You may have to leave off that last argument for your own sanity. I found that 'shadowstrict' drives you mad at first, but you end up making better code for it -- mirroring my general experience with all the things about go that a…
I was already using go-plus, but I think the addition of goimports is something recent — it wasn't there when I last looked. Thanks for the pointer. I know that "go vet" can warn about this, my point was that it's amazing that Go refuses unused imports but allows shadowing. It reveals a very skewed idea of what is important when compiling.
That's what I remember from reading about it.
Earlier quoted context omitted.
I was already using go-plus, but I think the addition of goimports is something recent — it wasn't there when I last looked. Thanks for the pointer. I know that "go vet" can warn about this, my point was that it's amazing that Go refuses unused imports but allows shadowing. It reveals a very skewed idea of what is important when compiling.
iirc, the decision to disallow unused imports was largely motivated by improving build times. And not just for your package either. If each package in the tree can accidentally have an extra import or two it could end up ballooning to crazy proportions where everything and their third cousin is imported with only some of them being used. That's what I remember from reading about it.
Go conflating the two is, I think, its biggest design mistake on the build system side. In Go, dependencies are inferred from imports, which, since it can't express versioning information, leads precisely to this sort of problem.
It makes sense only if you're putting all of your dependencies in a single versioned work tree, but almost no developers work like that outside of Google. And it's not a good pattern for most devs/companies. Yet Go is completely infected by it.
Other languages typically use a dependency manifest, which IMHO is the only sane, logic approach.
The funny thing, a dependency manifest is a superset of Go's current import behavior. But they chose implicit over explicit, which in CS is a mistake 9 times out of 10.
Earlier quoted context omitted.
Its generally unlikely those things lead to interface changes. e.g. func bcrypt(salt string, password string). Generally the bug isn't in the interface. So its somewhat safe to upgrade the dep and see if the compiler complains Also exporting of interfaces is protected by case private()/Public() which leads to refined interfaces being exported. And the go vet tool expects all exported functions be documented. Not sayi…
This didn't directly answer my question, but it implies that you just periodically update all of your dependencies to the latest versions and pray your tests pass with minimal changes required. Yes?
Earlier quoted context omitted.
>For better or worse, CS departments across the US produce Java programmers more than anything else. Do you think this large pool of programmers are good? >This makes it very easy to hire Java developers. Yes, if you are looking for sub-par developers. I don't think Google thinks to itself "oh man we're so glad we use java, otherwise hiring would be challenging". No, they have just as much difficultly hiring as anyon…
> Do you think this large pool of programmers are good? Yes, why not? I have yet to see evidence that Java programmers are not good. Seems like a discriminatory mindset. The large pool also makes them easy to replace. I think Facebook has had an ad for an Erlang developer for a few months now. I don't think a startup needs that kind of stress. Also, I'm sure there are Java Devi who are absolutely fantastic. That is,…
The programming language has really nothing to do with the quality of a developer. A new language is learned quickly, software engineering skills not.
Earlier quoted context omitted.
I'm getting furstrated by code generation. I have a big project with has 3 files with (only) generated code. It's essentially repeating the same 15 lines about 50 times with slightly different types. And yet I far prefer all of them over an interface{} solution. Works so much better. But the files are just so ugly, and changing them is rather hard. Worst of it all, I've been thinking about generating other pieces of…
What are you using generated code with lots of types for out of interest? I haven't felt the need as yet but would like to try it out. Re handlers, you really don't have to use the http handler. I use one which accepts a context, and returns an error (for rendering), which simplifies the boilerplate somewhat as errors are rendered by the router. I'd look into using your own interfaces before generating standard http…
Firstly, for data access methods (think load struct type X from offline storage). It's like gobs or encoding/*, but it blasts those away when it comes to speed.
Secondly, for searching through data (given a list of struct type X, and some number of indexes of the data (essentially listing what the sorting order is according to one of the fields), search for the record that satisfies condition X, fast.
It's very handy that after generation, my vim editor will actually autocomplete all the available methods, and adding an extra method or struct to either the datastore or the in-memory searchable index is adding a line to a file and pressing a shortcut.
And the one I've started to write, given function X with named input params a,b,c and named output params d, e and f, accept an http request extracting these parameters, validating authenticated user, check CSRF, all with appropriate error handling, call function X with the parsed parameters, encode it's outputs as a json struct and return the response. Well, I'm working on this one, I guess, so this one might still change. Maybe also write a javascript interface that calls these methods to a typescript file.
And they're writing tests for a lot of these autogenerated methods. Because we do code reviews and they insist on testable code. I think this is unnecessary, but I've been seriously outvoted on this issue (having tests for one or two of the autogenerated methods, leaving the rest untested until you actually run into a problem is my preferred option). I would object, and I have. Oh well, my total lines of code written is through the roof, well on it's way to the moon, far exceeding people who've been writing code for more than double the amount of time I've been here. And it's useful code, and "useful" tests, so ...
> The approach I take is to generate actions with all the normal code in them as scaffold (for CRUD actions) - so for each one auth, then setup, then business logic,
Modifying autogenerated code is tricky and dangerous. You should never do it. It takes discipline, but you should always change the generators, never the code.
Earlier quoted context omitted.
I completely agree that a developer should have the freedom to put the "project" folder anywhere. As a golang newbie, I went through the motions of setting up GOPATH, but did not give it too much consideration. It also isn't clear to me how one might have multiple copies of the same project.
> It also isn't clear to me how one might have multiple copies of the same project. A lot of technologies employ temporary, cache data storage to build for specific platforms and/or configurations. This data is derived from the actual project, and is not saved in the repo, but it often takes significant time to generate. For example, I work with Unity3d. Unity3d has a great graphics pipeline; if you release the same…
Earlier quoted context omitted.
I totally disagree. It's not only a good idea, it's essential for certain core functionality to work at all. Take serialization, for example: without this feature it's impossible to write a good serializer as a library without code generation (messy and brittle) or reflection (very slow). To give another example, try writing a linear algebra library that's generic over the data type without this feature (and such lib…
Are we talking about the same thing? That is the most full-throated defense of orphan instances I've ever heard. The reaction to such things is generally... less positive... to put it lightly.
Earlier quoted context omitted.
> for me, the error handling code is code, code I want to pay just as much attention to as the non-error path. You likely want to pay as much attention as required to make things work, but the purpose of your code isn't to generate errors -- errors are what get in the way of the actual purpose of your code. For people who want to get an overview of what some code does, the error code is interesting only after you und…
A reasonable attitude for client-side code, perhaps, ('oh it blew up, I'll reopen the app and try again/rerun the script'), but I think not so reasonable for server-side code.. There's element of personal preference here. The longer I program the more I favor systems and styles that minimize unexpected problems; explicit error handling is very much in that vein. Another complication is that the word "error" actually…
This seems like a response to something that wasn't my comment. I even went out of my way to state what I thought might be obvious: "pay as much attention as required to make things work".
Handling errors is a given in this thread. The question was how to represent that in the structure of the program.
> There's element of personal preference here.
I agree that there's some of that, but if you accept that the main purpose of programming language syntax is to ease reading, writing, and understanding programs, then preference only matters to the extent you can know it, and most of us can assume that we do not know the preferences of the people reading and trying to understand our code. Given that, we must try to use somewhat more objective measures.
When reading code, is it more useful to get a broad overview of the algorithm, or more useful to dive into every possible branch? The answer to this won't always be the same, but for a given type of code it will likely lean heavily toward either breadth-first or toward depth-first readings, which correspond fairly closely to whether error handling is done locally at the site of the error. Further, I think most programs will benefit more from a breadth-first organization, such that errors are better handled (syntactically) in a way that doesn't interrupt the process of understanding what the code is supposed to do.
Go has a lot of things I like, but the difficulty of laying out a clear "do this, then this, then this, then that" is not one. Either you end up with "do this (or handle the error from trying to do that by doing this other thing), then this (unless there's an error here, in which case...)", or you abuse panic, or explicitly ignore errors. If you're in this situation, then the first is the best of a bad lot, but unless you're doing some very finicky, low-level code, it would be nicer to be able to handle errors outside of the purposeful flow of the application.
I agree that having a distinction between different kinds of errors is nice, but errors of type (1) are not the purpose of your code. They're problems that prevent your code from fulfilling its purpose. That's a whole different conversation, though. :/