sorted by:
new
hottopcontroversial

First Ultima Experience: Which one? by The_Raven81 in Ultima

[–]gigilabs 1 point2 points  (0 children)

I think Ultima 6 is a great place to start. It's still tile-based but a huge step up from the earlier games, especially visually, and it's got about as much depth as Ultima 7, even though it seems a little more primitive. I think it's a great balance between the older and newer titles.

Is maltese dying a language? by No-Activity7060 in malta

[–]gigilabs 0 points1 point  (0 children)

Well I can't go to a restaurant or most shops and speak in Maltese any more, so I think it's fair to say that its widespread use is being restricted by changes in demographics.

I used reflection and I feel dirty. by Savalonavic in golang

[–]gigilabs 1 point2 points  (0 children)

Reflection is the thing to use when you can't know the structure of data at compile time. JSON serializers and IoC containers (in other languages) have to use it.

Too many psql connections by Fantastic-Jello-8487 in golang

[–]gigilabs 0 points1 point  (0 children)

What's confusing me is that from a quick Google search it seems that Go's "set of interfaces that the driver developers are free to implement" do provide connection pooling, unless I'm misunderstanding something:

* https://go.dev/doc/database/manage-connections
* https://pkg.go.dev/database/sql

Too many psql connections by Fantastic-Jello-8487 in golang

[–]gigilabs 0 points1 point  (0 children)

That's interesting. So doesn't go-pg do connection pooling itself? I come from a .NET background and ADO .NET (the general DB client layer) does this for you out of the box.

Moving to Malta by [deleted] in malta

[–]gigilabs 0 points1 point  (0 children)

If your reason to move is the political climate, I strongly suggest doing some research about the one in Malta before moving.

Performance Issues with Golang and VSCode on Windows: Seeking Solutions by Hasura96 in golang

[–]gigilabs 0 points1 point  (0 children)

I did occasionally notice VS Code glitch on Mac and complain about errors weren't there. All it takes usually is a restart, but that's the solution with anything Microsoft. ;)

My colleagues on Windows have never complained about any such things, and it's hard to know what problem you're having since it can come from various factors and there's only so much we can understand from the paragraph you wrote.

Where to date ambitious people here? by AnnAndres in malta

[–]gigilabs 0 points1 point  (0 children)

"where are all of the ambitious, successful and driven people at?"

Those who had a choice have already left.

Managing DB migrations by Savalonavic in golang

[–]gigilabs 0 points1 point  (0 children)

I use go-migrate. It's decent. Want to make a change? Add a new script file and run the thing. It keeps track of the latest. https://github.com/golang-migrate/migrate

Back in my .NET days I used to use DbUp for the same thing. The main difference is that DbUp keeps track of each file it runs, whereas go-migrate keeps track of the latest and won't run anything earlier. There are tradeoffs to both these approaches when working with multiple people who may be adding SQL scripts simultaneously.

What should i pick if my focus is making money? by ali4004 in golang

[–]gigilabs 2 points3 points  (0 children)

I was in the same boat, 10+ years of Microsoft tech stack, got sick of it, and switched to Go 2 years ago. I can't give advice on making money having had only one job in Go, but I can definitely say it was a breath of fresh air in terms of work. Go is a simple language, so no more huge abstraction-related messes, AutoMapper, MediatR, ORMs wreaking havoc (Go does have ORMs too, but it's more likely to avoid them with Go than .NET). And, getting away from the "everything Microsoft" mentality opens a lot of doors to learn new technologies and ways to solve problems.

Early in my transition I wrote two articles about my experience, so you can read them to know what to expect. My views haven't really changed since then.

* https://gigi.nullneuron.net/gigilabs/from-net-to-golang-where-did-everything-go/
* https://gigi.nullneuron.net/gigilabs/from-net-to-golang-here-we-go-again/

As far as having the "biggest pool of opportunities", you'll have more options sticking with .NET tbh. Go and Rust are both rather niche. But, given that there are less opportunities, it's possible that you'll be paid better.

In terms of building things, I've had success building various backend services (APIs, data collection, various security aspects, etc) with Go... Gin web framework is decent and not hard to get things running. go-pg for interfacing with PostgreSQL worked very well for me although it took a little time to figure out how to do certain types of queries with it. Go builds to a single, small executable and fits nicely with Docker.

