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

781–790 of 816 posts

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

#781

Post by ryanjshaw »

Daishiman wrote: post #722
ryanjshaw wrote: post #652

Earlier quoted context omitted.

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

Setting up a requirements.txt file and venv is _not_ a difficult ask. Seems like a skills issue here frankly.

Your attitude towards a new developer in the community is disappointing.

I just wrote in detail why I found it difficult/unintuitive and you dismissed everything without addressing it.

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

#782

Post by kerkeslager »

tome wrote: post #749
kerkeslager wrote: post #732

Earlier quoted context omitted.

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…

> The person you are responding to didn't say that, I did. Ah, thanks, I got confused. > 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. In my experience it's completely the opposite, actually. I can only really write code that correctly handles a ton of weird edge cases in Haskell. It seems that many people think that Haskell is…

> Granted, that is noisier than the Python, despite being a direct translation.

My complaint isn't the noise. My complaint is: can you explain what withJump does? Like, not the intention of it, but what it actually does? This is a rhetorical question--I know what it does--but if you work through the exercise of explaining it as if to a beginner, I think you'll quickly see that this is isn't trivial.

> 1. You don't get weird semantics around mutating the loop variable, and it remaining in scope after loop exit

Is this an upside? It's certainly unintuitive, but I can't think of a case this has ever caused a problem for me in real code.

> 2. You can "break" through any number of nested loops, not just to the nearest enclosing loop (which is actually more useful when dealing with weird edge cases, not less)

Again, is this actually a problem? Any high school kid learning Python can figure out how to set a flag to exit a loop. It's not elegant or pretty, but does it actually cause any complexity? Is it actually hard to understand?

And lots of languages now have labeled breaks.

Arguably the Lua solution (gotos) is the cleaner solution here, but that's not popular. :)

> 3. You can see exactly what effects are possible in any part of the program (which again is actually more useful when dealing with weird edge cases, not less)

What does this even mean? In concrete terms, why do you think I can't see what effects are possible in Python, and what problems does that cause?

In all three of the cases that you mention, I can see a sort of aesthetic beauty to the Haskell solution, which I appreciate. But my clients don't look at my code, they look at the results of running my code.

> Regarding laziness and performance, that is a resolved issue. I have an article that explains that: http://h2.jaguarpaw.co.uk/posts/make-invalid-laziness-unrepr...

The fact that you need a blog post to tell people how to resolve an issue exemplifies my point that this is not resolved. Nobody needs to be told how to turn off laziness in Python, because it's not turned on.

The fact is, Haskell does the wrong thing by default here, and even if you write your code to evaluate eagerly, you're going to end up interfacing with libraries where someone didn't do that. Laziness still gets advertised up front as being one of the awesome things about Haskell, and while experience Haskell developers are usually disillusioned with laziness, many Haskell developers well into the intermediate level still write lazy code because they were told early on that it's great, and haven't yet experienced enough pain with it to see the problems.

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

#783

Post by pantsforbirds »

Daishiman wrote: post #721
ansgri wrote: post #715

Earlier quoted context omitted.

This comment might finally push me to try DuckDB, thanks. I’m quite proficient with scientific python in general, but Pandas API is just alien (and slow). SQL is more natural for its domain.

How's DuckDB better than using SQLite on an in-memory DB?

It's designed for analytics work. Some examples: * You could run a bunch of analytics queries directly on a jsonlines, csv, or parquet file (or even glob of files). * You can output directly to a pandas or polars dataframe * You can use numeric python functions inside of queries * You can also attach to S3 buckets, postgres databases, or sqlite databases and query them directly.

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

#784

Post by quibono »

matwood wrote: post #286
stuff4ben wrote: post #124

Earlier quoted context omitted.

Damn, everything new really is old again. Everyone said the same thing about Java. Yet it still works and gets the job done. Go does as well. I'd rather poke my eyes out with a nail than use Python.

> I'd rather poke my eyes out with a nail than use Python. Glad I'm not the only one. Every time I'm forced to use Python I cringe. What version disaster and I'm going to run into today? The 2->3 transition happened a long time ago at this point and I still run into lingering effects. Also, for short 'script' like things Python doesn't feel any quicker or easier to write. Go is my Goto (hehe) for short scripts. And w…

> The 2->3 transition happened a long time ago at this point and I still run into lingering effects.

Interesting. I read about this a lot and I feel like it's a gimmick at this point. What lingering effects of the Py2->Py3 transition do you run into?

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

