26 ms·

Python Is Easy. Go Is Simple. Simple != Easy

• bborud 3y ago
  Most of the comments here focus on language. But I think this kind of misses an important point the blog post makes: >It is not uncommon to leave a Python application to go back to it after a few >months, only to realize that the host environment has changed enough that it is >no longer possible to even to start the application anymore.
• deleted 3y ago
  [deleted]
• emodendroket 3y ago
  Yeah, but the amount of boilerplate one must read and write in Go is frustrating, even compared to Java.
  • abound 3y ago
    Much less so these days with generics, even in their fairly limited capacity.
  • rargon 3y ago
    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.)
    • vore 3y ago
      Go doesn't really warn you if you forget to handle an error return, which in my experience continuing silently in the face of error conditions is far scarier than crashing loudly.
      • xanamander 3y ago
        That would not be a compile error, but these sorts of issues are why you should also run `go vet` and `golint` for a healthy codebase
      • starttoaster 3y ago
        Check out ErrCheck. It's a static analysis tool that detects exactly this. We added it to our common Makefile that we use for testing/building Go projects. Typically I have it test for this among other things before I commit, and then it runs again in CI scripts before a merge to main is allowed. In my experience, if you're not checking errors, then you're often just going to crash loudly. Likely at a similar point that the comparable Python would have had its runtime error. In my experience, if Go would have continued silently, the comparable Python might also just continue silently anyway.
        • candiodari 3y ago
          The problem with error checking is that Go doesn't cover every case BY FAR. EVERY memory allocation can fail. And I mean EVERY. var x := 5 // where's the error handling? EVERY kernel call can fail. Even this is still not a 100% correct way to call fmt.Printf("Hello, World!"): s := "Hello, World!") writtenSoFar := 0 while writtenSoFar < len(s) { bytesWritten, err := fmt.Print(s[writtenSoFar:]) // and even this is a recent syntax addition. if errno, ok := err.(syscall.Errno); ret == -1 && ok { // error signaled if errno == C.EAGAIN { time.Sleep() continue } else { return err } writtenSoFar += bytesWritten } If you don't do this, you will find, for example, that writing large amounts of data to a network socket suddenly only sends half the output to the other side. Plus anything could set O_NONBLOCK on stdout, which would require this. And time.Sleep() is required in some cases where the program redirects os.Stdout to itself. Even this does not take have proper reactions if an OOM occurs somewhere. So it is still not correct. It's like C. Simple Go looks correct and just chugs along, destroying data instead of crashing. This makes people feel programs run correctly ... but they don't.
          • starttoaster 3y ago
    • EnergyAmy 3y ago
      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: ... And the file will be closed after that block of code finishes executing. Similarly in Rust if you do "let file = File::open("foo")?;", when the variable drops the file will be closed. 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.
      • arp242 3y ago
        I wish defer was block-scoped rather than function-scoped; that would solve the "defer in a loop" problem. Right now I just wrap the lot in a function for that, which works and isn't too bad, but meh. defer is more flexibly and explicit though; I rather like that. It's pretty unclear what exactly that "with" does, what you can and can't use inside "with", you can't "just" run any arbitrary code without creating your own class, and you sometimes end up with 3 or more levels of nested "with"s that could have been one defer. In short, I don't think there's a clear winner. Both are clunky in some scenarios where the other is easier.
  • pclmulqdq 3y ago
    With things like copilot, the boilerplate (if err != nil sorts of things) comes out really easily, and you can skim past it when reading. Also, I have noticed that a lot of the other stuff that people call boilerplate in Go is actually an artifact of static typing (eg having to unmarshal JSONs before querying them), and is ultimately what prevents you from having Python-style runtime crashes or weird bugs.
    • avgcorrection 3y ago
      > With things like copilot, the boilerplate (if err != nil sorts of things) comes out really easily, and you can skim past it when reading. Easily... but is that simple though.
      • pclmulqdq 3y ago
        It's very simple. It's explicit and tells you exactly how errors are handled (if you care), and it follows a very common pattern that is easy to ignore when you don't want to know how errors are handled. Simple and concise are two very different things. In comparison, languages with exceptions give you a minefield around every function call.
        • avgcorrection 3y ago
          Ok. Then I will spell it out: using an LLM to generate code is not remotely simple.
          • pclmulqdq 3y ago
            I will spell it out for you: Almost every language in the world has some sort of template-based autocomplete for common boilerplate that is often used, from class definition templates to if statements. If you aren't using one of these, you're probably working unproductively by thinking about all of your boilerplate instead of just taking it off the shelf. Copilot and its ilk just take this one step further by effectively giving you the same thing but with the slots in the template filled in. I could have said that "with autocomplete it's easy to write" and it would have the same meaning. The presence or absence of boilerplate (and thus the presence/usability of autocomplete systems) does not imply anything about simplicity.
  • starttoaster 3y ago
    Write more libraries of common tasks you have to do constantly. If you're not abstracting your chores, you've been doing it wrong.
    • throwawa14223 3y ago
      Go fought me at every step trying to abstract away boilerplate.
      • starttoaster 3y ago
        I'm not sure how you mean it fought you. I've been writing libraries and utilities in Go for something like 5-6 years now though, so maybe what you and I perceive as "fighting" differs.
  • eddtries 3y ago
    Go is so boring that I found AI tooling to start being far more effective, fwiw
  • baby 3y ago
    It’s must nicer to read IMO than a generic-heavy language. Sure Golang is a bit more of a pain to write because of that but it’s a trade off.
  • thadt 3y ago
    In a former life I often bemoaned the amount of boilerplate shovel code I was having to write to move data between my underlying data models and the user interface's displaying them. So much repetitive and simple 'pick up this number, format it to two decimals, put it in this display box'. Then technologies came out featuring data binding, and patterns like MVVM to keep me from having to write all that shovel code. Instead I could just specify bindings directly in the declarative UI layer, bind it to my data object (or view object) and be done. All I had to do was learn the binding language, understand how the binding engine worked, understand the corner cases and details like the difference between one and two-way binding, etc. Eventually the code taught me that typing, proofing and and maintaining shovel code is often easier than understanding and maintaining the magic incantations of a more 'elegant' solution. My eyes can quickly scan over boilerplate and glean what it is doing pretty quickly. But magic - magic takes understanding - and I only have so many ready spell slots.
  • theshrike79 3y ago
    You can see the structure in the boilerplate pretty quickly. And because it's boilerplate, you'll also instantly see when it's missing.
    • josephg 3y ago
      Sounds like a waste of time. I’d rather just not have that code in the first place. I don’t want to write it. I don’t want to maintain it. I don’t want to have to scroll past it when I’m working, and have my monitor made artificially smaller because my code has the same repeated error handling code everywhere. What a waste of brain cells.
      • theshrike79 3y ago
        Sounds yes, but isn't in practice. You look at patterns every time you read code, if the pattern is clear, it's easy to see from far away. Any disruptions in the pattern stop your progress and you need to zoom in to see what's actually going on.
        • josephg 3y ago
          Right; but the computer is much better at fixed patterns than I am. This is the philosophy behind linters, automatic indenting tools in IDEs and gofmt and friends. Given a choice, I’d rather that the compiler does the work to write “if err != nil …” thing, using any mechanism for it - exceptions, or whatever. You’re right of course. I can deal with patterns. I do so every day. I can type that code over and over and visually learn to spot when I do it wrong. But I’ve got a computer right here in front of me. I’d rather get the computer to do that work and spend my attention focusing on the task in front of me.
  • didip 3y ago
    Java boilerplate is way worse AND hidden behind annotations and so many level of abstractions!
    • richbell 3y ago
      That's mostly a facet of frameworks like Spring, not something inherent to Java itself.
      • josephg 3y ago
        There’s a strong culture in the Java community which actively encourages this style of programming. I agree - I don’t think it’s an inherent part of the Java programming language. At least not any more - recent versions of Java have a lot of nice features! But you still see a lot of this overly abstracted, “enterprise” Java code in the wild all over the place. I find it easier to just specialise in other languages.
• phplovesong 3y ago
  No 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 small binaries and cross compilation ”just works”. Go projects usually dont have many dependencies, but IF you need something there always a package for it. Go takes BC serioisly, 10 year old Go code compiles (usually) fine with the lastest version. Overall its a really good ”get shit done” language, and a good fit for larger teams
  • ingoaf 3y ago
    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.
    • Cthulhu_ 3y ago
      They may be geniuses, but some - mainly Ken Thompson - are also luddites, eschewing things like syntax highlighting. I mean they have a point - if you need colors to make your code readable, your code isn't readable. But yeah, I love how everything is well thought out and they just say "no" a lot.
    • infecto 3y ago
      This was one of the troubles I always had with Java. It was very hard for me to reason about with some of the wildly nested inheritance.
    • coffeebeqn 3y ago
      I remember looking through this insane taxonomy of abstractions of a button to find the code for when it got pressed. There weren’t that many buttons and they had no special requirements. Just trying not to find some real actual code that does the thing. I work on much bigger projects now with much less abstraction and my quality of life is much higher
• mtlynch 3y ago
  Small note: You can simplify the author's Go translation using anonymous structs: https://go.dev/play/p/4C42Ykkir8g https://go.dev/play/p/4C42Ykkir8g
  • OJFord 3y ago
    > an unwritten rule in programming says that if the language provides an easier (as in, more concise, more elegant) option, programmers will gravitate towards it. and thus it was shown!
• reginaldo 3y ago
  And Clojure has "Simple made easy" [1] [1] https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4 -> on of Rich Hickey's best talks
  • hu3 3y ago
    I wonder why isn't Clojure more popular.
    • zbobet2012 3y ago
      Syntax IMO. I know it's obnoxious, but the reality is most people read C like languages, not Lisp.
      • vasac 3y ago
        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 3y ago
          [deleted]
    • aeonik 3y ago
      It's the learning curve. There is a very DIY approach with composition, with lots of library choices. This makes it tough for beginners and intermediate programmers to jump right in and be productive. That plus functional programming, plus immutable defaults, plus Lisp, filter out developers who don't have a lot of experience, dedication, or a mentor. The more I learn though, the more I love it.
    • whalesalad 3y ago
      lisp turns a lot of people off - it does require some retraining of your mind. when people need to get shit done this friction is too great, and so they fall back on other tools. going to do advent of code in clojure this year though to force myself back into it - it's a great language.
• mbb70 3y ago
  If you going to compare simple and easy, you've got to mention the Simple Made Easy talk by Rich Hickey. Though debatable if Rich would find Go simple in his sense of the word. An example might be not having an insertion-order map iterator. https://www.youtube.com/watch?v=SxdOUGdseq4 https://www.youtube.com/watch?v=SxdOUGdseq4
• ajayvk 3y ago
  Starlark in go https://github.com/google/starlark-go https://github.com/google/starlark-go is a great way to combine the best of both, the ease of use of Python and the simplicity of go. I have been building a platform for deploying internal web applications using this approach https://github.com/claceio/clace https://github.com/claceio/clace. Use Starlark to configure the application, the platform itself is built in go.
• mrcwinn 3y ago
  I'll take simple over easy every time. Simple endures. Easy is like a credit card.
• deleted 3y ago
  [deleted]
• at_a_remove 3y ago
  Note that there's a Python complaint buried in there that was not a complaint about the original Python. It is a two-parter. First, package management is bad news (violating PEP 20 in that there's more than one way to do it) right now. The second is that the language has had some features and libraries deprecated and we're now on a much faster release cycle. Both are summed up in the bit "updates often lead to incompatibilities and runtime crashes." Languages evolve, I get it. Certainly, when I first looked at Python and saw that whole integer division thing I said, "They're going to have to ditch that." Many people smarter than I have had a wide variety of opinions as to how well the unicode transition was managed. Overall, though, Python has started to feel fiddly in the way that Perl did: a lot of syntactic sugar, programmers writing "clever" code-golf you have to unpack, hunting for external libraries, and the like.
