Earlier quoted context omitted.
> but do I really know without performing a benchmark? Not really. But that’s one of Rob Pikes rules [1], I think the intention is to write whatever is simplest and optimize later. The programmer doesn’t need to remember 100 rules about how memory is allocated in different situations. [1] https://users.ece.utexas.edu/~adnan/pike.html
I mean it's a great idea, and I fully agree that I do not want to worry about memory allocation. So then why is `make` a thing? And why is `new` a thing? And why can't I take an address to a primitive/literal? And yet I can still take an address to a struct initialization? And why can't I take an address to anything that's returned by a function?
Lies we tell ourselves to keep using Golang (2022)
331–340 of 526 posts
Re: Lies we tell ourselves to keep using Golang (2022)
#332Earlier 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…
Well, I've also programmed for over thirty years and I wouldn't use a language without exceptions and even wrote a whole essay defending that position: https://blog.plan99.net/what-s-wrong-with-exceptions-nothing... > Even junior engineers have a trivial time debugging most go errors Not my experience at all. I had to do this once. An HTTP request to a production server was yielding a 400 Bad Request with no useful i…
> Useless: the server was written in Go and the logs had no information about where the error was originating. [...] In a language with exceptions there'd have been a stack trace that pinpointed exactly where the error originated
Go has support for exceptions, not to mention providing runtime access to stack trace information in general. They are most definitely there if your application requirements necessitate, which it seems yours did. Unfortunately, language support only helps if your developers actually speak the language. Go in particular seems especially prone to attracting developers who are familiar with other languages, who insist on continuing to try to write code in those other languages without consideration for how this one might be different and then blame the technology when things don't work out...
Re: Lies we tell ourselves to keep using Golang (2022)
#333Earlier quoted context omitted.
Sorry for the segue, but how your team's experience with C# on VSCode? Any recommendations for plugins? I've heard of a lot of people recommend Rider but not much, aside from neonsunset, talk about VSCode.
Great. C# DevKit is really all you need (and the same plugins you would normally have like GitLens, etc.). Refactoring experience isn't as good as Rider (JetBrains are kings of refactoring tooling). But for all other cases VS Code is fast and ergonomic. Rider does have some nice things for supporting working with SQL databases that I do envy once in a while.
Just in case: DevKit is optional and requires an account, you can just use the base C# extension which is what provides the language server and the debugger, if you prefer VSCodium there's a fork of it which packs Samsung-authored netcoredbg instead of vsdbg so that is covered too.
For F# - Ionide works great, I like it a lot, integrates seamlessly with existing C# projects.
Re: Lies we tell ourselves to keep using Golang (2022)
#334CTRL+F "rust", 24 matches, I had a feeling that would be the case. What does Golang, for the most part, have to do with Rust? I also find the following bit somewhat funny: >The success of Rust is due in large part to it being easy to adopt piecemeal and playing nice with others. And as if Rust itself didn't suffer from the same kind of imperfections one can find in Golang. So much for that "nothing new under the sun"…
> And as if Rust itself didn't suffer from the same kind of imperfections one can find in Golang.
Which imperfections are these?
Re: Lies we tell ourselves to keep using Golang (2022)
#335Earlier quoted context omitted.
I do wish this is something Rust had done better though - the panicking versions often look more attractive and obvious to developers, and that's the wrong way round. Vec indexing, IMO, should return Option .
One of my dream projects is creating a Rust stdlib based solely on panics for error handling. Sure, it'd be incompatible with everything, but that might be a feature, not a bug.
I think someone's already created this.
Re: Lies we tell ourselves to keep using Golang (2022)
#336> and most importantly, you adopted a language that happened by accident. Is the author implying that Go was created by accident?
"Accident" is hyperbole, but IIRC Go evolved out of Google's internal high-performance HTTP server tooling, so they didn't initially set out to create a general-purpose programming language.
Re: Lies we tell ourselves to keep using Golang (2022)
#337I have recently started to port a large codebase from Go to Rust. I thought it was going to take more code in Rust, but I have been surprised at how much less code it takes. As of right now, the Rust version is 60% smaller in terms of LOC.
I think a large part of this is due to error handling in Rust and the sugary `?` syntax which is so incredibly useful.. I can't count how many times I have done the following in go
x, err := Foo()
if err != nil { return nil, err } // or something like this
I'm pretty sure a large chunk of the LOC reduction was in that alone. Though, a large chunk is also some crates that make a lot of boilerplate go away (serde, serde_json, etc).
Re: Lies we tell ourselves to keep using Golang (2022)
#338This 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…
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…
Rust and Go's lack of stack traces are basically equivalent in that you need to call an additional function to add the stack context to the error result. For go you use fmt.Errorf, in Rust you use .context from anyhow (bad practice in many contexts IMO) or .inspect_err + log. It's rather unfortunate that neither has an easy way of capturing a line number + file easily and appending it to the context. Go could easily do it, I think. Oh well.
I agree that Go should really have an analogue to Rust's `?`, but you can't really do that in a sane way without sum types to represent your conditions. The very multiple-return style error propagation makes it impractical to do.
IMO Go should add really basic tagged unions and rework the stdlib to use them, but such a change would probably necessitate a v2.
Re: Lies we tell ourselves to keep using Golang (2022)
#339Earlier 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…
I forgot: The tenet "accept interfaces, return structs" is violated all over by returning the `error` interface. IMO it's okay to make behaviour-exceptions specifically for error handling. Rust for example doesn't really have builtin behaviour exceptions specifically for errors, they're generic to sumtypes and just happen to work well for errors. But then in practice you must resort to thiserror or anyhow helper crat…
> The tenet "accept interfaces, return structs" is violated all over by returning the `error` interface.
To be fair, that expression came from a blogger who often wrote about Go. It is not a tenet held by the Go project. In fact, Rob Pike has made clear that he considers it to be misguided advice. It is only violated in the same way returning Result in Rust violates the assertion I made up for this comment: Do not return Result.
Re: Lies we tell ourselves to keep using Golang (2022)
#340Earlier 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…
Rust and Go's lack of stack traces are basically equivalent in that you need to call an additional function to add the stack context to the error result. For go you use fmt.Errorf, in Rust you use .context from anyhow (bad practice in many contexts IMO) or .inspect_err + log. It's rather unfortunate that neither has an easy way of capturing a line number + file easily and appending it to the context. Go could easily…
RE: Golang v2, they clearly said they will not do it and will double down on backwards compatibility with exceptions powered by env vars and/or CLI switches.