Earlier quoted context omitted.
What were they actually doing? Passing interface{} all the time and casting it?
Haha you're spot on. In the codebase I inherited that was everywhere.
You can do crazy things in any language if you try hard enough.
Python Is Easy. Go Is Simple. Simple != Easy
181–190 of 313 posts
Re: Python Is Easy. Go Is Simple. Simple != Easy
#182Earlier quoted context omitted.
This roughly lines up with my feelings. Go is a solid improvement over many languages that we inherited from the 70s, 80s and 90s. But it also retains a certain "we don't need a robust type system; weak-ish static typing is good enough" ethos that made sense in back then, when compilers were hard enough to write that it was easier to justify making the programmer handle more things manually for the sake of simplifyin…
I think the key question is how robust a type system can be while keeping compilation extremely fast. Slow compilation absolutely destroys developer productivity.
You can make it pretty darn robust! OCaml compiles very quickly and has a good type system. Rust is slow due to LLVM, macros, and the compilation unit being the entire crate. None of these are requirements for a good type system
Re: Python Is Easy. Go Is Simple. Simple != Easy
#183Earlier quoted context omitted.
I could not agree more with this. Go is so frustrating to me because there is so much I like but these things you listed make it miserable for me to use. A basic option and result type could fix a lot of the issues around errors and null pointers. I know languages like Scala, Haskell, and Rust have type systems that are often considered too complex but Go doesn't need all that to add these two.
"Defaults are useful" was IMHO the biggest mistake Go made. I understand that it made the language a lot simpler but this was a simplification that ended up moving the complexity to the user, rather than just removing it. I have seen so many bugs caused by default values, production outages. Plus the code is harder to understand because you need to consider the default value case, and make sure that it is only left a…
Not to mention, some things just don't have a sensible or sane default. Needing the zero value to be meaningful has had so many negative downstream effects (nil being one of them) it's crazy people still defend this decision.
Re: Python Is Easy. Go Is Simple. Simple != Easy
#184Earlier quoted context omitted.
I read a lot of code. Reading Go is painful because I have to parse whatever open-coded version of standard algorithms or error handling the developer chose to use that day.
This was exactly my experience when I was working in Go. Each line was easy to understand, but reading actual code was painful because I needed to read so much to figure out what was actually being done. I was basically spending 90% of the time mentally simplifying the code into abstractions so that I could understand the business logic. Then once I understood the business logic I had to zoom back in to check that th…
Yep. Every layer has to deal with every detail of every problem. So now you get to read dozens of in-line, bespoke implementations of what should be a method call.
Re: Python Is Easy. Go Is Simple. Simple != Easy
#185Earlier quoted context omitted.
Exactly. Code is read WAY more often than it's written. Go is verbose, that's true. And if the speed of writing code is the biggest hurdle in your productivity you're either a true 100x coder savant or deluded. Go is boring, boring is good when you need shit to work every time. And especially when you can't pick the top1% geniuses to work on it and might need to bring some rando up to speed to the project AND languag…
Go is verbose. That slows me down when I’m _reading_ code. Especially when it means the chunk of code I’m reading doesn’t fit on my screen.
Or when I have to pick out what the actual logic is amidst a forest of error handling. Or mentally deconstruct some complicated loop to figure out it's just doing a map, filter, reduce.
Re: Python Is Easy. Go Is Simple. Simple != Easy
#186Earlier quoted context omitted.
I think the key question is how robust a type system can be while keeping compilation extremely fast. Slow compilation absolutely destroys developer productivity.
Conversely I could go longer between compiles if the type system caught more.
Most of the times when I really care about quick feedback cycles is when I'm experimenting to see what approach does and doesn't work well in the first place.
I care a lot less about it for "simple" errors like typing errors, typos, or whatnot. This is mostly trivial stuff compared to "is this entire approach good or not?"
Re: Python Is Easy. Go Is Simple. Simple != Easy
#187Earlier quoted context omitted.
Syntax IMO. I know it's obnoxious, but the reality is most people read C like languages, not Lisp.
t took me a week to get used to the syntax. Now that I'm not working with Clojure anymore, I find every other syntax somewhat repulsive. When I was looking into Elixir and now OCaml, I found them much harder to follow ¯\_(ツ)_/¯
[deleted]
Re: Python Is Easy. Go Is Simple. Simple != Easy
#188Re: Python Is Easy. Go Is Simple. Simple != Easy
#189Earlier quoted context omitted.
Python code typically doesn't and shouldn't rely heavily on inheritance. It sounds like you're working on non-idiomatic Python code. Bad luck.
Django typically does this.
In a lot of cases it is necessary complexity, between overloading the dot operator, wrapping SQL, and supporting multiple database backends. There is a fair bit of bloat, though.
Re: Python Is Easy. Go Is Simple. Simple != Easy
#190No 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…
Backward compatibility (BC)