• tetha 3y ago
  We as a sysops / platform engineering have decided on Go and Python as our languages as well. We'll be sending the dudes to 1-2 more python courses over the next year or so, and follow that up with a few go courses as well. We decided on that order, because the mortal part of python[1] can be picked up with less theoretical knowledge and requires less effort and knowledge to become useful imo. Like, if you know json.load, csv.load, some loops and other basics, some comprehensions, you can already do a whole bunch of useful things. And if you're a bit careful about your versions and dependencies, it can be easy to get this running on servers as well. Though you can still make your life a living hell with dependencies in python if you want to. And later on we want to offer Go for two reasons. First - we have to support some stuff on-prem on a variety of operations systems. Here, go's simple cross-compilation saves a lot of time. And a lot of our stack is written in go - consul, vault, terraform, ... being able to read this code, or even write providers, plugins and such later on will prove useful. Go just requires a bit more programming experience in my book to actually get into, as well as to start understand larger projects. 1: I mostly mean python not touching meta classes, multiple inheritance, monkey patching, binary patching and such. Darkness lies down that path.
• sethammons 3y ago
  I'm diving back into python after being mostly away for the better part of a decade having built high scale, highly available systems in Go during that time (including migrating several projects from python and perl to go). Being suddenly back in python is jarring. So much inheritance - abstract base classes and multiple inheritance via mixins, strange coupling in tests via over use of mocking and patching, and a reliance on method overloading to do magic things like make a field actually call out to the database on usage causing strange behavior that is unexpected. I miss Go and I will be pushing for it via the strangler pattern to bring productivity and sense to this project.
  • lemagedurage 3y ago
    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.
    • tgv 3y ago
      Django typically does this.
      • pphysch 3y ago
        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.
      • ShamelessC 3y ago
        Indeed. It's quite off-putting.
    • xwowsersx 3y ago
      Do you mean that the hierarchies don't tend to be very deep in Python? I don't tend to have deep inheritance hierarchies in Python, but I don't tend to have that in really any language I use. If you mean Python code doesn't tend to use inheritance in general, I'm not sure that's true. Django, DRF, the ML/DS packages, etc. all seem to use inheritance as much as any other language...I think? Maybe you're contrasting to those endlessly deep hierarchies you might find in Java? Otherwise, I'm just not sure what the basis is for saying you shouldn't rely on inheritance in Python, given that it is a first-class citizen due to its object-oriented programming model.
