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

571–580 of 816 posts

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

#571

Post by _xiaz »

tmountain wrote: post #486
_xiaz wrote: post #473

Earlier quoted context omitted.

I believe people over-estimate the benefit of properly learning a language. 3-12 months seems to be sufficient for the specialisation benefits to outweigh the small hit to language competency. My strategy is to be a generalist superficially learning specialized languages.

Whatever time frames you apply, the only way to really learn a language is to use it. Reading a book, blog articles, and watching videos on YouTube won't give you the hands on experience necessary to internalize how everything works.

Of course. My methodology is usually this:

Day 1: read the introduction of a book, set up editor and environment

Day 2: (superficially) learn flow control and type system

Day 3: practice with coding problems on codewars

Day 4-7: reimplement one of my projects

Week 2: read the second quarter of the book and continue with puzzles

Week 3+: Just projects, maybe invest a day into tooling somewhere in between

That is assuming 1-3 hour days

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

#572

Post by aragilar »

Lyngbakr wrote: post #492
lenkite wrote: post #448

Earlier quoted context omitted.

Go is not good for data science and ML. It doesn't even have a proper, maintained dataframe library for data-science. R and Python beat it hands on. Rust also beats it now thanks to polars. And mobile ? gomobile is not maintained. Fyne is amateur level on mobile. AFAIK Go has no maintained 3d game engines. Go has its well-established niche for middle-ware services and CLI tools. And that's about it. If your domain is…

Is the reason for the absence of a well-maintained dataframe library lack of demand? It looks like Gota and Dataframe-go are abandoned, while Gonum isn't particularly active. Did these wither on the vine because no one used them?

It's likely because it's a pain to call Fortran or C (I'd be suspicious of anyone trying to reimplement openblas in go).

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

#573

Post by simiones »

lenkite wrote: post #553
simiones wrote: post #514

Earlier quoted context omitted.

You can, but then it's a lot of work to actually traverse that map, especially if you want error handling. Here is how it looks like for a pretty basic JSON string: https://go.dev/play/p/xkspENB80JZ . It's ~50 lines of code to access a single key in a three-layer-deep JSON.

Its more like 30 lines of code without the prints. However, one generally should code generic functions for this. The k8s apimachinery module has helper functions which is useful for this sort of stuff. Ex: `NestedFieldNoCopy` and its wrapper functions. https://github.com/kubernetes/apimachinery/blob/95b78024e3fe... Ideally, such `nested` map helper functions should be part of the stdlib.

Sure, in production you'd definitely want something like that, but the context was an interview exercise, I don't think you should go coding generic wrappers in that context.

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

#574

Post by kbolino »

randomdata wrote: post #385
kbolino wrote: post #375

Earlier quoted context omitted.

I think my comment was clear on the distinction between real and mock implementations. If the code was testable with no need for mocks then certainly remove the interface and devirtualize the method calls.

Your comment was clear about mocks, but not why mocks are relevant to the topic at hand. The original comment was equally clear that it was in reference to where there is only one implementation. In fact, just to make sure you didn't overlook that bit amid the other words, the author extracted that segment out into a secondary comment about that and that alone. Mocks, by definition, are always a supplemental implemen…

It is easy to generate mock implementation code (GoMock has mockgen, testify has mockery, etc.) The lack of a hand-rolled mock implementation doesn't mean that much. For example, many people do not like to put generated code under source control. So, just because you don't see a mock implementation right away doesn't mean one isn't meant to be there. Also, the original author of the function that consumed the apparently unnecessary interface type may have intended to test it, but not had the time to write the tests or generate the mocks. If we are going to be this pedantic, I did say "mockable" interface, implying the usefulness and possibility, but not necessarily existence, of a mock implementation.

Since we are examining code we can't see, we can only speak about it in the abstract. That means the discussion may be broader than just what one person contributes to it. If this offends you or the OP, that was not the intent, but in the spirit of constructive discussion, if you find my response so unhelpful, it is better to disregard it and move along than to repeat the same point over and over again.

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

#575

Post by infecto »

classified wrote: post #537
afiodorov wrote: post #462

I used to work for a Go shop. We dealt with financial data. I found it so annoying that many of my colleagues would use Go for one-off tasks such as aggregating CSV files, updating the database with some data, or fetching data from the database, and then trying to make a plot. I saw my colleagues again and again implementing basic algorithms such as rolling median, or finding a maximum. Instead of loading data into P…

> Instead of loading data into Pandas and doing a group by SQL can do `group by`. No need for overkill with "data science tools".

While definitely doable, using a SQL database to do data discovery is obtuse.

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

#576

Post by markusw »

I CAN’T BELIEVE NO-ONE HAS MENTIONED MY BEAUTIFUL TYPOGRAPHIC LAYOUT YET. :D

Just look at this beautiful test page [0]. I’m pretty sure I spent more time on that than on the blog post.

On a more serious note, thank you for all the discussion! It’s hard keeping up with all the comments, but I’m truly appreciative of the quality of discourse here.

Also, the newsletter subscription is up now, if you’re into that. [1]

[0]: https://www.maragu.dev/typography [1]: https://www.maragu.dev/blog/go-is-my-hammer-and-everything-i...

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

#577

Post by jen20 »

lenkite wrote: post #454
scubbo wrote: post #356

Earlier quoted context omitted.

Uh huh....and what comes next? Trying to descend more than a couple of layers into a GoLang JSON object is a mess of casts.

Well, one used to have https://github.com/mitchellh/mapstructure which assisted here, but the lib then got abandoned.

Blessed fork: https://github.com/go-viper/mapstructure

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

#578

Post by mjw_byrne »

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…

4. Stability and backwards-compatibility. I have never seen a Go version upgrade break anything. Meanwhile I have colleagues who do a thousand-yard-stare if you so much as mention upgrading the version of Python we're using.

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

#579

Post by aragilar »

dilyevsky wrote: post #244
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…

Numerical programs seems like a great fit for DSLs, say Starlark[0] ;-) That's what many C++ libs basically achieve with their heavy use of overloading, tmp, etc [0] - https://github.com/google/starlark-go or alternatively https://github.com/facebook/starlark-rust

But why would someone use a new DSL, vs an existing (general-purpose-ish) language that supports numerics (there are enough out there, e.g. R, Python, or the numerous paid ones like matlab, mathematica or IDL)? You have no ecosystem, plus now you're got to wrap 50+ years of numerical libraries...
Post reply on HN