[flagged]
Lies we tell ourselves to keep using Golang (2022)
281–290 of 526 posts
Re: Lies we tell ourselves to keep using Golang (2022)
#282One thing what i observed is any language you right ask AI to optimize in Rust..why its so much of a debate when scale comes. In 6months AI will make any rewrite possible with full context aware. So don't spend your energy on things that can be done by machines and focus on things which u can get deep on for distributing the software.
Re: Lies we tell ourselves to keep using Golang (2022)
#283AI can rewrite any dream code which u write and putting ur brain on that is pure seless way of pointing start with some island as you pointed get to scale and in 6months every code can be rewritten how many ever time u want..tokens will be so affordable to run full context code base shift..don't worry about it just focus on distribution for ur product with the code you right..thats a good thing to worry about.
Re: Lies we tell ourselves to keep using Golang (2022)
#284Earlier quoted context omitted.
There are several shortcomings with go's error handling. The author heavily lies onto rust, so the alternative is not exceptions but a `Result ` sum type. No stacktraces and error wrapping forces you to not only invent unique error messages. You must also conceive a unique wrapping message at every call-site so that you can grep the error message and approximate a stacktrace. The weird "return tuple" , which obviousl…
Exceptions are sum types, they just have different syntactic sugar.
And different control flow, and different or sometimes non-existent types (Java's throws).
Re: Lies we tell ourselves to keep using Golang (2022)
#285This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…
Without fail, every single person I’ve seen rave about go’s error handling compares it only to exceptions as if that’s the only alternative. On the flip side I have yet to find a person who’s familiar with sum types (e.g., Maybe, Option, Result) that finds the golang approach even remotely acceptable.
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 what is happening.
As I pointed out I think Rust does it better with its types error handling. That isn’t too relevant for me though as Rust will probably never seem any form of adoption in my part of the world. I think Zig may have a better chance considering how interoperable it is with C, but around here the C++ folks are simply sticking with C++.
Re: Lies we tell ourselves to keep using Golang (2022)
#286> and most importantly, you adopted a language that happened by accident.
Is the author implying that Go was created by accident?
Re: Lies we tell ourselves to keep using Golang (2022)
#287Earlier quoted context omitted.
That is an interesting experience, as I find the opposite true in most of my cases. And I am a go developer that likes go and use it for 95% of my coding, including MMO servers. I love programming languages and have used and dabbled in many. I still go to go. And many go tools I use tend to be pretty well written. But maybe this is just a sample size of 1 vs a sample size of 1 issue.
From go programs at the very least I can expect they won't respect normal GNU getopt command line options, and work terribly with signals and going background in the terminal and so on. If it's a server, of course it won't support any way of communicating it's ready. Not the old fork way and certainly not the new sdnotify things.
why would it have to respect GNU getopt? When did that become the golden standard? I never respect getopt because I really don't care about it and it has no bearing on anything I build. As long as they are documented under `--help`. Almost everyone uses Cobra from command-line options. And it is capable of doing getopt if you want, but I don't see why it would be a requirement.
Signals and Backgrounding seem to be just developers that have little experience with that stuff. I can't remember the last time I did any sort of signal handling to do anything specific. And I haven't had issues with backgrounding, but that might be just the tools I use and the infrequency of backgrounding that I do.
Most servers I interact with or work on have some sort of `health` api endpoint to get that status because most servers in go are HTTP. What more are you expecting? I don't even know what you are referring to by the `old fork way` but I will agree most don't use sdnotify, as that makes the assumption you are running Go on something that handles systemd notifications.
I am fairly certain a majority of Go servers run in a container, specifically an Alpine, distroless, or scratch container. So communication would be over stdout or some kind of API endpoint, be it HTTP, GRPC, or any other TCP/UDP endpoint.
Re: Lies we tell ourselves to keep using Golang (2022)
#288Earlier quoted context omitted.
Having programmed for over 30 years, including nearly a decade of C#, I would say exceptions are one of the worst ideas in all of programming. They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about. Even junior enginee…
But with Exceptions you can easily implement multiple return types in e.g. Java ;) I shocked my Professor at university with that statement. After I started laughing, he asked me more questions... still went away with a straight A ;D
In OCaml, that's actually a common use for exceptions, as they let you unwind extremely quickly and carry a result (helped by the fact that OCaml doesn't have finally or destructors).
Re: Lies we tell ourselves to keep using Golang (2022)
#289It really does not matter. There are so many critical services running off of Go. You don't wanna use it? Go to hell.
Re: Lies we tell ourselves to keep using Golang (2022)
#290Earlier quoted context omitted.
Go’s type system is not even impressive compared to python’s .
Do you have a pydantic equivalent in go? Also modern typing in python is starting to be OK to be honest (well, if you consider typescript typing OK), so it isn't really a knock on Go :)
> Do you have a pydantic equivalent in go?
I've been working on one [1].
But gosh, does go make it hard.