121–130 of 243 posts
You must build a Directed Acyclic Graph (DAG) to ensure these special interfaces don't hit an infinite loop.
To stop the infinite loop cycles, and actually implement a DAG, I marked visited nodes and returned `false` if the nodes were already marked.
I find it ironic that golang refuses to introduce exceptions, but instead is slowly turning errors into a crappy substitute. I feel like a modern language should do either two things with errors: exceptions, or a result monad. Since the language is GC'd and doesn't have language support to make a result type practical, it seems like exceptions are a no brainer.
Earlier quoted context omitted.
> slight inconvenience for non-US citizens So, 96% of the world's population? And even in the US, science and engineering projects commonly use ISO dates. Go's date formatting is as if a random American had taken a quick glance at a paper calendar pinned to the side of their fridge, and decided "yeah, let's do it like that".
Most people can remember "January 2nd" and don't think about US-date vs non-US date.
Earlier quoted context omitted.
> Go repeats design mistakes that were recognized as mistakes decades ago (nil pointers) All popular languages have some way to encode the fact that a value is absent. When languages that don't support nil/null values become popular, you might have a point in claiming that it was a mistake. Right now it makes no sense to make that claim.
Rust doesn't have nil/null values. It has an Option type that enforces at compile time that you explicitly handle missing values, through pattern matching, transformations, or unwraps. This makes 95% of the problems associated with nil/null pointers magically disappear. The difference this makes for the safety of large-scale systems is huge.
Earlier quoted context omitted.
Rust doesn't have nil/null values. It has an Option type that enforces at compile time that you explicitly handle missing values, through pattern matching, transformations, or unwraps. This makes 95% of the problems associated with nil/null pointers magically disappear. The difference this makes for the safety of large-scale systems is huge.
> Rust doesn't have nil/null values. Yeah, and it's also not popular. The reason I said "popular" is because the popular languages are addressing pain-points for devs. If nil/null was a pain point, none of the popular languages would allow nil/null values. The simple fact is that, for many developers, there is a pressing need to indicate lack of a value. Languages that don't address this pain-point never really get t…
Almost every new language that has come out in the last ~10 years or so tries hard to avoid null pointers, and old languages try very hard to mitigate the problem in various ways.
Dart went through a tedious process of removing nullability.
Kotlin doesn't have nullability (well, sort of, using Java bindings can still get you null pointer exceptions).
There are lot's of attempts for Java, from static analysis tools (eg recently from Meta , but there are older solutions), Springs new @NonNull, etc.
C# switched to making non-nullable the default a few years ago.
Rust only has null pointers in the unsafe part of the language, and only for low level raw pointers, not for traits.
Go is the odd one out.
Earlier quoted context omitted.
Sorry, but what are you talking about? Poorly designed? A lot of incredibly good software is written in Golang and while that might not mean it's the best language ever designed, it would be hard to say it's "poorly designed" based on that fact alone?
Incredibly good software has been written in JS, that does not make a good language out of it. To a competent team, a bad language is an hindrance, not a deadly obstacle.
I still feel there's space for a middle ground language. One that: * compiles (ie no interpreter/VM required) * is statically typed and has generics * has exceptions or option types * doesn't have a borrow checker * isn't purely functional but has map, filter, pattern matching, etc * has reasonable traction Is there anything like this?
Earlier quoted context omitted.
> Go repeats design mistakes that were recognized as mistakes decades ago (nil pointers) All popular languages have some way to encode the fact that a value is absent. When languages that don't support nil/null values become popular, you might have a point in claiming that it was a mistake. Right now it makes no sense to make that claim.
Rust doesn't have nil/null values. It has an Option type that enforces at compile time that you explicitly handle missing values, through pattern matching, transformations, or unwraps. This makes 95% of the problems associated with nil/null pointers magically disappear. The difference this makes for the safety of large-scale systems is huge.
I have to nitpick here: Rust raw pointers (https://doc.rust-lang.org/std/primitive.pointer.html which does note "Working with raw pointers in Rust is uncommon") do have null values. It's not usually a problem since raw pointers can only be dereferenced in unsafe code; most of the time, you will be using a reference wrapped with an Option, which has the same size and same possible values (the compiler knows a reference is never null, so it uses the "missing" null value to represent the None variant of the Option enum).
Earlier quoted context omitted.
Implicit interfaces are one of the defining features of the language that make it so great, I love them. Calling them borderline insane without any supporting arguments does make me question whether you ever gave idiomatic Go a chance. What do you dislike about them? Re error handling, I've been looking at the proposals and haven't yet seen a satisfying one. Sure, the current error handling is a bit verbose (three li…
> I much prefer it to exceptions as it makes you think about each error and makes people wrap errors with helpful context everywhere… This would be absolutely fine, for the reasons you state, if Go made you deal with the error. But because it will silently allow you to completely ignore the error, your statement that it "makes you think about each error" is quite optimistic. In an exceptionful language, the runtime w…
Rust/Zig/Swift approach is definitely the best.