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

731–740 of 816 posts

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

#731

Post by Kamq »

kaba0 wrote: post #435
Kamq wrote: post #353

Earlier quoted context omitted.

I mean, you're not wrong, It's just strings (usually) instead of ints. It's pretty bad, but it turns out that exceptions and inverting my entire program to pass into a Result's flatmap chain are even worse. When they come up with another strategy, I'll try that instead, but until then I'll keep using the least bad option I've found.

> It's pretty bad, but it turns out that exceptions and inverting my entire program to pass into a Result's flatmap chain are even worse Based on what? Exceptions do the sensible thing at all times: auto-bubbling up (no random swallowing), contain info about its origin, and a handler can be specified as tightly or widely as necessary. It’s objectively superior to grepping for an error message, or straight up not doin…

> Based on what?

My experience using all three.

> no random swallowing

We have not been in the same codebases, apparently. The number of times I've come across (I'm paraphrasing):

    try {
        // some stuff that can fail
        // bonus points if there's a comment explaining why it can't error in practice
    } catch (Exception e) {}
Is hilarious. Especially when it happens in library code.

As verbose as `if err != nil { return nil, err }` is, the fact that it gets banged out so much means people default to it, and I find myself less likely to get into a weird partially initialized state in go than I have been in other languages.

> It’s objectively superior to grepping for an error message

Then use `errors.Is`?

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

#732

Post by kerkeslager »

tome wrote: post #660
RandomThoughts3 wrote: post #609

Earlier quoted context omitted.

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?

The person you are responding to didn't say that, I did.

The abstractions I'm pointing at are cases where mutation or side effects are the desired result of execution. Ultimately this always runs up against having to grok a lot of different monads and that's simply never going to be as easy to understand as calling "print" or "break". Haskell works really well if the problems you're solving don't have a ton of weird edge cases, but often reality doesn't work like that.

The other thing is laziness which makes it hard to reason about performance. Note that I didn't say it's hard to reason about execution order--I think they did a good job of handling that.

Don't get me wrong, Haskell's dogmatic commitment to functional purity has led to the discovery of some powerful abstractions that have trickled out into other languages. That's extremely valuable work.

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

#733

Post by ratorx »

whateveracct wrote: post #628
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…

> I used to work for a Go shop. We dealt with financial data. Hopefully you never forgot to initialize a numeric field and had it default to 0!

I think you are implying that this is incorrect behaviour. Could you explain why?

The alternative would be to have it be undefined, which seems clearly worse. Or do you mean that it should be a compiler warning/error instead?

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

#734

Post by ratorx »

sanderjd wrote: post #568
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…

It has not been my experience that Go is good for almost everything. On the contrary, it seems good at a couple very specific (though very common) niches: network services and cli utilities. But for most of what I do right now - data heavy work - it has not turned out to be very good (IMO). It really is just not better in any way to have to constantly write manual loops to do anything.

I think Go is pretty OK as a language for building data pipelines (I’m assuming you meant statistical ones, but the same argument applies to more data transform-y ones). What it is not good for is doing exploratory analysis (which is where Python shines).

Manual loops are pretty annoying when the focus is on figuring out which loops to write (exploratory phase). However, they are pretty nice once you’ve figured it out and need write a durable bit of code where your prioritise readability over conciseness (productionisation).

Going from Python to between the exploratory phase and the productionised pipeline is going to be a pain, I don’t think Go is particularly worse than others. At that point it’s all about the classic software tradeoffs (performance vs velocity vs maintainability) and I didn’t think Go is a good choice in many situations.

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

#735

Post by kerkeslager »

mrkeen wrote: post #585
kerkeslager wrote: post #378

Earlier quoted context omitted.

"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…

> 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…

> Exceptions or return values? Nope, monadic error handling, any day of the week.

Ehhhh...

The thing is, there are a lot of cases where I can look at the code and I know the error won't happen because I'm not calling it that way. Sure, sometimes I get it wrong, but the fact is that not every application needs a level of reliability that's worth the effort of having to reason around error handling semi-explicitly to persuade the compiler that the error is handled, when it really doesn't need to be.

> Terse dynamic code, or bloated static code? Nope, terse code with full type inference.

I think you're significantly overselling this. Type inference is great, but you can't pretend that you don't have to implicitly work around types sometimes, resulting in some structures that would be terser in a dynamic language. Type inference is extremely valuable and I really don't want to use static types without it, but there are some tradeoffs between dynamic types and static types with type inference that you're not acknowledging. I think for a lot of problems Haskell wins here, but a lot of problems it doesn't.