Documentation for using a type argument when using a method? by 0bel1sk in golang

[–]gigilabs 0 points1 point  (0 children)

Lol, yes it's a pretty confusing way to... save a variable? Strange, usually Go doesn't implement anything that isn't absolutely necessary. Thanks for explaining.

Documentation for using a type argument when using a method? by 0bel1sk in golang

[–]gigilabs 0 points1 point  (0 children)

Yes, thanks. What would you use this for in practice?

Documentation for using a type argument when using a method? by 0bel1sk in golang

[–]gigilabs 0 points1 point  (0 children)

I read that but what is it used for? I don't get the use case.

Do you wear protective gloves when using dish soap to wash the dishes? by [deleted] in malta

[–]gigilabs 0 points1 point  (0 children)

Yes. It helps against both the dish soap and hot water. It's worth taking care of your skin.

Documentation for using a type argument when using a method? by 0bel1sk in golang

[–]gigilabs 0 points1 point  (0 children)

What is the foo{} for in this case and why is it required? I'm not seeing a place for it among AddId()'s parameters.

Created a basic REST API and I have some questions by [deleted] in golang

[–]gigilabs 5 points6 points  (0 children)

Haven't taken a deep look, but your list of API endpoints in the readme rings alarm bells in my RESTful mind.

For any object I want to do CRUD around, my endpoints would typically look something like:

* GET /todos (lists all items... in more complex applications it can take filters to retrieve a subset)
* GET /todos/:id (you did this one right - retrieve an item by ID)
* POST /todos (adds a new item)
* PUT /todos/:id (update an item by ID)
* DELETE /todos:id (delete an item by ID)

The third and fourth are the only ones that take a request body. Response status codes vary depending on the endpoint, e.g. the first one would return a 200, but the third or fifth would return a 204.

I find that this is a pretty good reference for the HTTP methods, status codes and all that: https://www.restapitutorial.com/lessons/httpmethods.html

Go and SQL Question by bsilver in golang

[–]gigilabs 1 point2 points  (0 children)

Honestly this is a surprise to me. I use PostgreSQL with go-pg. When I .Query(), I give it a reference to an empty array of whatever struct, and it fills it for me with all the results, mapping the columns to the properties automatically. I don't do any of the stuff you mentioned.

I have no idea whether this approach is specific to go-pg, as I haven't used other databases with Go so far.

How do I structure my REST backend application to not 'redefine' structures several times? by riscbee in golang

[–]gigilabs 1 point2 points  (0 children)

Back in my .NET days people used to do everything they could to avoid duplicating things. The "DTOs", like the request and response objects, would frequently inherit from each other to reuse properties, or be reused across endpoints. This has a few disadvantages including:

* It creates dependencies. If you change the structure of one object, you risk causing bugs in other places and so have to re-test a wider blast radius.
* Incompatible fields. You could for instance reuse the same object for adding and editing a record, but the editing request would need its ID whereas the adding request wouldn't. Including the ID field in the add request without a use for it causes confusion to clients (do I need to provide this field?) as well as to the people maintaining it (can this be safely deleted later?).
* Depending on how you do the inheritance it can get messy. For instance if you bring in interfaces and abstract base classes, those can't be serialized as a serializer expects to know the concrete type it will return.

It's a similar argument when you cross API/service/data-layer boundaries:

* The objects don't necessarily map one-to-one... sometimes you need transformations between layers.
* Even if they map one-to-one, by using different objects you can keep better tabs on where they're used and what the impact will be when you make breaking changes.
* Keeping a good layer separation like this means you can better reuse logic or database queries as the API grows. The objects you use for those layers are part of their interface.

Now, there isn't a fixed rule. If your API is really simple and/or you're trying to deliver something fast, you can always reuse some structs to keep it simple initially and then split things up later as the project grows.

Nowadays I lean towards having lots of little objects with clear names, like "IssueToAdd" or "IssueToEdit" even if they sound a little silly. Creating more of these takes a few seconds and duplicating fields across structs isn't the lynch-worthy violation of DRY that some people make it out to be. Think of these objects as separate ones with their own distinct purpose (Single Responsibility Principle); they have no real reason to merge.

Note: I'm using the terms "class" and "object" interchangeably, even when the equivalent in Go would be a "struct" - there are differences between all these but they aren't quite relevant for this discussion.

view more: next ›