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

651–660 of 816 posts

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

#651

Post by RandomThoughts3 »

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…

> rolling median, or finding a maximum

The real question is why are you writing code to make a plot when you can load a csv in excel and get a clean plot in 2 minutes.

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

#652

Post by ryanjshaw »

derriz wrote: post #494
sph wrote: post #419

Earlier quoted context omitted.

2012: Python is Awesome! 2014: Python is a pain in the butt to manage packages and dependencies, how the hell am I gonna deploy this? It's still a mess 10 years later unless you live deep in the ecosystem and know what third-party solutions du jour to manage that complexity. At least we have Docker now. Also let's not forget the Python 3 migration fiasco that lasted ~2008-2018 and I still find myself porting librarie…

At least for Python dependency management, I'd hardly call it a mess these days and yes it was a horrible 10 years ago. The de-facto standard of venv and pip (using a requirements.txt file) is generally painless these days. To the extent that moving between MacOS, Linux and Windows is feasible for most (of my) Python work. And the Python 2/3 pain stopped being an issue a few years back. I haven't been forced because…

I started using Dagster a few days ago, which runs on Python.

As far as I can tell, I have to install the packages with pip. Wait - don't forget venv first. Oh but I'm not supposed to commit the venv, so how is anybody to know what I did? Okay I have to setup a requirements.txt... but now what did I install in the venv? Okay there's a way to dump the venv.. but it's giving me all the dependencies, not the root package I installed?!

Okay there's something called pipenv that seems smart... Oh wait no this Dagster has a pyproject.toml, maybe I should use poetry? Wait poetry doesn't work, it seems like I'm supposed to use setup.py... so what's the point of pyproject.toml.

Okay I put the package into the setup.py. Great now I have to figure out the correct version dependencies by hand?! I don't get it, python is a nightmare.

Compare to .NET: dotnet add package

On build: dotnet run # automatically restores packages to a project level scope

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

#653

Post by jamwt »

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…

IME, engineers and "the discourse" when we argue on the Internet often conflate "ease of use" and "ease of learning". When we say "ease of use", we usually mean "ease of learning."

If you're a hobbyist, yeah, you should heavily value "ease of learning." If you're a professional, the learning curve is worth it if the tool's every day leverage is very high once you're ramped up. Too many developers don't put those 3-4 months in, in part due to the over-emphasis on "ease of learning" in our discussions/evaluations of things.

I was a part of a very large go project (https://news.ycombinator.com/item?id=11282948) and go-based company infra generally some years ago, and go is emblematic of the classic tool that is amazing at ease of learning, and quite mediocre at "ease of use" as time goes on.

I personally end up resenting those tools because I feel tricked or condescended to. (This is a little silly, but emotions are silly.)

I'd wager this is also why Rust is a perennial "most loved" winner in the surveys: it gets better as your relationship with it deepens, and it keeps its promises. Developers highly value integrity over trickery, and hard-earned but deep value feels like integrity and wins in the long run. (other examples: VIM, *nix, git)

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

#654

Post by shepherdjerred »

funny_falcon wrote: post #403
shepherdjerred wrote: post #360

Earlier quoted context omitted.

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).

You're misunderstanding what I'm saying. How the language works is relatively simple. Understanding what's going on when problems arise isn't.

* "how is my Cobra command being registered when I'm not calling any code?" -> "oh, there's an init function that registers the command when imported"

* "why is this variable not working?" -> "oh, it's that for loop thing again"

* "why does the result of my unit tests depend on the order of test execution?" -> "oh, we have 150 Cobra commands in one package with variables shared between _all_ of those commands"

* "how is this variable being set?" -> "oh, we have to call go build with a monstrous ldflags argument

* "why is CI not passing for this oneliner when this looked fine locally?" -> "oh, it's a linux-only file so the IDE isn't even showing me simple syntax errors"

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

#655

Post by anthk »

okasaki wrote: post #546
theshrike79 wrote: post #513

Earlier quoted context omitted.