• hardkorebob 3y ago
  Ok so for context. Most of my experience doing stuff in the world is face to face customer service and craftsmanship. So from a blue collar type point of view, Python gets it done and it is an amazing language. I went into Go but it is a different animal for a different hunter. I enjoy that we have the flexibility to choose any language we want to use to get our digital tools made. The really interesting thing is how some of these digital languages are a 501c3 nonprofit, same as a church. Which strikes me really deeply cuz now that simply means that all these styles of expressing 0s & 1s are simply a church in cyberspace preaching the salvation to all our woes. (A foundation with a public mission) Interesting isn't? Of course don't obsess with the Legalese of it all and how it is different and go into defense mode. Besides who am I? Just a dudelitonthemostsublimetruevedas lol edit: for further clarity of my intent to comment
• jonathaneunice 3y ago
  The same simple vs. easy distinction arises again and again, year after year, in systems management tools. There are a ton of "simple" tools that are indeed very simple to understand. That does not making using them at any level of scale easy or low-effort. In fact, IME, often quite the opposite.
• lambda_garden 3y ago
  Python is valuable due to the ecosystem of libraries it offers. The language itself is extremely poor. I think this is not something most Python users are aware of since if you are doing ML, data-science or simple scripting there is little reason to step outside of the ecosystem. - Weird scoping rules - Very limited list-comprehensions - Ability to monkey patch things is a liability - Mutability by default - Lack of support for functional programming - Deployment story remains extremely painful - Tacked on type-system - Slow execution of pure Python code If this sounds like a rant... it sort of is. I find it really sad that so much programmer effort is being put into something with poor fundamentals. Many of these issues cannot be fixed with breaking changes.
  • alsodumb 3y ago
    I mean it's not like MATLAB where a company put in millions of dollars to make these libraries - the entire ecosystem was developed by open source contributors because they liked something about Python - sure, it's probably not as sophisticated as some of the other languages, but it has a low barrier of entry, it has users, and people developed libraries - in some cases because that's where users are and in many cases because it's the language they know! You're thinking about the programmer effort put into making certain libraries efficient, but think about the users who are reaping the benefits of low barrier to entry! More people are coding, getting comfortable with the idea of programming, and we should welcome them!
    • lambda_garden 3y ago
      > they liked something about Python I think it's simply what they already knew. Very few programmers learn multiple languages to any kind of depth. Is there any evidence that Python is an easy language to learn? I think we've reached a situation where beginners learn Python because it's seen as beginner friendly... because beginners learn Python!
      • EnergyAmy 3y ago
        It's definitely easier than many other languages to start learning. Absolute beginners don't want to worry about overflow, signedness, or anything like that. They just want to add some numbers and have it work. Python isn't perfect by any stretch, but having syntax like "for x in y:" goes a long way towards helping beginners not have to care about stuff they're not ready for yet. Admittedly, that's just an opinion. I don't know of any relevant studies, but Python wasn't always the preferred language for beginners, and it changed at some point. It feels like there must be a reason for that.
