201–210 of 222 posts
Earlier quoted context omitted.
I would argue that e.g. decent error handling is not "fancy shit".
It's perfectly decent, it forces you to explicitly handle or ignore every error. It's verbose as all hell, but on the other hand you'll notice immediately if it's missing. Go is not a "fun" language by any means, but that doesn't mean it's not a productive one.
Earlier quoted context omitted.
Python 3 should be considered a different language from Python 2, pretty much.
The level on intentional compatibility breaking was crazy. The fact that they went out of their way to break python 2 unicode when running on python 3 was just totally nuts. Especially after making such a big deal about unicode! I've never seen anything like it I don't think? Maybe the new Perl that never really landed?
Earlier quoted context omitted.
My C and C++ code for Windows 3.1 written in 1995 would compile just fine today on Windows 10.
I heard this a lot but I wonder if it's still really true. I mean, can I literally open the latest visual studio and open an old project, hit build and it will just work?
Earlier quoted context omitted.
With the introduction of generics in Go 1.18 and the accompanying "slices" package ( https://github.com/golang/go/issues/45955 ), we might soon write that as: a = slices.Delete(a, i, i+1) That said, in code I write, I rarely need to do an in-place delete from a slice. I think it's rare enough that recognizing the idiom is okay.
It's so weird why they're adding a slices package instead of making them functions on the slice itself. They did the same with strings. Compare strings.ToUpper(strings.Replace(strings.Trim(s), "a", "b"))) Instead of s.Trim().Replace("a, "b").ToUpper()
It's "to avoid complicating questions about the interface (in the Go type sense) of basic types". It also allows separating the builtin functions, of which there are very few (they have to be in the core language spec), from the stdlib functions like strings.ToUpper, which there are many many more of and are added to more quickly than the builtins.
Earlier quoted context omitted.
The level on intentional compatibility breaking was crazy. The fact that they went out of their way to break python 2 unicode when running on python 3 was just totally nuts. Especially after making such a big deal about unicode! I've never seen anything like it I don't think? Maybe the new Perl that never really landed?
Well, there were good reasons to change the way py2 worked with Unicode, and I don't think this could have been made right without severe breakage either way. The only thing that should have happened sooner is support for u"" literals.
For some reason this was not good enough for the python 3 folks - they actively broke this code which was from folks who had SPECIFICALLy addressed unicode in their apps.
And yes, they could have supported u"" (and a number of other things).
They went - unicode is so critical we will break the world, and then for folks who had already supported unicode well or wanted to dual target a library they said your u"" approach to unicode is so bad we will break it.
Total BS in my book.
Earlier quoted context omitted.
Python 3 should be considered a different language from Python 2, pretty much.
The level on intentional compatibility breaking was crazy. The fact that they went out of their way to break python 2 unicode when running on python 3 was just totally nuts. Especially after making such a big deal about unicode! I've never seen anything like it I don't think? Maybe the new Perl that never really landed?
Earlier quoted context omitted.
It's so weird why they're adding a slices package instead of making them functions on the slice itself. They did the same with strings. Compare strings.ToUpper(strings.Replace(strings.Trim(s), "a", "b"))) Instead of s.Trim().Replace("a, "b").ToUpper()
For better or worse, this is by design. See: https://golang.org/doc/faq#methods_on_basics It's "to avoid complicating questions about the interface (in the Go type sense) of basic types". It also allows separating the builtin functions, of which there are very few (they have to be in the core language spec), from the stdlib functions like strings.ToUpper, which there are many many more of and are added to more quickl…
I didn't get the last point. builtin functions are there (for a big part) because the language doesn't have generics. Functions on types can be added without affecting the interface, since strings don't implement any interface (at least not on purpose, another problem with golang). Java constantly enriches standard library types with more useful methods.
Earlier quoted context omitted.
It has nothing to do with catching bugs. It has to do with that one sometimes has to write 80 lines of code in Go to to the same as 3 lines of Rust code due to having to repeat oneself all the time.
That’s an even more superficial concern. No one is bottlenecked on the rate at which they can type.
It also gets in the way of reading code.
Earlier quoted context omitted.
This will be when I finally use Go for something then.
Even with generics, it has so many issues: * Error handling is error prone and awkward. * No proper enums * No sum types/pattern matching * Null pointers exist * Its interfaces are very awkward. There are superior implementations of what they tried to do in other languages. * Subpar IDE experience, made worse by how interfaces are implemented. You need an IDE for any non-trivial project. * Very awkward choice to have…
Wouldn't any visibility change require a large diff in all languages?
Earlier quoted context omitted.
It's perfectly decent, it forces you to explicitly handle or ignore every error. It's verbose as all hell, but on the other hand you'll notice immediately if it's missing. Go is not a "fun" language by any means, but that doesn't mean it's not a productive one.
I don't see how it forces you to ignore? You don't have to be explicit to ignore the returned error code.
You instantly notice it because the if err != nil -template is missing after it =)