It still won't beat the deployment speed of scp executable user@host:direc/tory/ that you get with Go. I still use python for stuff that never leaves my computer, but in most cases if I know I need to run it on Someone Else's Machine (or even a server of mine) I'll reach for Go instead.

At the expense of absolutely massive, gargantuan, entire-OS-sized binaries. Just looking at my bin/ folder eg k9salpha - a relatively simple curses app - 56MB argocd - a cli for magaging argocd - 155MB

        strip --strip-all k9salpha argocd

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

#656

Post by didntcheck »

neonsunset wrote: post #202
thornewolf wrote: post #161

Earlier quoted context omitted.

I argue: - The list comprehension is ever slightly more readable. (Small Positive) - It is a bit faster to write the code for the Python variant. (Small Positive) So this would be a small positive when using Python. Furthermore, I believe there is this "small positive" trade-off on nearly every aspect of Python, when compared to Go. It makes me wonder why someone might prefer Go to Python in almost any context. Some…

Rust: let results = foo .into_iter() .filter(|s| s.contains("banned")) .collect:: >(); C#: var results = foo .Where(s => s.Contains("banned")) .ToArray(); Convenient, easy to understand and fast.

And I think Kotlin would just be

    val results = foo.filter { "banned" in it}
Though I'm not sure I'm a fan of it eagerly finishing with a List. If you chained several operations you could accidentally be wasting a load of allocations (with the solution being to start with foo.asSequence() instead)

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

#658

Post by Dylan16807 »

randomdata wrote: post #636
Dylan16807 wrote: post #625

Earlier quoted context omitted.

If a nil is another implementation then interfaces with a single implementation don't exist.

Given the following, where is the nil implementation found? package main type FooInterface interface { Baz() } func bar(fizz FooInterface) { bizz.Baz() } type MyFoo struct{} func (*MyFoo) Baz() {} func main() { var foo FooInterface = &MyFoo{} bar(foo) }

Nil is built-in. You just have to write the code to instantiate it and the compiler gives you one. The coder does not need to create an implementation, it's there for free.

I would not have called it a "second implementation" myself, but that's your claim to defend, not mine.

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

#659

Post by theshrike79 »

kamov wrote: post #611
theshrike79 wrote: post #515

Earlier quoted context omitted.

I'll take verbose and simple code over terse trickery every day. People who disagree have never had to wake up at 3 in the morning to fix a critical production issue in someone else's code. And that someone else really loved "elegant and terse" code. It's not fun to grok your brain around weird language trickery when you're half-awake and in a hurry to fix stuff before the customers wake up.

I personally think that writing so called "terse, clever" (misnomer) code, is not an issue with the language, rather the user. Do we really want to have worse tools, just because some people are writing bad code? Clearly it's an issue with the software engineering process rather than language itself. A good language should allow a skilled user to write code as clear as day, while properly modelling the problem domain…

> is not an issue with the language, rather the user

Go actively prevents you from writing stupid code, it doesn't give you the tools to do cool code golf tricks

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

#660

Post by tome »

RandomThoughts3 wrote: post #609
mrkeen wrote: post #585

Earlier quoted context omitted.

> Attacking Haskell is sort of a straw man--so far I haven't seen anyone in this thread propose Haskell as a go alternative. I think we agree Haskell is far too dogmatic about its abstractions when it's impractical to be used as a general-purpose language (because I don't think it's intended as a general-purpose language). I'll be that guy. We like our stuff in Haskell. Watching the rest of the industry move forward…

The issue is not language semantic. The issue is readability. Having the best feature set in the world is useless if the code produced by others is a pain to decipher. Haskell disqualified itself for general programming when its community decided that point-free was desirable despite the style being impossible to read and custom operators were a good thing. I personally hate every Haskell code base I have ever seen d…

So when you said

> I think we agree Haskell is far too dogmatic about its abstractions when it's impractical to be used as a general-purpose language

did you mean "sometimes some Haskellers use point-free style and it's impossible to read"? If not, could you explain what you did mean?

Post reply on HN