#785

Post by kerkeslager »

kerkeslager wrote: post #782
tome wrote: post #749

Earlier quoted context omitted.

> The person you are responding to didn't say that, I did. Ah, thanks, I got confused. > 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. In my experience it's completely the opposite, actually. I can only really write code that correctly handles a ton of weird edge cases in Haskell. It seems that many people think that Haskell is…

> Granted, that is noisier than the Python, despite being a direct translation. My complaint isn't the noise. My complaint is: can you explain what withJump does? Like, not the intention of it, but what it actually does? This is a rhetorical question--I know what it does--but if you work through the exercise of explaining it as if to a beginner, I think you'll quickly see that this is isn't trivial. > 1. You don't ge…

Also, you need a 3rd party library to handle something this basic...

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

#786

Post by marcus_holmes »

lelanthran wrote: post #747
marcus_holmes wrote: post #736

Earlier quoted context omitted.

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

> 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 :) To me it looks like a footgun: if the parsing failed then an error should have been signalled. In this case, there is no error and you silently get the wrong value.

Yeah, I presented that wrong. It's not actually a failure as such.

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

#787

Post by marcus_holmes »

simiones wrote: post #752
marcus_holmes wrote: post #736

Earlier quoted context omitted.

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

> 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 :) I do agree that there are good reasons on why this behaves the way it does, but I don't think the reason you cite is good. The implementation detail of generating a 0 value is not a good reason for why you'd implement JSON…

> I have no idea what you mean here. json.Unmarshal() is an all-or-nothing operation. Are you saying it's common practice to use json.Decoder instead?

No, I mean you create a struct that deals with only a part of the JSON, and do multiple calls to Unmarshal. Each struct gets either populated or left at its zero-value depending on what the json looks like. It's useful for parsing json data that has a variable schema depending on what the result was.

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

#788

Post by tgv »

GraduateDescent wrote: post #539
tgv wrote: post #430

Earlier quoted context omitted.

- Typescript doesn't protect you at all against external data. - A Go program runs single-threaded, unless you explicitly tell it not too, so I don't quite see that as a plus for Typescript. - Go is quite a bit faster than Typescript. - I haven't had a versioning problem in Go, and I can still compile and run old code. Typescript still beats Python in that respect, but Go wins stability. And I say this as someone who…

If you want TS-supported deserialization, just use runtime schema validation. I don't see the issue. It's dead-simple and is the way everyone does it.

Sure that's good advice, but it was a comparison of language features.

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

#789

Post by tgv »

sapiogram wrote: post #503
tgv wrote: post #430

Earlier quoted context omitted.

- Typescript doesn't protect you at all against external data. - A Go program runs single-threaded, unless you explicitly tell it not too, so I don't quite see that as a plus for Typescript. - Go is quite a bit faster than Typescript. - I haven't had a versioning problem in Go, and I can still compile and run old code. Typescript still beats Python in that respect, but Go wins stability. And I say this as someone who…

> - A Go program runs single-threaded, unless you explicitly tell it not too, so I don't quite see that as a plus for Typescript. I don't think this is a fair comparison. Almost all software needs some kind of concurrency, and multi-threading is the only way to do concurrency in Go. For example, the http server in Go's stdlib runs each request in its own goroutine, which I guess you technically asked for, but also ca…

That means you think it's a good idea that a JS/TS server handles everything on a single thread, which doesn't sound like an advantage.

BTW, you can also start multiple processes in go instead of go routines. There's probably a Worker-like library for it.

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

#790

Post by tome »

kerkeslager wrote: post #785
kerkeslager wrote: post #782

Earlier quoted context omitted.

> Granted, that is noisier than the Python, despite being a direct translation. My complaint isn't the noise. My complaint is: can you explain what withJump does? Like, not the intention of it, but what it actually does? This is a rhetorical question--I know what it does--but if you work through the exercise of explaining it as if to a beginner, I think you'll quickly see that this is isn't trivial. > 1. You don't ge…

Also, you need a 3rd party library to handle something this basic...

Haskell has a long history of a small base library with a lot of essential functionality being provided as third party libraries, including mtl and transformers (monad transformers), vector (an array library). Even time (a time library) and text (Unicode strings) are third party, by some definitions (they aren't part of the base library but they are shipped with the compiler).

Some people think that's fine, some people think it's annoying. I personally think it's great because it allows for a great deal of separate evolution.

Post reply on HN