• debatem1 3y ago
  Go as a language is pretty darn good. Go as a runtime is a never-ending pile of problems mostly stemming from the authors' determination to fight the operating system for concurrency.
• whalesalad 3y ago
  Why is there not a Go with Python syntax? Golang is hideous to read.
  • lambda_garden 3y ago
    F# is basically statically-typed Python (with better performance).
    • whalesalad 3y ago
      I've been meaning to try it. Isn't F# modeled after Haskell?
      • lambda_garden 3y ago
        Kinda. F# is modeled after OCaml. OCaml and Haskell are both modeled after ML. I suppose you could say they are cousins.
      • munchler 3y ago
        F# comes from OCaml, not Haskell.
• 11235813213455 3y ago
  JS is both
  • meowtimemania 3y ago
    I also enjoy the simplicity of JS. Pros: * Being single threaded makes concurrency simple. No need to think about mutex/semafor/channel/etc. * Everything is a pointer so no debate on whether to use pointer vs value for variable * Not to many reserved keywords to learn before being able to write javascript * I like async/await Cons: * Tiny standard library * Very little standardization between projects * JS is often compiled/minified which can make debugging painful * Not so performant. Can't do true concurrency
  • rplnt 3y ago
    JS is anything but simple.
    • 11235813213455 3y ago
      getting started is simple, it's abundant in resources, libs but what's more complex is this laguage should be backward-compatible to not break the web, so there are often 3+ ways to do the same thing
