Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is my hammer, and everything is a nail

maragu.dev

Post reply on HN
Print view View original

401–410 of 816 posts

Re: Go is my hammer, and everything is a nail

#401

Post by blt »

SatvikBeri wrote: post #241
blt wrote: post #216

I really like most aspects of Go, but as someone who writes a lot of numerical code, no operator overloading is a deal breaker. It's so hard to accept something like Add(Scale(s1, vec1), Scale(s2, vec2)) over s1 * vec1 + s2 * vec2. So I stick with Python and C++ for now. Rust is really appealing as a C++ replacement, but it has too many rules to replace Python for one-off scripts. Still need to try Nim and Swift, I g…

We switched from Python to Julia for numeric code. It's generally much faster (and easier to optimize), and has slightly better syntax for mathy code. It's worth noting that Julia is very similar to go, despite superficial differences. They're both small languages with big libraries, use the same concurrency model, use a mark-and-sweep GC with an emphasis on making it easy for the programmer to reduce garbage/allocat…

Julia looks like a great language, but has the "time to first plot" issue been fixed yet? I don't want a REPL-centric workflow.

Re: Go is my hammer, and everything is a nail

#402

Post by l33t7332273 »

pjmlp wrote: post #397
dartos wrote: post #268

Earlier quoted context omitted.

Or servers, and about anything that really benefits from concurrency. Even a lot of games could be made with go. The gc wouldn’t really kill the frame rate of a game unless you really push it.

That is what "UNIX daemons, containers means" on my comment. Gamedev in Go only for those that rather spend their time doing engines from scratch. Additionally Go's lack of support for dynamic linking is a no Go (pun intended) for big A game studios.

My Go is a little rusty by now, but I thought they supported some type of dynamic linking(although if I recall correctly it comes with a number of free footguns)

Re: Go is my hammer, and everything is a nail

#403

Post by funny_falcon »

shepherdjerred wrote: post #360
monkeywork wrote: post #348

Earlier quoted context omitted.

kind of hard for someone to prove a negative - feel free to find some Go code that meets that definition.

I feel this way... very often. * Init functions * Top-level variables being shared between all files in a package * For-loop sharing (fixed in 1.22 [0]) * ldflags (this is more of build behavior, but it took me a while to figure out how some variables were being set [1]. Note: Go does embed some data by default, but an app I was working on introduced more metadata) * Go build directives prevent IDEs/linters from anal…

First three are clearly documented in language reference, which could be read in several hours (at least before generics were introduced).

Re: Go is my hammer, and everything is a nail

#404

Post by anonymoushn »

randomdata wrote: post #394
tengbretson wrote: post #350

Earlier quoted context omitted.

A lot of times you want to be able to cmd+click on something and actually see what the hell the code actually does and not get dead-ended at an interface declaration.

Sounds like a UI bug more than anything. The compiler certainly knows how to determine if there is only one implementation of an interface and remove the interface indirection when so. There is nothing really stopping the cmd+click tooling from doing the same.

Does the compiler do that? That sounds extremely unlikely, especially because an interface with only one implementation can store the nil type tag or a tagged pointer to an instance of that implementation.

Re: Go is my hammer, and everything is a nail

#405

Post by blt »

bouncycastle wrote: post #328
blt wrote: post #216

I really like most aspects of Go, but as someone who writes a lot of numerical code, no operator overloading is a deal breaker. It's so hard to accept something like Add(Scale(s1, vec1), Scale(s2, vec2)) over s1 * vec1 + s2 * vec2. So I stick with Python and C++ for now. Rust is really appealing as a C++ replacement, but it has too many rules to replace Python for one-off scripts. Still need to try Nim and Swift, I g…

in my case, I prefer to see that the code is calling functions, so that I'm aware that they take extra resources such as stack space and it's easy to quickly jump into the functions to find what they are doing. Code that uses op overloading is hard to navigate and sometimes causes intense debugging pain. Simplicity always beats fancy features imo.

Operator overloading can be bad when abused for non-numeric types. But for numeric types, it is indispensable.

It's not hard to remember that `__add__` is using extra resources when I'm working with big matrices in NumPy.