One area I'm exploring with the interpreter I'm writing is strong, dynamic typing. The hypothesis is that the strictness of the types matters more than when they are checked (compile time or runtime). Python and Ruby I think both had this idea, but didn't take it far enough in my opinion, making compromises where they didn't need to.

> Terse nulls or nulls & boilerplate Optionals? Nope, just terse Optionals.

100% with you on this.

> First-order generics or no? Higher-kinded parametric polymorphism.

Ehhh, I feel like this is getting overly excited about something that simply isn't all that useful. I'm sure that there's some problem out there where higher-kinded types matter, or maybe I just lack vision, but I'm just not coming across any problems in my career where this feels like the solution.

I feel like there's a caveat I want to add to this but I'm not able to put my finger on it at the moment, so bear with me if I revise this statement a bit later. :)

> Multiprogramming via locking & shared memory or message passing? Hey how about I choose between shared-memory transactions or transactional message-passing instead?

Ehh, the languages I like are all using transactional message-passing anyway, and I'm pretty sure Haskell didn't invent this.

> There is little stuff happening outside of Haskell to be envious of. Java took a swing at the null problem with Optionals a decade ago. My IDE warns me not to use them. It's taking another swing with "Null-Restricted Value Class Types". I know your eyes glaze over when people rant about Haskell, but for two seconds, just picture yourself happily doing your day-to-day coding without the existence of nulls, and pretend you read a blog post about exciting new methods for detecting them.

I mean sure, I'm 100% with you on Option types, as I said. But, imagine being able to insert `print(a)` into your program to see what's in the `a` variable at a specific time. Hey, I know that's not pure, but it's still damn useful.

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

#736

Post by marcus_holmes »

simiones wrote: post #526
marcus_holmes wrote: post #417

Earlier quoted context omitted.

This. In $other_language you'll parse the JSON fine, but then smack into problems when the field you're expecting to be there isn't, or is in the wrong format, or the wrong type, etc. In Go, as always, this is up front and explicit. You hit that problem when you parse the JSON, not later when you try to use the resulting data.

Go's JSON decoder only cares if the fields that match have the expected JSON type (as in, list, object, floating point number, integer, or string). Anything else is ignored, and you'll just get bizarre data when you work with it later. For example, this will parse just fine [0]: type myvalue struct { First int `json:"first"` } type myobj struct { List []myvalue `json:"list"` } js := "{\"list\": [{\"second\": \"cde\"}…

It totally makes sense from a Go perspective: You created a struct, tried (but failed) to populate it with some json data, and ended up with a value initialised to its zero-value. This is fine :)

One of the techniques for dealing with JSON in Go is to not try to parse the entire JSON in one go, but to parse it using smaller structs that only partially match the JSON. e.g. if you endpoint returns either an int or a string, depending on the result, a single struct won't match. But two structs, one with an int and one with a string - that will parse the value and then you can work out which one it was.

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

#737

Post by [deleted] »

xigoi wrote: post #481
abtinf wrote: post #294

Earlier quoted context omitted.

Operator overloading essentially makes code unreadable without deep diving past the interface boundary. In Go, you can generally look at any snippet of code and know precisely what it does.

How is a + b any less “know precisely what it does” than a.add(b)? It’s literally just different syntax for the same thing.

[deleted]

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

#738

Post by noisy_boy »

theshrike79 wrote: post #511
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…

> I used to work for a Go shop. We dealt with financial data. People dealing with finance are THE MOST risk-averse people I know. No new tool will be used without years of vetting and it'll still be blamed if something goes wrong - even if the new tool never touched that bit of the process =) Source: Consulted for a finance company and it was Ye Olde Java and COBOL all the way down =)

People who are saying Finance == assembly/COBOL/Java either have never worked in the area or have decided about the elephant by touching a very small part it.

Within a bank, you can have the accounting department using tested and tried approaches and/or vendor products whereas the machine learning group may be using the latest tech. But finance is not all banks - you can have non-banking financial orgs, rating firms, investment consultancies, private equity, hedge funds and on and on. A hedge fund probably uses super cutting edge stuff in one team while the other has been chugging along with stored procedures and Java.

It is too big and varied to generalize.

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

#739

Post by bb88 »

aduwah wrote: post #490
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…

chore(omfg): fix print to print()

Fix print to logger.info() why not?
Post reply on HN