• dxbydt 3y ago
  A 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.
  • sf_rob 3y ago
    The interesting experiment would be to make Go startups work in Python and Python startups work in Go :)
  • ShamelessC 3y ago
    I feel like it has more to do with those VC's having simultaneous investments in Google. Also, the "google pitch" for Go was generally that it was easier for junior devs to get started with, meaning your start up won't have to pay employees as much. Not at all true, of course but investors rely heavily on signaling.
  • aserafini 3y ago
    There are tons of startups that were built on Python that became enormously valuable companies: Instagram, Dropbox, Reddit, Spotify, YouTube, Pinterest, Quora, SurveyMonkey, Twitch, Zenefits. I don’t think the data supports your VC’s thesis.
• munchler 3y ago
  Anyone who appreciates the benefits of simplicity should skip Go and try functional programming instead. The basic tenets are a model of mathematical simplicity: * Values are immutable * Functions are pure (i.e. no side-effects) * Functions are values (i.e. can be passed as arguments to other functions)
  • Ringz 3y ago
    Exactly what I am doing with… Python.
    • pharmakom 3y ago
      Python has mutable data structures by default and you cannot have multi-line lambdas. The interpreter cannot optimise common functional patterns, so you pay a heavy perf cost. I could be wrong, but last I checked there is no TCO. Python is not even close to a proper FP language.
• mjan22640 3y ago
  Simplicity is hard.