Re: Go is my hammer, and everything is a nail

#406

Post by truth_seeker »

kerkeslager wrote: post #378
RandomThoughts3 wrote: post #138

Earlier quoted context omitted.

That's why I love Go so much. You want to write a very clever library using elegant abstraction and generics to have a cool innovative interface to solve your problem? Tough luck, you can't. So instead, you will just have to write a bog standard implementation with for-loops and good old functions which you will have to copy and tweak as needed where you really need something more complicated. It will work perfectly…

"Simple" is a cop-out word. Things can be simple along a lot of vectors. The vector you've chosen seems to be "does less for you" which taken ad absurdum would have you using assembly. Go does have elegant abstractions, and they aren't the simplest along this vector, nor would anyone want them to be. Coroutines, for example, are actually quite conceptually complicated in some ways. I prefer "understandable"--it appea…

Spot on ! same feeling here !

Re: Go is my hammer, and everything is a nail

#407

Post by JodieBenitez »

actionfromafar wrote: post #263
daghamm wrote: post #47

The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything . I have extremely good productivity when using Go. Once your project exceeds 100 lines it is usually even better than python. And yes, I am aware that Rustians did a survey where Rust was crowned as the most efficient language but in my reality (which may differ from yours) Go is simply the best…

My personal Python threshold is 10k lines. After that I tend to loose track of what I am doing and I start to miss static typing and nowadays, an IDE to navigate it. Maybe future Python IDEs can AI scan the codebase and compensate.

Wait... in what year was this comment written ? ;)

There's type hinting and IDEs do navigate it.

Re: Go is my hammer, and everything is a nail

#408

Post by surfingdino »

I was hesitant to learn Go after 10+ years of Python, but then I started work on a side project where performance translated into actual money savings for me. My Python code routinely took between 100-200ms to run. I was happy, but I was also curious if I could do better without rewriting it in C/C++. Go proved to be easy to learn and being compiled it was much easier to deploy (that was before I could rely on Docker for packaging). The big surprise came when I ran my code and found out that each request would take 10-20ms to process same payloads. I have never written a line of code in another language on the backend ever since. The cherry on top is support for multithreading/multi-core CPUs. I've been in Python by day client work), Golang by night (my own work) mode for many years now. It's a great language. OK, I do admit to learning Rust, but... it's just out of curiosity, not out of need for anything "better".

Re: Go is my hammer, and everything is a nail

#409

Post by SatvikBeri »

blt wrote: post #401
SatvikBeri wrote: post #241

Earlier quoted context omitted.

We switched from Python to Julia for numeric code. It's generally much faster (and easier to optimize), and has slightly better syntax for mathy code. It's worth noting that Julia is very similar to go, despite superficial differences. They're both small languages with big libraries, use the same concurrency model, use a mark-and-sweep GC with an emphasis on making it easy for the programmer to reduce garbage/allocat…

Julia looks like a great language, but has the "time to first plot" issue been fixed yet? I don't want a REPL-centric workflow.

It's vastly faster than it was before (~5s compared to ~40s for the Plots package, and much less for most workflows) but it can never drop to 0, since it's compiling each function the first time you use it.

Though honestly if you don't want a REPL or notebook-centric workflow, I would probably recommend a different language.

Re: Go is my hammer, and everything is a nail

#410

Post by mingusrude »

nemo1618 wrote: post #279
bborud wrote: post #94

People always under-estimate the cost of properly learning a language. At any given time I tend to have a "main go-to language". I typically spend 2-4 years getting to the point where I can say I "know" a language. Then I try to stick to it long enough for the investment to pay off. Usually 8-10 years. A surprising number of people think this is a very long time. It isn't. This is typically the time it takes to under…

One of the most important qualities of Go is that it is actually possible to fully understand the language -- in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?" Getting to that point takes many years, to be sure. But the language is simple enough, and changes slowly enough, that it is not an unrealistic goal -- the way it would be in C++, or Rust,…

This is similar to the experience that I had with Erlang. After having spent time with it, I was hardly every surprised looking at any code and my brain could deal with the actual problems at hand without having to figure out how to apply what I knew about the language.
Post reply on HN