411–420 of 477 posts
What would be a good alternative to Go, with - large and well maintained standard lib - great runtime characteristics - esp. reasonable memory usage - developer ergonomics - matureness - long term stability - preferably managed memory I really have used a lot of languages. They all have some downsides. I like Kotlin a lot but the JVM is just to cumbersome and resource heavy. Grade is way to complex. Rust is way to cu…
Earlier quoted context omitted.
Null pointer bugs are prevented by idiomatic use of Option in Rust, so that’s at least one case where Rust’s focus on correctness prevents memory-safety bugs.
Yet many Rust code bases are littered with .unwrap(), which undoes that benefit.
Blaming a language such as Go for poor software design choices is like yelling at a garden spade, in ASL. I've seen some well-written library code that is kept up-to-date, and I've seen some crufty libs that, frankly, would barely pass muster on an internal code review. A good litmus test is to check the linting configuration for a given library repository, as well as the frequency by which a given library is updated…
If your idea of a "grown up engineer" is one who fails to notice systemic problems and diligently, repeatedly hits themselves in the head with a rake because that's the way it's always been done, we have very different ideas.
I see this point everywhere about Rust's union types and it always kind of irks me: > The point is, this [Result type] makes it impossible for us to access an invalid/uninitialized/null Metadata. With a Go function, if you ignore the returned error, you still get the result - most probably a null pointer. It's all about framing. You can just as equally say it is "impossible" to access an invalid Go FileInfo, because…
The difference is what the language makes easy to do and how it signals to you you're about to do something dangerous. If you call `.unwrap()`, that's a big yellow flag that you're going to be taking the gloves off and maybe touching something radioactive. Go has the maybe-radioactive thing sitting right there; safely touching it and unsafely touching it look exactly the same. I generally enjoy using Go, but this is…
Sure. And, in Go, if you write
v, _ := f(...)
v, err := f(...)
// use v without checking err
Earlier quoted context omitted.
Note that a "dismissal" is not the same as an actual rebuttal. A template can just as easily generate a tricky-to-dissect fallacy or bad-faith argument as actual logic.
I disagree - if its a template that is commonly used, someone only has to dissect it once. Regardless, what exactly is tricky to disect or falacious about this template? The rebbutal is basically: * go is trying to optimize for different things * go makes no secret that its trying to optimize for different things * some people like the things that go optimizes for (and some people don't). * [with an implied] if you i…
Author here: I wrote this in 2020, have changed jobs twice since. Both jobs involved Go in some capacity, where it's supposed to shine (web services). It has not been a pleasant experience either - I've lost count of the amount of incidents directly caused by poor error handling, or Go default values. If folks walk away with only one new thought from this, please let it be that: defaults matter. Go lets you whip some…
Don't fall prey to an ad-hominem argument - I don't think your article negatively hints at any kind of 'this is a Rust fanboy-made praise text' and it saddens me that a genuinely legit article like this needs to have the author defend himself like this. Your points were well explained. Go has several serious warts which, in my own opinion, are showstoppers, and you are comparing it to a language which is somewhat new…
They were designed with the help of type system experts like Phil Wadler: https://arxiv.org/abs/2005.1171
Not sure why you think they were 'rushed', given the timeframe involved.
The author fundamentally misunderstands language design. He picks an arbitrary design constraint, in this case correctness, and argues that any language that does not provide 100% correctness is bad. He uses Rust for his examples, a language that has correctness as one of its top design goals, and contrasts it with Go, for which correctness is not that important. So of course Rust will come out on top when the only m…
What an extremely convenient template to dismiss any nuanced argument against "worse is better". You even get to question my credentials a couple times! (I apparently pick metrics that are convenient to my argument, and fundamentally misunderstand programming language design). Even if I accept the premise that "I'm challenging Go on things it doesn't promise to deliver" (which is disingenuous to begin with — correctn…
Correctness is a spectrum, not a boolean. Failures of correctness are, equally, a spectrum of risk. And risk is measured primarily by impact on business goals. Consequently an incorrect program that satisfies its business-level responsibilities is definitionally better than a correct program which does not.
Earlier quoted context omitted.
Seems pretty straightforward to me: type Car struct { Motor Motor Wheels [4]Wheel } type Motor interface { Rev() } type KiaMotor struct { ... } func (kia *KiaMotor) Rev() {} func NewKiaCar() Car { return Car{Motor: &KiaMotor{ ... }} }
Took me a second to see the difference in what you were doing between what I was doing. In your case you're making a Kia car by making a regular car with a Kia motor. In my case (at work) I'm making a type KiaCar struct { Car ... }. Which is why I have to link a concrete type in the KiaCar to the Car if I want methods with Car receivers and KiaCar receivers to use the same concrete Motor. I do like what you've writte…
type BookStoreBackend interface {
GetBook(isbn string) (*Book, error)
PutBook(*Book) error
ListBooks() ([]*Book, error)
DeleteBook(isbn string) error
}
// BookStore embeds (i.e., is composed of) a Backend, which is an
// interface type.
type BookStore struct {
// ... other fields
// Backend supports PostgresBookStoreBackend, SQLiteBookStoreBackend,
// FileSystemBookStoreBackend, MemoryBookStoreBackend (for testing),
// etc.
Backend BookStoreBackend
}Earlier quoted context omitted.
> But programming languages should get on your way while you're doing things wrong. Go does not. To be fare, most mainstream languages do not: I think Rust is the best in this thing, other languages often aren't. But Go is by far the worst of all, because of its striving for "simplicity". Go typically does get in your way when you're doing things wrong, but yes, I'd like to see Go require return values be dealt with…
> I'd like to see Go require return values be dealt with or explicitly ignored. Ever use the return value from fmt.Println?