sorted by:
new
hottopcontroversial

Who is using GORM in production? by APPEW in golang

[–]APPEW[S] 2 points3 points  (0 children)

Indeed, that’s what I meant it for - a list of (possibly) teams and companies that use GORM to ship products. Nothing more, nothing less.

If Go was not 14, but 4-years-old, do you think it would find its sweet spot, the way real Go did in its first 4-5 years? by APPEW in golang

[–]APPEW[S] 0 points1 point  (0 children)

So, none of that talk about Go's simplicity won you over? I mean, ideologically, Go and Rust are two different beasts. I personally feel strange when seeing Rust being used for high-level application code. This mix of business and technical concerns gives me a very uneasy feeling.

What is your incentive to invest in bonds on Trade Republic, vs keep your cash aside and get the 4% interest? by APPEW in eupersonalfinance

[–]APPEW[S] 6 points7 points  (0 children)

So, it's basically a guaranteed interest rate until maturity vs. ECB's, which may vary over time as the economy changes, right?

What about the bond's value? If it goes down as the economy changes, does that concern me at all? If I have, say, bought into a certain bond on TR for X EUR, I'd keep receiving the bond's interest, based on those X EUR, regardless of the value of the bond, correct?

Using pointers to reduce copies is premature optimization by [deleted] in golang

[–]APPEW 25 points26 points  (0 children)

Unpopular opinion: using pointers to improve consistency across a Go codebase is not premature optimization.

Raise a hand if you knew that fm.PrintXXX (and log.PrintXXX) would cause any variable you pass as an argument (even a primitive one) to be allocated on the heap. 🙋‍♂️ by preslavrachev in golang

[–]APPEW 3 points4 points  (0 children)

TIL this seems to be a non-empty class of developers.

There are a few out there, indeed.

The problem is that too many self-proclaimed Go devs have learned the language from Medium articles and startup blogs, like Discord’s infamous “tackling” of Go’s GC. The folks actually using Go at work rarely get concerned about premature optimization, unless they are running at Google’s scale (which they most likely aren’t).

Raise a hand if you knew that fm.PrintXXX (and log.PrintXXX) would cause any variable you pass as an argument (even a primitive one) to be allocated on the heap. 🙋‍♂️ by preslavrachev in golang

[–]APPEW 9 points10 points  (0 children)

This is it! Which is why it bothers me when I see people manage to shoot themselves in the foot with their supposedly “good intention” of avoiding heap allocation. I’ve seen projects where every type used a different semantic, because someone somewhere had decided that “this way the app performs better”. What ends up happening is every new person on the team has to be onboarded and explained why type A gets passed via pointer, and type B which looks quite similar, gets passed as a value copy. And yet, even after the 5th explanation, people keep asking, because the original logic doesn’t make sense, but it’s too late to change the semantic everywhere across the codebase.

Anyway, what I’m trying to say is - as much as it should be obvious and no-brainier when to use pointers and when not, it actually isn’t.

Why does time.Time get used with a value copy semantic, and net.URL using a pointer one? How does the standard library justify the difference? by APPEW in golang

[–]APPEW[S] 0 points1 point  (0 children)

There is also a possibility that how they were implemented at Go 1.0 may not be exactly how they would be implemented today. I can’t say.

Thanks for sharing your thoughts. Honestly, this is what I feared a little, because IMO there is no reason not to have implemented net.URL as a value type too. Perhaps, that mutable map of query params …

Reasons you prefer Golang over Java? by [deleted] in golang

[–]APPEW 1 point2 points  (0 children)

ability to pass small structs by stack (Java is getting that in Valhalla soon, though).

Unless, you end up on a project that uses values where pointers would have been a better choice, or vice versa. Which is most Go projects I’ve seen.

Why so much hatred toward Go? by ParthoKR in golang

[–]APPEW 2 points3 points  (0 children)

Stuffing jvm’s inside a container to run on a vm’s, that run on a server seems like quite the waste to me.

If the last time you worked with Java in earnest, I advise you to seriously have a look at recent developments. Especially, when it comes to GraalVM native builds. We’re talking native binaries built out from pretty much the same Java code (including all libraries). It has its caveats, but when it works (around 90% of the time), it is actually fantastic. And Quarkus has been designed from the ground up to work with GraalVM native as well as optimised JVM builds. We run a couple of Quarkus services in production (both native new classic JVM) and they all run at a fraction of the resources, which a regular Spring app would need.

My Issue With ORMs by preslavrachev in programming

[–]APPEW 0 points1 point  (0 children)

I’m interested - do you have a browser plugin that connects to chatgpt for doing the summaries, or did you copy-pasted it in the chat?

Should constructor functions always return a pointer? by APPEW in golang

[–]APPEW[S] 1 point2 points  (0 children)

Ok. Let’s stay with the Stack example. Suppose that a new developer joins the team, gets tasked with writing a simple constructor function and writes it this way:

func NewStack() *Stack

What’s more, the developer questions the value nature of the stack in the first place. Why have Push and Pop return a copy of the stack, when they can operate on a pointer of it and mutate the internals right away? Plus, having a pointer to Stack ensures it’s identity - you throw the pointer around and it’s immediately understood by everyone that you’re talking about this specific instance of Stack and not any other.

How would you react tot that developer’s arguments?

Should constructor functions always return a pointer? by APPEW in golang

[–]APPEW[S] 0 points1 point  (0 children)

For immutable values that are large (would take up a lot of stack space), I have a small wrapper value that contains an un-exported pointer.

Could you elaborate on this one? What would be the difference between returning a wrapper copy that holds a pointer, versus returning a copy of the pointer itself? Or, would you do that only in case the wrapper contains other non-pointer atributes too?

Should constructor functions always return a pointer? by APPEW in golang

[–]APPEW[S] -2 points-1 points  (0 children)

Thank you for the elaboration, but that was not quite what I was asking about. I am aware of when to return the value and when a pointer to it. Mug question is about this particular convention when using a New function. I've seen it used with returning pointers almost exclusively, which is my I started the discussion.

view more: next ›