111–120 of 508 posts
Earlier quoted context omitted.
No, Python is not strongly typed by any serious definition of the concept.
Strongly typed: >>> "foo" + 3.141 TypeError: can only concatenate str (not "float") to str >>> object() + 3.141 TypeError: unsupported operand type(s) for +: 'object' and 'float' Weakly typed: > "foo" + 3.141 "foo3.141" > Object() + 3.141 "[object Object]3.141" > [] + {} "[object Object]" > {} + [] 0
a = 3
a = 'abc'
Earlier quoted context omitted.
Is there even a single go abstraction that doesn't leak it's guts everywhere?
There aren't any abstractions in any language or library that don't leak everything about what they are trying to hide as well as everything about their own implementation. That's just life. It's impossible to hide complexity. Whatever wraps one thing will be strictly more complex than the wrapped thing was.
Haskell's json/sql marshalling do not use runtime reflection but instead ad hoc polymorphism, so when I create (or even derive automatically!) a marshalling instance, it is pretty easy for me to reason about what will happen statically. Haskell's Generic & newtype-deriving go a long way here, and are good examples of principled abstractions that do not leak.
Haskell's conduit (and other streaming libraries) is another good example. I use them to create programs that process things in constant memory, and when I compose them (e.g. with operators like =$= or .| in conduit), the resulting program streams in constant memory. I have built entire systems (CLIs, batch jobs, event processors, etc) on top of this abstraction and conduit itself has never leaked.
I think this post summarizes to, - I don't like the file-related packages - What's up with this random 7 star library having a lot of transitive dependencies - Rust for life - In summation, Go is the worst
// This file is intentionally empty.
// It's a workaround for https://github.com/golang/go/issues/15006
I don't understand why you would create a statically typed language but not actually take advantage of types, instead typing everything with generic types like string. Why make the user pay for complexity in types but not actually deliver their promise? This is the problem with C and Go doesn't really solve it either
Generally we try to avoid the mistakes of the previous generation (and make the same ones as the one before that, half the time) so this is confusing to me.
I wonder how many Android contributors he had working with him while these decisions were being made.
> The Go way is to half-ass things. This used to be known as the New Jersey school, and is the underlying philosophy of Unix: build a bunch of little pieces that work a lot of the time and kind of fit together if you remember the gotchas, then call it a day. There is an essay on this that I am unable to locate right now which mentions the horror of someone working on ITS when they asked how Unix solved a rollback on…
Windows-focused rant. Plus a few reasonable points. Every language is complex at some level and in their own ways-Rust included. Every language hides some of the complexity of layers below it like assembly and thus hides hardware details. Computers are complex. Point granted. Fact is Go is a very reasonable set of compromises that let's real enterprise-scale work get done and run with solid performance. I've done wor…
Until it has them it's a valid complaint. And the fact that they're finally coming 11 years after the language's creation is another matter
Earlier quoted context omitted.
I absolutely agree. The one time I had the great misfortune of building software for windows I was extremely happy to see Go worked at all. Linux and OS X largely work the same way due to their shared Unix-ness and pretty much everyone I’ve ever met or talked with uses Go on one of those two platforms. If you have to develop software primarily for Windows, maybe don’t use Go - it’s easily the least actively maintaine…
No one expects iOS to run on Windows. But given that there's a Windows version of Go, it's reasonable that it should work. And also, the points about metadata and path management are spot on. It's 2020. Languages should not be assuming that paths are byte strings. Unix-think is a bug, not a feature. A good language should abstract the file system, not just put a teeny tiny wrapper of modesty around it.
They are in the real world and you have to live with that.
Screaming at people might sometimes have good results.
Screaming at reality never does.
Earlier quoted context omitted.
Strongly typed: >>> "foo" + 3.141 TypeError: can only concatenate str (not "float") to str >>> object() + 3.141 TypeError: unsupported operand type(s) for +: 'object' and 'float' Weakly typed: > "foo" + 3.141 "foo3.141" > Object() + 3.141 "[object Object]3.141" > [] + {} "[object Object]" > {} + [] 0
a = 3 a = 'abc' There goes your strength, Samson. Just because there's something worse, that doesn't make python strongly typed