Live data from Hacker News

Go is my hammer, and everything is a nail

maragu.dev

661–670 of 816 posts

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

#661
post #377

Earlier quoted context omitted.

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

hah my journey was -- man im 100s of lines in what is the type of this thing that I am passing? ... man i really wish i had types or at least hints and then we got type hints but then I think more of my work will be moving to go anyway why is packaging still broken?

I only dabbled with Python occasionally in college, and the lack of types was my biggest obstacle. Even reading the official documentation of libraries, I still couldn't figure out what I should expect from whatever function I was calling.

I recall the Selenium library I was using as a particularly gnarly offender -- pretty much every function I called, I had to debug or `print(typeof(x))` to figure out what I'd gotten back.

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

#662
post #543

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.

Sure but that's not going to work across platforms, right? So not really an apples to apples comparison.

Like the sibling comment said, cross-compiling is literally setting two environment variables.

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

#663

Earlier quoted context omitted.

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)

Of course. This was just to illustrate the point, whether to snapshot/collect a sequence or not is another matter entirely. It just goes to show that idiomatic and fast* iterator expressions is something that modern general-purpose PLs are ought to have.

* I know little about performance characteristics of Kotlin but assume it is subject to behaviors similar to Java as run by OpenJDK/GraalVM. Perhaps similar caveats as with F#?

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

#664
post #543

Earlier quoted context omitted.

Sure but that's not going to work across platforms, right? So not really an apples to apples comparison.

Even the most ardent of Go-haters have to be fair and admit it makes cross-compilation really nice. GOOS=linux GOARCH=amd64 go build && scp executable user@host:direc/tory/ Out of the box, no toolchains to manage.

This is pretty much what I do.

I have a Taskfile for local compilation and running (macOS) and when I need to release I can just say `task publish` and it'll cross-compile a Linux binary and copy it to my server.

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

#665
It's really nice that Go and Rust have one standard package management system, and a built-in standard formatter. Both of these things seem obvious now, but they were innovative when they were introduced. They add a new set of "batteries" to the "batteries-included" mindset. And they put community and ease-of-use first, which are crucial for adoption.

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

#666
I'm totally with this idea - use the language you know best for mundane tasks.

I used to switch to shell or Python to do one-off scripts. But there's not a super great reason why I can't do the same in C++, which is what I know best. All the build stuff is easy to do in my company's repo, so that's not a big blocker.

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

#667

Earlier quoted context omitted.

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

If you have a csv, pandas is the "less overkill" route than loading it into a database to use sql.

Each their own tool, but that's nothing awk can't do [1]. I prefer a shell script, because shell is everywhere.

[1] https://stackoverflow.com/a/75073649

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

#668

Earlier quoted context omitted.

hah my journey was -- man im 100s of lines in what is the type of this thing that I am passing? ... man i really wish i had types or at least hints and then we got type hints but then I think more of my work will be moving to go anyway why is packaging still broken?

I only dabbled with Python occasionally in college, and the lack of types was my biggest obstacle. Even reading the official documentation of libraries, I still couldn't figure out what I should expect from whatever function I was calling. I recall the Selenium library I was using as a particularly gnarly offender -- pretty much every function I called, I had to debug or `print(typeof(x))` to figure out what I'd gott…

yeah ... i've become far more disenchanted with loosely typed languages. It's amazing to be able to quickly script things together and focus on the happy path in one-off scripts and bash-replacements but ... in a huge system when reasoning about what's going on -- I find it far more rewarding to know exactly what the type of a thing is and what it can do, etc., etc., and here with Python I rely on the editor a ton and I don't really like that.

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

#669

Earlier quoted context omitted.

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.

map is also built-in. Where do you find the hash map in the given program?

By your logic some nebulous package in a random GitHub repository that happens to satisfy an interface is also another implementation, but you would have to be completely out to lunch to think that fits with the topic of discussion.

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

#670
post #304

Earlier quoted context omitted.

I should say what 3D game engines use Go?*

Not sure if you're being intentionally cheeky by pointing out a use case one wouldn't use Go for but will answer anyway. A language with a GC (like go) typically isn't a good fit for a 3d engine. Almost all serious engines are C++, at least for the core code, for that reason.

> pointing out a use case one wouldn't use Go for but will answer anyway.

The thread is about using Go everywhere and I make games so I'm asking about it.

Unity and Godot have C# scripting which most game code will be in. Unreal has garbage collecting for game assets. GC is just another tradeoff to work with and certainly not a deal breaker for games.

I'm mostly curious about whether someone has done the work to integrate goroutines with a 3D engine in a performant way as typical techniques require a lot of synchronization with native threads that seem at odds with Go's design. But I'm curious to see it done.

Post reply on HN