Erm..
> As it happens, I am not a junior developer, far from it. Some way or another, over the past 12 years,
I'd say that's isn't too far from it to be fair.
Lies we tell ourselves to keep using Golang (2022)
171–180 of 526 posts
Re: Lies we tell ourselves to keep using Golang (2022)
#172Earlier quoted context omitted.
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.
You hit the main gripe I have with Go, its types system is so basic. I get people raving type-correctness of Go when they come from Python but the type system in Go is simply pre-historic by modern day standards.
I feel that the future for Python people who want type safety will eventually be TypeScript on nodejs. Go was intended as an alternative to C++. It seems that in reaction to the ungodly complexity of C++, the creators wanted to avoid adding language features as hard as possible. If the user could work around it with a little extra verbosity, it'd be ok. I feel they removed too much and maybe not the right things.
Re: Lies we tell ourselves to keep using Golang (2022)
#173Well, i feel like this is the 100th article i read about why golang is bad "mkay".
For my personal background, i started with golang about 6 years ago and im using it mainly for private and open source projects.
Yes golang for sure isn't perfect, but what language is tho? I think the major point is - the language you use should match your use case. If it doesn't it will always feel "bad" or you will more likely tend to find points why the language isn't perfect (for your needs).
Sure you could write a website builder in ASM or you can write an Operation System in Javascript - but why should you?
Just look at your use case - check your needs and decide what language fits the best.
If its golang? Fine use it. If its not golang, than don't. But don't take a language and try to match it on "everything" and than complain that it doesn't do the job - because no language will.
Thats my 5 cent's on this topic....
Re: Lies we tell ourselves to keep using Golang (2022)
#174Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating some…
> A garbage collected relatively simple language that compiles into a statically linked binary and has a [good] type system Yeah! Pattern matching too. What are currently available languages closest to this? AFAIK, Gleam relies on a virtual machine, but otherwise seems promising.
Stretching 'currently available' a little, there's Roc lang [1]. Though still in development, you can use it for small personal projects. Another caveat is that it's a functional language, which could potentially hinder its wide adoption
Re: Lies we tell ourselves to keep using Golang (2022)
#175Earlier quoted context omitted.
This 100%, I was just about to type a long rant up about this. There are so many weird parts of the language that took me forever to grasp, and in many cases, I still don't have an intuitive grasp of things. And plenty of other examples that aren't in that article: - You have a struct with an embedded interface. Does the outer struct satisfy the embedded interface? And can I type assert the outer struct into whatever…
> 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?
Re: Lies we tell ourselves to keep using Golang (2022)
#176This 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…
For me, the issue with error handling is that while errors are explicitly stated, they are often poorly handled. Rarely have I seen the handling of multiple reasons for why an error might occur, along with tailored approaches to handle each case. This is something very common in older languages like Python or Java
As a regular Go user, I agree with this take. Though the tools exist, error wrapping and checking (with errors.Is and so on) is actually pretty rare in my experience.
Positive example of good and appropriate usage here: https://github.com/coder/websocket/blob/master/internal/exam...
Re: Lies we tell ourselves to keep using Golang (2022)
#177My biggest problem with Go is readability of some projects. In many cases, the code is split across files in an unintuitive way, and you can only navigate with the help of an IDE.
Re: Lies we tell ourselves to keep using Golang (2022)
#178Go: "I'm a simple language!" User uses Go for some time. User: "I hate you, you're a simple language!" Perhaps it's because I'm 50+, I love a simple language. I feel the "critique" is not very balanced, and I view judgements that are not balanced as weak, as everything in technology is about tradeoffs. I of course come to a different conclusion: https://www.inkmi.com/blog/why-we-chose-go-over-rust-for-our...
I wish the discourse that Go is a "simple" language would die. Despite its veneer, once you start writing Go it quickly becomes apparent that it isn't simple. Hidden complexity and footguns are abundant (e.g., https://archive.ph/WcyF4 ). It's nevertheless a useful language, and I use it quite a bit, but it's not "simple".
It's easy not simple, but the consequence is that any complexity that other languages handles for you, in go gets forced onto the developer.
There's more stuff to think about, because the language is doing less for you.
Re: Lies we tell ourselves to keep using Golang (2022)
#179This 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…
this part of error handling is pure religion. it goes even against one of the most basic go tenents. that code should be easy to read not write.
Try reading and understanding the logic of a particular method where 75% of the lines are error noise and only 25% are the ones you need to understand what the method does.
yes it's noise because whenever read a codebase for the first time you are never interested on the the error edge case. first glance readability needs to tell you what you are trying to accomplish and only after what you are doing to make sure that is correct.
on this point go's error handling is a massive fail. Notice that I'm not saying explicit error handling is bad. I'm saying the insistence that error handling needs to be implemented inline interleaved with the happy path is the problem. You can have explicit error handling in dedicated error handling sections
Re: Lies we tell ourselves to keep using Golang (2022)
#180Earlier quoted context omitted.
Many people against Go's error handling do not advocate for exceptions, but for a combination of an Either/Result type (for recoverable errors) and fully aborting (for unrecoverable errors).
Abort on the other hand is used WAY to liberally in Rust. How I hate it, that every second function call can break my program when it's clearly not a "halt the world, it's totally unrecoverable that the user sent us nonsense" type. Return a Result and get on with your life!
If a Rust function can panic, there's generally a non-panicking alternative. For example, `Vec` indexing has `vec[n]` as the panicking version and `vec.get(n)` as the version that can return `None` when there's nothing at that index.