• tonymet 3y ago
  The sad thing is that many people make language decisions on the beginner topics like syntax , literals, hello world or trivial samples. Sure a 20 line python app will be 40 lines in Golang, but that doesn’t mean 10k lines of python are 20k lines in golang. And there are way more serious considerations than LOC. Golang concurrency is amazing. You can reproduce an entire multi-core application stack with concurrent IO and CPU in a single binary. When you realize how much code is wasted on config, RPC, encode-decode, code-generation, concurrency & locking – you want a language that reduces the need for those things (or makes them really easy).
  • aserafini 3y ago
    My experience translating a codebase from Python to Golang (chat application), is that 20k of Python really does translate to around 40k of Golang to get the same functionality. And it’s not just due to language but also expressiveness of the library ecosystem.
    • tonymet 3y ago
      Are you including the libs in the calculation? E.g. if in python you can “import map” and in golang you implement map, which one is being counted.
    • Mawr 3y ago
      I very much doubt that. "The man barrier to translation was that, while at 14KLOC of Python reposurgeon was not especially large, the code is very dense. It’s a DSL that’s a structure editor for attributed DAGs — algorithmically complex, bristling with graph theory, FSMs, parsing, tricky data structures, two robot harnesses driving other tools, and three different operator-composition algebras. It became 21KLOC of Go." [1] [1]: https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.adoc https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.ado...
      • aserafini 3y ago
        It’s not a subjective opinion: I’m saying that I’ve actually migrated a Python application to Golang (real time chat application with a lot of business logic) and it was 2x the line count. I expect the Golang line count ‘overhead’ gets bigger for typical LoB software that has to address any sort of enterprise mess.
• Merrill 3y ago
  Some tools are easy to learn, some are easy to use, and some make it easy to achieve high performance given skill and effort.
• didip 3y ago
  Go is both simple and easy. For people who knows both, I don't know why you would choose Python (except if your domain doesn't have the libraries, like scientific/AI/ML stuff).
• JohnMakin 3y ago
  Am I insane that: > filtered_temps = { entry["city"]: entry["temp"] for entry in temperatures if entry["temp"] > 20 } is less readable to me than: > for _, ct := range temperatures { if ct.Temp > 20 { filteredTemps[ct.City] = ct.Temp } } ??
  • runekaagaard 3y ago
    A great typing system is generally a good thing if many people work on the same large project. I love how nim typings gets out of your way but are flexible enough to not tie you down. That being said - by Rich Hickey - typing also add a lot of complexity and non-optimal bindings between stuff. Untyped incremental development with just simple scalar types, and a single list, map and set type is wonderful. Large refactorings, not so much. Adding gradual typing to a project often gives you the worst of the two worlds. You still fear changing stuff, _and_ have lots of overhead doing all the typing. Either your project is fully type checked at compile time or it isn't. Python match statements are useful for checking structure and de-duplicating the container name: result = {} for temperature in temperatures: match temperature: case {"city": city, "temp": temp}: if temp >= max_temp: result[city] = temp Oh, and python typing has come a long way: from typing import List, TypedDict, Dict class Temperature(TypedDict): city: str temp: int def filter_temperatures(temperatures: List[Temperature], min_temp: int) -> Dict[str, int]: result = {} for temperature in temperatures: match temperature: case {"city": city, "temp": temp}: if temp >= min_temp: # Most of the time >= is what people mean. result[city] = temp case _: raise ValueError(f"Wrong temperature format: {temperature}") return result my_temperatures: List[Temperature] = [ {"city": "City1", "temp": 19}, {"city": "City2", "temp": 22}, {"city": "City3", "temp": 21}, ] print(filter_temperatures(my_temperatures, 20)) print(filter_temperatures([{"typecheck error": "and runtimeerror"}], 20))
  • stouset 3y ago
    And all of it is less readable than city_temps .select { |ct| ct.temp > 20 } .to_h { |ct| [ct.name, ct.temp] } Or let map: HashMap<_, _> = city_temps .iter() .filter(|ct| ct.temp > 20 ) .map(|ct| (ct.name, ct.temp) ) .collect();
• zubairq 3y ago
  I agree, a lot of things that look really easy often are really hard to make, as a lot of thought has to go into designing things to be easy to use
• spacecadet 3y ago
  haha as a Python and Go dev, Go Python!
• from-nibly 3y ago
  Go isn't very declarative. The thing that always gets me with go is how much stuff has to be (or is culturally) imperative code. This isn't article isn't wrong, simple things arent easy and easy things aren't simple. But saying one is better than the other is not right either. Turring machines are simple but we don't use them for anything serious cause it's WAAAAY to difficult to make anything worthwhile. It's been a while but golang keeps making simple is better decisions that hurt the language and ecosystem. Sure, saying just download a dep from git is simple, but it doesn't work. It makes the whole ecosystem fragile. Sure putting all your deps in a global folder is simple but it means you have to have a tool to manage envs and swap them out anyway to be able to write more than one app. Simple != Easy but neither of them equal good.