371–380 of 396 posts
Earlier quoted context omitted.
The whole idea is a joke, it's right there in the name. It was a recognition of the "facts on the ground" of GvR's role as the creator of Python, it was never seriously meant as a principle of project management. It's descriptive not prescriptive, eh? The idea got reified all out of hand.
The wording may be a joke but the concept is real and widely used.
Russ gave us proper vendoring and generics: two things I thought I'd never see in Go... Thanks a lot for the effort!
While vendoring is great, generics is bad addition to Go, since they complicated Go type system too much [1]. This makes typical Go code with generics hard to read and hard to maintain. [1] https://go.dev/blog/type-inference
Earlier quoted context omitted.
The `match` statement is the most obvious - its motivation [0] is "pattern matching syntax is found in many languages" and "[it will] enable Python users to write cleaner, more readable code for [`if isinstance`]". But `if isinstance` is bad Python! [1] `match` also breaks fundamental Python principles [2] and interacts badly with the language's lack of block scope: >>> a, b = 1, 2 >>> match a: ... case b: pass ... >…
Here's Guido himself expressing FOMO about what would happen if Python stopped continually accumulating new features (specifically including the `match` statement): > Essentially the language would stop evolving. I worry that that would make Python become the next legacy language rather than the language that everyone wants to use. https://discuss.python.org/t/pep-8012-frequently-asked-quest...
Earlier quoted context omitted.
> pointless features are added because maintainers are afraid I wouldn't have described language designers' feelings that way, but you're absolutely right. For example, witness the recent features added to Python with little more justification than "other languages have it". It's pure FOMO - fear of missing out.
"Other languages have it" is a disease that's struck many languages in the past decade+, notably Javascript which added partial OOP support (classes but initially no access modifiers), or Java which added functional programming constructs via Streams. I mean granted, Java needed some tweaks for developer ergonomics, and I'm glad they finally introduced value types for example, but I now find that adding entire paradi…
Earlier quoted context omitted.
"That's why go's toolchain isn't as messed up as npm, yarn, grunt, ..." And let's be honest, Rust toolchain is pretty messed up too. Want to cross-compile with go? Set the GOOS variable and you are done. On Rust you need to curl-sh rustup, switch to nightly, add new targets, add target to your cargo and cross fingers it works this week.
Rust cross-compilation isn't great, but this seems a bit hyperbolic: > On Rust you need to curl-sh rustup Yes, but you do that once per computer, probably when you installed the compiler > switch to nightly, No > add new targets, Fair. But this is also one-time setup. >add target to your cargo Not sure what you're talking about here tbh > and cross fingers it works this week. Don't use the nightly compiler and you're…
Earlier quoted context omitted.
Ohhhh boy have I seen that. Like I say, it’s a skill issue, but those people tend to be in Java and C#, not Go and Rust.
Go has Kubernetes ecosystem for that, and Rust is yet to take off as application programming language embraced by Enterprise Architects at big corp.
Earlier quoted context omitted.
> It's impossible to write complex and performant programs without pointers. Well, I'd rather not copy around a multi-hundred-megabyte (or gigabyte) 3D object around to be able to poke its parts at will. I'll also rather not copy its parts millions of times a second. While not having pointers doesn't make impossible, it makes writing certain kinds of problems hard and cumbersome. Even programming languages which do n…
Well, looks like the GP missed a very common false fact: The operations written in a program must literally represent the operations the computer will execute. This one stops being true on high-level languages at the level of x86 assembly.
Earlier quoted context omitted.
False things programmers believe: All reference types should be able to take a null value. It's impossible to write complex and performant programs without null. It's impossible to write complex and performant programs without pointers. References always hold a memory address in a linear address space. (Not even true in C!) Every type is comparable. Every type is printable. Every type should derive from the same comm…
Without pointers in some form or another, you can’t refer to allocated memory. You can change the name of pointers but they are still pointers.
Example in C:
void fun(void) {
int a[16];
for (int i = 0; i I have allocated and referred to memory without pointers here.
Earlier quoted context omitted.
Without pointers in some form or another, you can’t refer to allocated memory. You can change the name of pointers but they are still pointers.
That's... not true? Example in C: void fun(void) { int a[16]; for (int i = 0; i } I have allocated and referred to memory without pointers here.
Here's something to try at home .. exactly your code save for this change:
i[a] = 1;
WTF ??? you ask, well, you see, X[Y] is just syntactic sugar for X+Y - it's a pointer operation disguised to look like a rose (but it smells just the same).