Then why am I still messing around with Axum and friends and people using Go are shipping microservices like there's no tomorrow?
Lies we tell ourselves to keep using Golang (2022)
471–480 of 526 posts
Re: Lies we tell ourselves to keep using Golang (2022)
#472Earlier quoted context omitted.
I am not sure how would that work? F.ex. how would you introduce tagged unions and make the language 100% backwards-compatible... but not the stdlib? I admit I have no idea.
The stdlib would remain 100% backwards compatible, but the implication was that he would want to see certain existing features of the stdlib amended with modified versions that leverage the new tagged unions. He imagined that modification would necessitate v2 stdlib packages to maintain sensibility.
Oh. Silly me, I am ashamed for failing reading comprehension so badly.
Thanks for clarifying, that makes sense.
Re: Lies we tell ourselves to keep using Golang (2022)
#473I feel like the author is fed up with being disagreed with, yet makes very opinionated statements about how others should (or will, at some point in the future) feel. They make good points about problems in Go, but I gotta say they also make a lot of points that might never become a problem at all. I've written code that runs in production for 20 years now and every language I ever shipped software with, from ASP, PH…
Took some time to read the linked Tailscale blog posts as examples of horrible hacking around Go. And I would agree it's crazy for a product oriented startup to do this, but this team is also made up of people that have contributed a lot to several core parts of the Go runtime.
Since these blog posts were written, Go has made official the interning approach that the netaddr.IP type depended on, now without the horrible pointer hacks, and the IP type itself has been migrated into an official package with even more improvements, now benefitting everyone. The iOS network extension memory problem was a very nice deep dive into what happens behind the scenes (something that is assuredly not perfect in any language) and resulted in a better Go experience for everyone using the language.
So a team pushed the limits of a language and made the language better for everyone out of the box. This happens in most languages, but rarely do you see such approachable blog posts about it, where the solutions are readable in the language itself, and with enough commentary even understandable.
I recommend reading these articles as examples of good language evolution, not as examples of a broken language.
Re: Lies we tell ourselves to keep using Golang (2022)
#474Earlier quoted context omitted.
I see it used often, even in languages that don't formally support multiple return arguments – with some hacked up array/object single value return to try and emulate what would be better represented as multiple return arguments. Like I mentioned in another comment, Go does seem especially prone to attracting developers familiar with other languages who insist on trying to continue to program in those other languages…
The pragmatically "right" choice is to have some tuple type built-in. Because they are not only very good for function in/out, they can be used in many more places. Lists of tuples, tuples in structs, etc. If the language doesn't have tuples, then you have to "roll your own" and emulate them every single time , but it's not a functor so you can't do all the useful stuff. Go didn't do the pragmatically right choice, b…
> The pragmatically "right" choice is to have some tuple type built-in.
Perhaps, but in practice we end up with these ill-conceived languages that support tuples but end up not embracing them. Consider, for example, this Rust function:
fn process_tuples(tuple1: (i32, i32), tuple2: (i32, i32), tuple3: (i32, i32))
fn process_tuples(tuples: ((i32, i32), (i32, i32), (i32, i32)))
And once you accept the theoretical unsoundness of a function having its own tuple concept for input, it naturally follows that it needs to also extend that concept to returns. After all, the most basic function is an identity function. What would be super weird is not being able to write an identity function any time the number of inputs is greater than one.
Go needed to allow multiple outputs because functions can accept multiple inputs.
Re: Lies we tell ourselves to keep using Golang (2022)
#475Earlier quoted context omitted.
> When did that become the golden standard? 30 years ago? > Signals and Backgrounding seem to be just developers that have little experience with that stuff. Yes, go developers have little experience. I see we agree. > What more are you expecting? Them to tell systemd they started. > I don't even know what you are referring to by the `old fork way` As I said, most go developers have little experience. I see you agree…
> 30 years ago? I have yet to find a developer, go or otherwise, that cares strongly enough about getopt outside the hardcore FOSS groups that pays attention to this. I know of getopt, and I don't follow it, because no one ever told me to was the golden standard, I was under the impression it was one of many ways, not the only way, especially if you work with systems like Windows at any point, that doesn't follow it…
> I have yet to find a developer […]
Users care, because that's how all the other commands work. It's the standard whether you like it or not. Of course you can choose to do the snowflake CLI, but that doesn't really shout "experienced dev" does it?
> windows
oh lol… what % of go programs is used on windows? 1? 2?
> Why?
So systemd can start the other service that depends on that one?
You need to know when the docker daemon is up and running before starting your containers no?
You don't know how to do a thing that anyone writing a server process should know.
Yes you're further and further proving my point that go developers are on average less experienced. And you seem ok with that except when it's pointed out.
> maybe open a PR
I have far more FOSS contributions than you do. Mostly in C/C++ or Python.
> Maybe take the time to be open minded instead of calling the entire Go dev ecosystem "inexperienced"
Maybe take the criticism instead of getting angry.
Re: Lies we tell ourselves to keep using Golang (2022)
#476Earlier quoted context omitted.
> 30 years ago? I have yet to find a developer, go or otherwise, that cares strongly enough about getopt outside the hardcore FOSS groups that pays attention to this. I know of getopt, and I don't follow it, because no one ever told me to was the golden standard, I was under the impression it was one of many ways, not the only way, especially if you work with systems like Windows at any point, that doesn't follow it…
> I have yet to find a developer […] Users care, because that's how all the other commands work. It's the standard whether you like it or not. Of course you can choose to do the snowflake CLI, but that doesn't really shout "experienced dev" does it? > windows oh lol… what % of go programs is used on windows? 1? 2? > Why? So systemd can start the other service that depends on that one? You need to know when the docker…
> Users care, because that's how all the other commands work. It's the standard whether you like it or not. Of course you can choose to do the snowflake CLI, but that doesn't really shout "experienced dev" does it?
I have never had a user complain about this. They just read the readme or the `help` and use it accordingly.
> oh lol… what % of go programs is used on windows? 1? 2?
I am sure it is quite a bit more than that, especially since I tend to see `exe` builds for most go tools I have used.
> You don't know how to do a thing that anyone writing a server process should know.
Oh I know it, I just don't think it is relevant for my day to day, or most of the go-made servers or tools I run.
Another thing that you seem to be assuming is that I am waiting for daemons to start. I used the term Containers instead of Docker specifically because the majority of them are in Kubernetes, or get converted to VMs for services like Fly.io. In those situations the daemon, or equivalent, is already running. I also use Podman, which doesn't have a daemon unless you need one.
And in the few cases where I would have needed to wait, I poll the docker unix socket for the /info path, and get the information that way.
> I have far more FOSS contributions than you do. Mostly in C/C++ or Python.
I never argued that, I have a paltry amount of FOSS contributions compared to most people interested in open source. I just said that if it matters so much to you that you are willing to label an entire dev community as inexperienced, and act all high and mighty about some standards that aren't seen as important these days, then you should teach us how to be better. Open that PR and show us the way. Obviously there is only 1 way to do things, and you are already well versed in it, guide us out of the dark hole we apparently live in.
> Maybe take the criticism instead of getting angry.
I am not in the least bit angry. I am discussing this, because I believe you are stuck in old ways and not adapting to the changes in the industry and development, especially in the areas where Go is used most, which is servers, devops, containers, and the like.
Also, I acknowledge there are industries, environments, etc that can't or won't use containers. But that is a small percentage of use-cases, and the engineers there are probably building things properly.
I will also never say no to implementing such a thing if I get an issue opened requesting it, a PR opened to add it for me, or the like. But I have not seen a need for it in years, both professionally or personally, to be added right away. And I feel like majority of Go devs have nothing against it, and would add it if requested. I know Miniflux for example, after their V2 rewrite into Go, added it 8 months later, due to a request. and have been maintaining/improving it since.
I had no clue how the sd_notify support was in Go in general, until this conversation with you. Not because I wasn't aware of sd_notify, I just never had to go looking for it or needed it. Took me 10 seconds to google it, find a library that saves me time, and I can add it to any server I need it in now. But I will do that if needed, not pre-emptively. Especially since 95% of the servers I make are for work, and dont need systemd. And personal stuff doesn't need it either. But if I opensource anything, and it is requested? I will add it without much fanfare.
Re: Lies we tell ourselves to keep using Golang (2022)
#477Earlier quoted context omitted.
Interestingly, every time (and I mean _every_ time) that I've tried to use `errors.As` on errors raised by lib code, I found out that the lib just went with "nah, I'm just going to use `errors.New` or `fmt.Errorf`", which makes the error impossible to match. So... I'd say that this is a fumble in the design of Go.
%W exists to solve this
It would, if people actually defined new errors. But, as I mentioned in my message, people just use `errors.New` or `fmt.Errorf`, all the way down, so you end up with errors that cannot be matched. Which means, in turn, that if these are errors that should be handled properly (and not just propagated/logged), they cannot.
Re: Lies we tell ourselves to keep using Golang (2022)
#478Earlier quoted context omitted.
> what's the difference between your program and one with exceptions Because errors as values are explicit. You're not forced to use ? everywhere; you can still process errors however you like, or return them directly to the calling function so they deal with it. They're not separate control flow like exceptions, and they're not a mess like Go's.
No, because you end up with a function coloring problem that way. A function that returns something other than Result has to either call only infallible code or panic on error, and since something can go wrong in most code, the whole codebase converges as time goes to infinity on having Result everywhere. Yeah, yeah, you can say it's explicit and you can handle it how you want and so on, but the overall effect is jus…
"Function coloring problem"
Function coloring isnt a problem, it is just approach
Re: Lies we tell ourselves to keep using Golang (2022)
#479Earlier quoted context omitted.
I think it’s because Go is an alternative to Java and C# more so than an alternative to Rust. It is for me at least. As I said, Rust isn’t seeing any form of real world adoption in my region while Go is. Go isn’t replacing C/C++ or even Python though, it’s replacing Typescript, C# and Java. Now, there are a lot of good reasons as to why Go shouldn’t be doing that, a lot of them listed in the article, but that’s still…
> Now, there are a lot of good reasons as to why Go shouldn’t be doing that I disagree. Typescript, C# and Java are terrible languages (as are Python/Ruby/etc. in other ways). Golang is bad by OP's standards but there's nothing wrong with it gaining ground on those languages. Besides it's also easier to convert a codebase to Rust from Golang than Typescript or C#/Java.
C# is the best designed lang out of the top10 most popular langs
Re: Lies we tell ourselves to keep using Golang (2022)
#480Earlier quoted context omitted.
> A segfault is a security vulnerability :) Fair enough. > I expect a modern programming language that has a runtime to not do that, correct. But how do you define "has a runtime"? Java clearly has one - the JVM. Go produces standalone code, though. Or do you say that it has a runtime because it has a garbage collector that is running while the program runs? The original Pascal didn't have a runtime (if you weren't u…
> Go produces standalone code, though. So if I put the jvm and my .jar file inside a single .zip file java no longer has a runtime? And since C applications load .so files they do have a runtime? Having a runtime is independent of the amount of files you need to read to run the program.
So, I'll ask more explicitly: what's your definition of "having a runtime"?