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

411–420 of 816 posts

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

#411

Post by randomdata »

anonymoushn wrote: post #404
randomdata wrote: post #394

Earlier quoted context omitted.

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.

The nil interface is another implementation. I mean, unless it is being used as the sole implementation, but I think we can assume that isn't the implementation being talked about given that it isn't a practical implementation. We're talking about where there is one implementation.

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

#412

Post by pjmlp »

l33t7332273 wrote: post #402
pjmlp wrote: post #397

Earlier quoted context omitted.

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)

It does a very crude one, where one is bound to expose C ABI types, all shared objects have to be linked with the same runtime, and there are still issues making this rather basic support work on Windows, land of game developers.

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

#413

Post by lelanthran »

claytongulick wrote: post #369
marcus_holmes wrote: post #362

Earlier quoted context omitted.

Go maps have a defined type (like map[string]string), so you can only put values of that type in them. A JSON object with (e.g) numbers in it will fail if you try and parse that into a map of strings. As others have said, the issue with Go parsing JSON is that Go doesn't handle unstructured data at all well, and most other languages consider JSON to be unstructured data. Go expects the JSON to be strongly typed and r…

I feel like good JSON handling is sort of table stakes for any language for me these days. The pain of dealing with JSON in Go is one of the primary reasons I stick mostly with nodejs for my api servers.

> The pain of dealing with JSON in Go is one of the primary reasons I stick mostly with nodejs for my api servers.

Unless you're dealing with JSON input that has missing fields, or unexpected fields, there is no pain. Go can natively turn a JSON payload into a struct as long as the payload's fields recursively match the struct's fields!

If, in any language, you're consuming or generating JSON that doesn't match a specific predetermined structure, you're yolo'ing it and all bets are off. Go makes this particualr footgun hard to do, while JS, Python, etc makes it the default.

Default footguns are a bad idea, not a good idea.

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

#414

Post by irjustin »

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…

ChatGPT accelerates this timeline significantly. As a senior programmer you can largely skip the "junior" phase of the learning, almost like pair programming with a very proficient junior programmer.

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

#415

Post by zeroc8 »

jillesvangurp wrote: post #139

I understand the sentiment. My goto hammer is Kotlin, which I like a bit better than Go. But that's a highly subjective thing of course. And I use plenty of other languages as well (including very occasionally some Go). It's not about what is better in general but about what is better for you. Better here means less time wasted with figuring out syntax, tools, APIs, frameworks, etc. Once you know how to do a certain…

But you also need the GUI part. Flutter seems to be the main competitor here. What's the current situation with Kotlin? Is there a decent Compose for Web yet?

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

#416

Post by p0w3n3d »

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…

I totally agree with you. Only after min 2 years of fully coding a viable production solution can one learn most of the pitfalls of given language. I would add frameworks which give another level of complexity and sometimes a framework is like a separate language.

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

#417

Post by marcus_holmes »

lelanthran wrote: post #413
claytongulick wrote: post #369

Earlier quoted context omitted.

I feel like good JSON handling is sort of table stakes for any language for me these days. The pain of dealing with JSON in Go is one of the primary reasons I stick mostly with nodejs for my api servers.

> The pain of dealing with JSON in Go is one of the primary reasons I stick mostly with nodejs for my api servers. Unless you're dealing with JSON input that has missing fields, or unexpected fields, there is no pain. Go can natively turn a JSON payload into a struct as long as the payload's fields recursively match the struct's fields! If, in any language, you're consuming or generating JSON that doesn't match a spe…

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.

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

#419

Post by sph »

bb88 wrote: post #377
saghm wrote: post #364

Earlier quoted context omitted.

> It is the time it takes to where you can start to meaningfully contribute to evolving how the language is used and meaningfully coach architects, programmers and system designers. It is also what you need to absorb novices into the organization and train them fast. I think these criteria in particular are much more than a lot of people mean when they say "learn a language", which would explain why their estimates a…

2012: Python is Awesome! 2014: Python is a great language, but there are a few pitfalls 2016: Python is a good language with the right IDE, tooling, and process. The people are pretty cool though. 2018: I like python, but I wish more people used type annotations. 2020: You know, metaclasses are freaking awesome! They saved me so much work! 2022: Why can't people code the most obvious solution in python? 2024: Celery!…

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 libraries to this day.

I haven't used Python in a personal project in 10 years because of these painful paper cuts .

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

#420

Post by anonymoushn »

randomdata wrote: post #411
anonymoushn wrote: post #404

Earlier quoted context omitted.

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.

The nil interface is another implementation. I mean, unless it is being used as the sole implementation, but I think we can assume that isn't the implementation being talked about given that it isn't a practical implementation. We're talking about where there is one implementation.

Right. Can you cite anything that says that the go compiler does this sort of whole-program analysis to try to prove that a certain argument to a function is always non-nil, so that it can change the signature of that function and the types of variables declared in other functions?
Post reply on HN