JS is both
Python Is Easy. Go Is Simple. Simple != Easy
101–110 of 313 posts
Re: Python Is Easy. Go Is Simple. Simple != Easy
#102Earlier quoted context omitted.
I think you typed "python" wrong :) Duck typing is a python thing. And the dependency management is a nightmare, constantly breaking. To the article's point - you _must_ run it in a container and defer to the OS to have anything resembling a sane development story.
Ok that's totally fair. What's the Go name for it? In my mind Go interfaces are duck typed.
Python is duck typed as it support dynamic type, whereas Go doesn't. Yet you can do polymorphism in Go and aside that difference I think Go interface are duck typed.
Re: Python Is Easy. Go Is Simple. Simple != Easy
#103Earlier quoted context omitted.
IMO, Go is a mediocre language with great tooling and a great company behind it, and it turns out ultimately if you don't have the latter, the former is irrelevant.
Most developers are mediocre, so having a language that can match the skill level of the average dev is a win for many situations, no?
A mediocre language is not the same as a language appropriate for developers of mediocre skills. Go could have been made a better language [0] in many ways that would have actually made it easier than it is right now, by avoiding some of the footguns built into the language. This also wouldn't have made the language more prone to being used in a complex manner by metaprogramming enthusiasts and the like. Better often means simpler, not more complex.
[0]: Not that it's not already decent.
Re: Python Is Easy. Go Is Simple. Simple != Easy
#104Yeah, but the amount of boilerplate one must read and write in Go is frustrating, even compared to Java.
Huh? Having defer statements and error returns vs. dealing with exceptions gives Go the win all by itself. And then there is the business of being able to make a type automagically satisfy an interface. (Java may have fixed some of the agony of creating classes just to satisfy a required interface. Last I used Java, it didn't have delegates and whatnot.)
Go's defer is verbose and unwieldy compared to Python's `with` statement or Rust's lifetime system. In Python, you don't have to manually write any code to close the file, you just do:
with open('foo') as f:
...
If you want to loop over 10k files, both of those handle that just fine, because the active file will be closed at the end of each loop. Go's defer will try to wait until after the loop to close everything. You can make things even more verbose to fix that, but it gets ugly real quick.
Re: Python Is Easy. Go Is Simple. Simple != Easy
#105Why is there not a Go with Python syntax? Golang is hideous to read.
F# is basically statically-typed Python (with better performance).
Re: Python Is Easy. Go Is Simple. Simple != Easy
#106A VC once told me that as a rule, Go startups were more likely to succeed than Python startups. Maybe because successful startups are working on simple problems, not easy problems.
Re: Python Is Easy. Go Is Simple. Simple != Easy
#107Re: Python Is Easy. Go Is Simple. Simple != Easy
#108No matter what your opinion is about Go (as a language), but they nailed it for bigger projects. Go code always looks the same, performance is predictable and fast enough for most programs, and its really, really easy to be productive. When i picked up Go i basically got shit done without ever having written a single line of Go. Its statically typed (with generics yey!) and compiles very fast. Its easy to create smal…
The way I describe it is that Golang is optimized for reading, other languages are often optimized for writing. If you have to deal with someone else’s codebase, then Golang is a godsend. I also like that you pointed out that every Golang codebase looks the same. I think part of that is that Golang’s formatter can’t be customized. I pushed for that to happen in Rust but lost the battle.
I don't think I understand where you are coming from. Reading Go code is pretty painful compared to most languages between the specification and the formatter everything looks identical and there is a lack of intentionality. You can't really reason about method signatures or really tell what source will do given the shape.
Re: Python Is Easy. Go Is Simple. Simple != Easy
#109Earlier quoted context omitted.
Don't forget the fact that it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on. Even generics in Go were a heated debate because they make the language more complex. All in all Go was created by geniuses and it shows.
> it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on Several Go codebases I've worked on would like a word. Some Go people really love their interfaces and abstractions and making sure every method is only 3 lines and pretty soon you're 20 files and three type hierarchies deep trying to figure out what a…
There is this odd thing where the actual syntax and features of a language are (at least partly) independent of how it ends up being used. A culture forms around the language (that the authors have limited influence over). Java does not have to be used the way most people tend to (factoryfactoryimplfactory!). And some go projects (notably at least early k8s are go in Java style).
A lot of what people comment on is less the language and more the dominant culture.
Re: Python Is Easy. Go Is Simple. Simple != Easy
#110No matter what your opinion is about Go (as a language), but they nailed it for bigger projects. Go code always looks the same, performance is predictable and fast enough for most programs, and its really, really easy to be productive. When i picked up Go i basically got shit done without ever having written a single line of Go. Its statically typed (with generics yey!) and compiles very fast. Its easy to create smal…
I used Go for many years. My issue is that it's _almost_ a great language, but in its current version it's just a collection of foot guns that makes it difficult to get shit done. Go doesn't have some of the most library functions, so large codebases shared between teams end up with a dozen different implementations of functions like "minimum" or "filter". Good luck debugging a bug in one of the implementations. The…
I feel like the pointer stuff you could handle safely in a modern language. Because I think pointer and array notation are convertible so one isn't scarier than the other.
But yeah not being able to tag pointers as 'can't be null' and have the compiler enforce that ignores everything we've learned in the last 40 years. You shouldn't be able to pass a potentially null pointer to a routine that can't deal with it. You end up with code finding a null pointer without any context that tells it what to do with that. Or it panics.