[HN Gopher] Go is my hammer, and everything is a nail
___________________________________________________________________
Go is my hammer, and everything is a nail
Author : markusw
Score : 166 points
Date : 2024-08-12 12:59 UTC (10 hours ago)
(HTM) web link (www.maragu.dev)
(TXT) w3m dump (www.maragu.dev)
| __s wrote:
| as the saying goes, when you're a nail the right tool is always a
| hammer
| markusw wrote:
| I guess we're at "I am Go and also a hammer and all the nails"
| then. :D
| lawgimenez wrote:
| I wish Go had a decent UI framework though.
| lagniappe wrote:
| Go has FyneUI, and it's great
| bborud wrote:
| Can you give me an example of a decent UI framework? Or
| frameworks?
|
| (I'm not a GUI programmer, but I've been dabbling a bit using
| Fyne. I figured that in the C++/C# sphere UI frameworks
| especially on Windows were sorted out until I read an article
| by some frustrated individual who listed all the problems he
| has with various UI frameworks on Windows. So I realized that
| perhaps this isn't as well sorted as I thought. I don't
| actually know)
| neonsunset wrote:
| Windows situation is kind-of a mess, but cross-platform story
| is in a good state mainly thanks to AvaloniaUI and Uno (and
| you can always use things like SDL2 or MonoGame if you feel
| like approaching the problem in a more "hands-on" way).
| euroderf wrote:
| Cogent Core looks promising.
| bborud wrote:
| I wasn't aware of that project. This looks pretty new, but
| after clicking around a bit in the documentation looks very
| interesting. I get the impression that it isn't as verbose
| as a lot of other frameworks I've seen.
| Propelloni wrote:
| > Can you give me an example of a decent UI framework? Or
| frameworks?
|
| The obvious answer is Qt, but Qt can be a bit of a chore to
| get into. Same is true for GTK. In my opinion more accessible
| options would be Fyne or Gioui. All of them have good Go
| bindings and are suitable for "standard fare".
| lawgimenez wrote:
| I mostly work on Swift and macOS, so SwiftUI.
| Cthulhu_ wrote:
| TBH this can be said about most programming languages, and this
| is one reason why Node / Electron based UIs are so popular
| because there's so many well-developed UI options then that are
| automatically cross-platform.
| DarkNova6 wrote:
| If all you know is a Hammer...
|
| I was searching for reasons why to use the Go-Hammer when there
| are comparable ones such as Java, C#, etc. but the article left
| me wanting.
|
| It strikes me that Go is riding the peak of hype languages,
| succeeding Rust and Node.js (which are all good pieces of
| technology and absolutely have their merit). And like with most
| hype driven decisions there is little (self) awareness of context
| and alternatives.
|
| Note, this is explicitly not about the languages themselves, but
| rather the larger cult(ure) of mainstream programmers around
| them.
| Scarblac wrote:
| I think he could have chosen those alternatives just as well,
| he just happened to pick Go. His argument is that he strives to
| use his chosen tool in as many situations as possible instead
| of having a bunch of different ones.
| markusw wrote:
| Yup, this exactly!
| busterarm wrote:
| > It strikes me that Go is riding the peak of hype languages.
|
| Very much so. Also it seems to be a strange choice as a solo
| developer when its strengths are explicitly targeted at large
| organizations. And I think the tooling is actually a bit of a
| mess compared to some other options. God help you if as a solo
| developer you start building on top of protobufs (another
| basically default choice in the Golang world...).
|
| I just don't understand why you wouldn't choose something
| faster and more expressive.
| ergonaught wrote:
| > I just don't understand why you wouldn't choose something
| faster and more expressive.
|
| The answer to this is as simple as genuinely asking,
| answering, and understanding why you don't do all of your
| development in assembly language.
| busterarm wrote:
| I didn't mean faster in terms of execution time but in
| terms of development time. And more expressive is doing
| more with less code.
|
| We're at complete opposite ends of the spectrum here -- how
| that indicated to you that I meant assembly...
| ergonaught wrote:
| It's the same principle.
|
| My own experience (I'm not the author) is that the
| investment required to reach the point where Go can be a
| "hammer" as in this case is lower (usually significantly
| lower) than with "faster and more expressive" languages.
| whstl wrote:
| Go might not be the most concise or expressive language,
| but it's quite fast in terms of development time,
| IMO/IME.
| Cthulhu_ wrote:
| Yeah, you just write code without worrying about whether
| it can be done more concise or clever, it's a very
| pragmatic language.
|
| The downside is code volume, but honestly that is rarely
| the problem in software.
| danielvaughn wrote:
| I'm genuinely curious which language you see as having a
| better development time. I don't mean that as arguing,
| I'm actually curious. I don't know much about Go but I
| just began learning it 2 days ago. I'm already 50% of the
| way done through a really nice TUI app, and I haven't
| even touched the docs.
|
| To me at least, it feels extremely productive so far.
| laserlight wrote:
| Developing with Python is faster.
| DarkNova6 wrote:
| Only for small or new projects...
| randomdata wrote:
| When leaning on libraries pushing what's new in computer
| science, like certain facets of machine learning as a
| prominent example, which generally aren't found outside
| of the Python ecosystem, certainly. But head-to-head on
| well-trodden computer science paths, Python doesn't stand
| a chance.
| Thaxll wrote:
| Protobuf is not the default in Go the default is REST. What
| tools are a mess? Go tooling ( runtime ) and IDE integration
| is very good.
|
| Go is not a hyped language, we're past that cycle, some
| critical and widely used software are built in Go, millions
| of people rely on it.
| busterarm wrote:
| Bazel.
|
| While not Go-specific, it's the extremely popular option in
| the space and I've seen it bring many-a-seasoned wizard to
| their knees in tears.
|
| Also managing your go dependencies if you cargo-cult other
| Google behaviors like monorepos tends to be painful.
|
| Basically just cargo-culting Google behavior == pain.
| Choosing golang can often be part of this behavior pattern.
| tail_exchange wrote:
| Bazel is not a Go default either. You can get very far
| just by using the default Go Modules, and this is much
| more common than repos using Bazel.
|
| Throw some Makefiles and shell scripts in the mix, if
| that's your thing, and that's perfectly fine.
| busterarm wrote:
| Obviously but if you look at a lot of Go projects you
| tend to see it.
|
| Especially in a corporate space. It should be obvious
| that I'm referring to things that you see in a
| professional environment with professional standards. I'm
| getting a lot of hate where that seems to be lost on
| people.
|
| And even if someone is a solo developer I don't assume
| that they don't ever have to work with other people's
| code -- that certainly wasn't my experience when solo
| contracting.
| tail_exchange wrote:
| Because you are attributing things that are common in
| enterprise environments (Bazel, monorepos, and Protobufs)
| to Go. It's fine if you hate these things, but saying
| that these are the defaults of Go isn't right, and I bet
| that's why people are hating on you. There's nothing
| default about them in Go. If you work with enterprise-y
| code, it shouldn't be surprising that a lot of them are
| going to follow Google's steps.
| busterarm wrote:
| Go was designed for use in enterprise environments. It
| was literally designed for Google's specific development
| problems.
|
| Nothing about Go's design should be talked about divorced
| from the context of it being tailor-built to solve
| Google-specific problems.
|
| All other uses of Golang are basically in the territory
| of rounding error.
| cy_hauser wrote:
| True for the early days of Go but I don't know about now.
| I think the switch started happening right after modules
| came out. Generics and the new range stuff seem more for
| the sake of growing the language than specific needs in
| Google.
| etse wrote:
| The opposite seems true (regarding Go being over-fitted
| to Google problems).
|
| It was designed for Google, but Google has not adopted it
| widely. Google is still heavily C++ and Java after all
| these years. The outside world loves it way more.
| Kubernetes isn't used internally at Google (except Cloud,
| which is not any different from any other cloud provider)
| though it's sponsored by Google. Bazel is probably in a
| similar boat.
|
| Being designed to solve Google problems doesn't mean that
| it actually solves Google problems well, or that Google
| thinks it does.
|
| I became introduced to Go through my startup and my
| experience was it a delight to work with in very small
| teams.
| giraffe_lady wrote:
| Go tooling was relatively very good a decade ago but other
| languages have improved a _lot_ since then, significantly
| because of its influence, and it 's now about average. It's
| still better than python, and C or C++ of course. But about
| even with typescript, ruby, shit even php and ocaml have
| nearly caught up with their tooling. Go's is significantly
| worse than rust god help us and elixir has always made good
| excellent here.
|
| I wouldn't call its tooling "a mess" but these days it's
| nothing notable either.
| Cthulhu_ wrote:
| I consider that a win too tbh; JS land has improved a lot
| with e.g. Prettier and now Biome, and those were inspired
| by Go's formatter and stance saying "shut the fuck up
| about code formatting already, this is how it's
| formatted, end of story, go worry about more important
| things".
| jimbokun wrote:
| Go was explicitly designed for fast compile times,
| especially compared to C++, and I haven't heard anything
| to suggest that's no longer the case. It was also
| designed as a more modern and mature replacement for C,
| and I can't think of many application domains where C is
| still the better choice.
|
| Python is at such a different point in the design space I
| don't think you can really compare the two. Same with
| PHP, Ruby, Javascript etc.
|
| For OCaml, need to decide how strongly you want to commit
| yourself to functional programming. Also, didn't OCaml
| have weak support for concurrency? Has that changed
| recently?
|
| Similarly with Rust, comes down how much you want to
| commit yourself to learning and conforming to the borrow
| checker.
|
| Elixir is an interesting comparison, as it's another
| language that allows you to build highly concurrent back
| end services. The tradeoffs are that Elixir provides even
| more robust scaling due to the Erlang VM. But Go allows
| you to more easily understand and optimize the memory and
| CPU performance of your application.
| kaba0 wrote:
| > Go was explicitly designed for fast compile times,
| especially compared to C++, and I haven't heard anything
| to suggest that's no longer the case
|
| Well, it's quite easy to be fast if you are just spewing
| out barely optimized machine code. Compilers aren't slow
| just for the sake of it.
| jimbokun wrote:
| My understanding is there are more fundamental reasons
| for why Go compiles faster, like how it handles
| "includes". And not supporting the C++ templating system.
|
| And some things that slow down compiles are not to
| improve optimization. But to support complex, higher
| level language features. Go seems to hit a sweet spot of
| being highly expressive without slow compile times.
| giraffe_lady wrote:
| Well regardless of the goals or intent of its creators,
| it has found success as a general purpose language suited
| to a broad set of unrelated tasks. And in fact that is
| exactly how it is being recommended here by the articles
| author: so within this context I don't think it makes
| sense to exclude these other languages.
|
| But even aside from that we were just talking about
| tooling at the moment.
| Thaxll wrote:
| Go tooling is far better than Elixir and I would say
| above Rust.
|
| You should have a look what the go command can do.
| giraffe_lady wrote:
| OK fair, I am a couple years out of date on go (and also
| rust) myself, so I'm comparing my recollection of both to
| elixir's current state.
| markusw wrote:
| Author here. Well, it has worked pretty well for me so far,
| so I don't know why I would switch. Go is fast and expressive
| enough for my use, and it's probably outweighed by being
| super familiar anyway.
|
| (BTW, in my eight years of Go, I think I've used protobufs
| maybe once or twice. HTTP FTW!)
| azthecx wrote:
| Do you have better alternatives to Protobuf?
|
| What are the shortcomings that you find with it? At work
| these choices have been out of my hands but I've used JSON
| Avro and Protobuf and I felt like Protobuf was the least
| prone to errors, best surrounding tooling and easy migrations
| while maintaining small payloads.
| azthecx wrote:
| Do you have better alternatives to Protobuf?
|
| What are the shortcomings that you find with it? At work
| these choices have been out of my hands but I've used JSON
| Avro and Protobuf and I felt like Protobuf was the least
| prone to errors, best surrounding tooling and easy migrations
| while maintaining small payloads.
| jimbokun wrote:
| Faster on what axis?
|
| Go has maybe the fastest compile times, for example. Which is
| very important when you are iterating on a project.
|
| What do you dislike about the tool chain? Seems better than
| most languages to me.
| kaba0 wrote:
| Java's toolchain may leave some to be desired in
| ergonomics, but compile time is just as fast if not faster.
| DarkNova6 wrote:
| What do you see missing in the Java toolchain? Frankly, I
| see it as one of the most complete and deep of all
| languages.
| kaba0 wrote:
| Only ergonomics, I do actually like most of it (maven
| central/repository model and gradle). It is one of two
| truly general build tools (other being Bazel), and being
| that generic/capable does mean that it can't be as user
| friendly as a single-language build tool like Go's or
| Rust's. But these all break down the moment you introduce
| another language/build step/whatever, while Gradle can
| build the whole hodgepodge that is the Android platform
| just fine, which is quite a testament to its power.
| moomin wrote:
| I think it's fine. Honestly I think there's a lot more deep
| developers out there than broad developers. It's just they
| don't blog about depth the way broad developers blog about
| their shiny new toy.
| kamikaz1k wrote:
| Go is getting hype because TS is old news. And people got tired
| of being nerd sniped into trying Rust and being let down.
|
| It's okay, hype cycles are good since it shakes up mainstream
| opinion and gets people to try stuff. Like a new trendy food. I
| don't feel much in the ways about it.
|
| How do you feel about Go outside of the hype cycle?
| auggierose wrote:
| How is Go not older news than TS?
| danielvaughn wrote:
| I think hype is more about trends than it is about age. PHP
| is going through a bit of a hype phase right now, for
| instance, mostly because of Laravel and the fact that the
| language has been silently improving a lot since the
| wordpress days, and developers are just now starting to
| realize it.
| markusw wrote:
| I believe there are many different hype cycles at once,
| depending on ones vantage point. The world is large!
| DarkNova6 wrote:
| > Go is getting hype because TS is old news. And people got
| tired of being nerd sniped into trying Rust and being let
| down.
|
| Sounds like my impression as well.
|
| > How do you feel about Go outside of the hype cycle?
|
| I think it's in a weird place, but I have a much higher
| opinion of the language ever since it got generics.
|
| There is nothing which is inherently unique to Go, but it got
| some neat technical features: Static compilation, garbage
| collection, good model for multithreading, fast compilation
| times. With these qualities you can get pretty far and have
| good cloud readiness.
|
| However, I'm a Java guy and the JVM is my working horse. I
| have seen how large projects (don't) scale once you have 8+
| developers and there are shortcomings in Go for projects of
| this size. And I think the explicit nature of nominal typing
| (e.g. Java) absolutely wins over the implicit structural
| typing one (e.g Go).
|
| You see this difference of philosophies by interface
| constraints: Java interfaces must be implemented explicitly
| and you can even limit who can implement them. Java is
| primarily a language designed for libraries & frameworks and
| the quality shows it.
|
| With structural and open implementation of interfaces, your
| line of code-ownership becomes blurry. This is not nearly as
| problematic as dynamic typing, but in my mind an interface is
| a specification. And you there should be a contract between
| the provider and consumer. This also helps with understanding
| the connections inside/between code-bases.
|
| Same about interfaces can be said about First Class Functions
| vs. Functional Interfaces. Functional Interfaces can be
| documented, domain-specific, extended and implemented. It
| feels like a perfect blend of FP and OOP, whereas with First
| Class Functions I feel like I am working with C-stylee
| primitives which don't help me express the nature of the
| solution I want to model nearly as much.
|
| As for Java, I have an immeasurable amount of respect for the
| current language designers (can't say I have the same respect
| for Go Designers after the drama surrounding generics). I am
| an avid reader of their mailing list and time and time again,
| they have shown deep thought and tremendous foresight (their
| way of work is quite inspiring). Yes, they have to live with
| some nasty historical baggage, but they have a very high
| level of quality.
|
| Then there are aspects such as the ever-evolving JVM, along
| with its choice of several garbage collectors and top-tier
| runtime analysis (Flight Recorder) & optimization (Hot Spot).
|
| Sorry, this is entirely subjective but you asked me how I
| "feel" about it :-)
|
| Summing it up, I'd say Go is a comfortable local maximum
| which can give you a whole lot, but ultimately is less
| flexible. But it's surely enough for 90% of applications. In
| this sense Go is like the big brother of PHP, which is a
| perfectly reasonable language if all you need in your backend
| are save/load database operations. Go can cope with that too,
| but also scale into non-trivial domains, the cloud and multi-
| threaded problems.
|
| But Java is "corpoaraty" and not "trendy", so most people
| don't even consider it as an option. And there are enough bad
| devs who started their carreer in JS/TS and want to move
| towards something more performant, that is still as ad-hoc
| and don't mind sharp edges because they never learned to
| reason about their application in a more formal sense.
|
| But looking at the work that is currently being done to the
| JVM, I'm looking forward to the near future when we can run
| Java-compatible bytecode on GPUs and AVX512.
| neonsunset wrote:
| Thanks for posting this.
|
| It's an unfortunate choice of "one hammer to rule them all"
| given Go does not offer necessary coverage at both low and high
| ends of abstraction (and performance) the way C# does. For me,
| it's a similar kind of hammer.
|
| (I prefer to think of it as a crowbar ;D)
| mapcars wrote:
| The problem with C# is its created by Microsoft, even if its
| a good language its hard to look at it and not think how much
| its limited while used outside of Windows.
| neonsunset wrote:
| It seems that you _might_ be asking this question in bad
| faith.
|
| But on the off chance you are not, please find previous
| replies that address the same kind of question below:
|
| https://news.ycombinator.com/item?id=41037792
|
| https://news.ycombinator.com/item?id=41189309
|
| https://news.ycombinator.com/item?id=41211767
|
| https://news.ycombinator.com/item?id=41197493
|
| https://news.ycombinator.com/item?id=41218353
| rlp wrote:
| This is no longer remotely true. Most .NET teams I know now
| deploy on Linux and develop on Windows/Mac/Linux.
| markusw wrote:
| I wasn't aiming for that. My point is more: I know Go already,
| it's good enough for my purposes, so I'm using that as my
| hammer. I could just as well have been Java or C# I learned
| eight years ago and used that for everything. :)
| danielvaughn wrote:
| I just began using Go literally 2 days ago, but I could
| already see building most of my projects in it from here on
| out. It has the type system I'd need from Java or C#, while
| being almost as simple and readable as Python. I love the
| module system so far and enjoy not having to decide on my own
| formatter.
|
| Go is perfectly boring and simple, and seems to get out of my
| way. At least, that's how it feels as a newcomer. I'm sure it
| will change over time, but I'm having a blast at the moment.
| kamaal wrote:
| What about the absence of exception handling?
|
| Plus OO has its own advantages, even if you don't use it
| all that much, its one of the best ways to fit problems
| into neat design patterns.
|
| Go seems to be missing those features.
| danielvaughn wrote:
| This is my first time working with a language that
| exclusively uses errors as values, and I haven't had time
| to develop any strong feelings about it. So far it feels
| nice because it makes error handling crystal clear, but I
| could also see it becoming cumbersome over time.
| jimbokun wrote:
| It can get verbose, but I'm willing to live with it for
| all the other benefits of the language.
| kamaal wrote:
| I mean to this end, Go is more closer to Perl(C/Unix
| family) than to Python(Pascal? family).
|
| But by now most programers are so very used to making the
| language do a lot of error handling kind of chores that
| having to do them manually kind of feels doing work that
| shouldn't be done(Like doing what the language should
| have been doing).
|
| Of course you could bolt OO onto Go. In a way similar to
| how Perl provides kind of bare bones means assemble a OO
| system. But that is not the point, having syntax to this
| baked into the language just makes it easier and
| standardised to learn and use well.
|
| Perhaps Go is Perl done right? Than a replace for Python.
|
| But one has to see for how long it can maintain its
| minimalism. On the longer run code turns to be as
| complicated as the problem you are trying to solve.
| Removing the features doesn't make the code simple, it
| simply make it explicit(a.k.a Verbose)
| kaba0 wrote:
| It's the exact same broken system as has been known from
| C, it's literally checking `errno` all the time.
| markusw wrote:
| What you see as missing, others (including myself) see as
| delightfully constrained and solved in a different way.
| kasey_junk wrote:
| Go has exceptions and exception handling in the form of
| panics and recovers, but go devs are discouraged from
| using them.
|
| Go also supports most of the typical attributes of oo. It
| has polymorphism and encapsulation it's just missing
| inheritance and uses composition instead. Most Java and
| C# code basis have stayed away from inheritance (for a
| long time) so there isn't that big a difference.
| Cthulhu_ wrote:
| ? It doesn't have exceptions, so it doesn't need
| exception handling. It has an error system / standard
| that isn't based on exceptions.
|
| I only know exceptions from Java myself, and in practice,
| what it calls exceptions are often... well, not
| exceptions at all. Files missing, SQL queries returning
| no errors, division by zero are not exceptional
| situations, but normal day to day events. And an
| exception generates a stack trace, which is an expensive
| operation.
|
| I mean one way to avoiding that is defensive programming
| - check if a file exists, do a count on the SQL query
| first, do a pre-check or assertion before dividing - but
| that adds more and more code that you need to write, test
| and maintain.
|
| OO has merit for what you describe, but Go's alternative
| works just as well (imo) for that purpose; you have
| struct types containing data, you can add methods to
| those types to encapsulate behaviour. Go doesn't have OO
| inheritance, but inheritance has been out of fashion for
| years now so it's not missed.
|
| TL;DR, exceptions and OO are solutions to problems, Go
| has its own solutions to those problems, neither of which
| are difficult to understand.
| kamaal wrote:
| The whole idea of exception handling with try/catch comes
| from the fact that problems and error handling can all be
| standardised into one structure of patterns. Once you are
| here you can be sure the language(compiler) and
| tooling(IDE/Editor etc) will generate them for you and
| provide you with means to handle them.
|
| Nothing much has changed in terms of problems and
| interfaces. So the errors will remain the same.
|
| Now when you use go, you will have to write a lot of code
| that other wise the language+tooling could do
| automatically for you. This is just doing work that you
| shouldn't even be doing the first place and pointless
| verbosity.
|
| Minimal is not always better. And some parts just feel
| like they were omitted because the language designer
| didn't want to do the work for you. Whereas the whole
| point of a programming language is that it does as much
| work for you as it possibly can and make it easier for
| you.
|
| Just saying writing the same/similar code over and over
| again is waste work.
| randomdata wrote:
| Of course, Go has try/catch, albeit under the keywords
| panic/recover. The whole idea of not using it, most of
| the time, except for the case of exceptions, comes from
| the fact that problems and error handling have shown to
| not in any way fit well into a standardized structure.
| Ruby, for example, came to the same realization even
| before Go. This is something that was already becoming
| understood before Go was conceived.
|
| _Sometimes_ it works out. Certainly encoding /json in
| the Go standard library shows that it's quite acceptable
| to use where appropriate - the programming tools are
| there to use, but it turns out that it is rarely
| appropriate. Which is also why most other languages are
| also trying their best to move away from the practice as
| a general rule, if it ever was adopted at all.
| erik_seaberg wrote:
| Throwing prevents the caller's control flow from passing
| into code that assumes a useful value was returned and
| ready to be consumed when it wasn't. Handling a success
| or a failure with exactly the same code shouldn't be a
| default because it almost never makes sense.
|
| A Java exception can suppress stack trace init if needed,
| letting an instance be created once and reused very
| cheaply (though logs will be less useful).
| jimbokun wrote:
| In modern Java applications, interfaces are favored much
| more heavily than OO designs relying on inheritance.
|
| And Go has very nice support for interfaces. To the
| extent you don't even need to declare support for an
| interface. Go just figures it out if your type supports
| all the methods in the interface.
|
| If you mean classical Smalltalk style OO, no Go doesn't
| support that, but neither do Java or C# or C++.
| jerf wrote:
| Interfaces and functions do pretty much everything
| inheritance does. It's just cut in a different direction.
| If you go in demanding that Go support inheritance you'll
| be in for a bad time; if you go in demanding that it have
| _some_ good solution to those problems that you may not
| be used to, you 'll find it generally has them.
| markusw wrote:
| It actually gets even better! :D Enjoy the journey!
| jimbokun wrote:
| I've been using it for work projects for a year or two now
| and I still feel the same way as you.
| mapcars wrote:
| Just looking at Go after having experience with Erlang and
| Crystal, does it still have a narrow-minded view of what
| features language won't support?
|
| Like I remember there was a whole drama about generics,
| errors being simple strings and always returned without being
| able to raise them, is this attitude still there or have
| things changed?
| markusw wrote:
| Nope, it's the same. It's one of the things I value about
| the language and project.
| Cthulhu_ wrote:
| That attitude is still there because there is no compelling
| reason to move away from that. A lot of languages have been
| diseased by bolting on features for no other reason than
| different languages have them, and it's overcomplicated the
| languages and fragmented the codebases.
|
| Example, if you ask ten Scala developers to solve a
| problem, you'll get ten different solutions. That number
| drops quickly for less feature-rich and more opinionated
| languages like Go.
| mapcars wrote:
| I agree with that and Scala example, but also languages
| diseased by not evolving and not allowing new widely-
| accepted features. I wonder what would happen with Go if
| they never changed their mind and kept it without
| generics?
|
| My point is not about bringing all features other
| languages have (its just not possible unless its a lisp),
| but rather creating a new language and not understanding
| how vital something like generics is for general purpose
| programming. That is an orange flag for me.
| randomdata wrote:
| _> I wonder what would happen with Go if they never
| changed their mind and kept it without generics?_
|
| Change their mind? What do you mean? Go always maintained
| it would get them, once the right design was found -
| which was echoed by Ian Lance Taylor actually working on
| them even before the first public release. He alone has,
| what, 8 different failed proposals?
|
| The problem was always, quite explicitly, that nobody
| within the Go team had the full expertise necessary to
| create something that wasn't going to be a nightmare
| later. As you may recall, once they finally got budget
| approval to hire an outside domain expert, the necessary
| progress was finally made.
|
| Being an open source project, you'd think the armchair
| experts on HN would have stepped in and filled in that
| gap, but I suppose it is always easier to talk big than
| to act.
| jimbokun wrote:
| No, that attitude is core to the design of Go and one of
| the key reasons people pick it for projects.
|
| Generics were eventually added. But not until they thought
| through very carefully performance and compilation time
| implications.
| konart wrote:
| Well, Go has generics now and you can do quite a few tricks
| with errors. In the end error handling logic is up to
| developer.
|
| UPD: thankfully Go does not try to bring in every "feature"
| possible. Not without consideration at least.
| DarkNova6 wrote:
| And this is a perfectly reasonable approach. Frankly, the
| cost/benefit ratio of delving into another language is most
| often not appealing.
|
| As a suggestion, you could have delved more into the "hammer"
| metaphor, mentioning that a hammer is a flexible tool: nail
| planks, remove nails, smash things and even as a defensive
| weapon! You shouldn't misuse it for drilling walls, but that
| is outside the required scope of your work etc.
|
| But in the end it's a very personal post, and we typically
| crave here for universality and judge posts up high from a
| meta-perspective, haha. Often neglecting that we were not
| actually the intended audience.
| jimbokun wrote:
| I'll give it a shot.
|
| The tools make a lot of decisions for you that are pretty
| arbitrary, like how to format code, freeing up brain cycles for
| other things.
|
| It compiles very fast, so the iteration cycle is similar to a
| dynamic language with a REPL. Very little time between making a
| change, running and seeing the new result. The language is
| designed from the bottom up for fast compile times even in
| large projects, with features at odds with fast compilation
| rejected.
|
| Decent sized community and library ecosystem.
|
| The networking APIs are very simple and productive. More and
| more back end code is being written in Go for this reason.
|
| The semantics are straight forward. The other programming
| environment I need to deal with at work is Spring Java, which
| is unjustifiably complex and obfuscated for what it does. Go
| allows you to read the code and run the program in your head
| understanding semantics and performance characteristics.
|
| Builds single file executables that are simple to deploy.
|
| Has just enough high level features to be productive without
| compromising above points about simplicity, fast compiles, and
| comprehensibility. Channels and go routines work very well to
| model concurrency across a wide array of problem domains.
|
| Maintainers are careful about adding new features. Generics
| took a long time to arrive, but when it did was very well
| thought out and did not negatively impact performance very
| much.
|
| I'm sure I'll think of more.
| alemanek wrote:
| I am someone with significant experience in Java, C#, C++, and
| JS/TS. I am a bit of a newbie to Go but have used it for a few
| things at work. So, I can give a bit of a comparison for you.
|
| I really like the DevX and strong standard library of Go. Also
| I really like that the community around Go has a strong
| preference for just using the stdlib and not going crazy with
| third party libraries.
|
| Languages are just tools but I have a strong preference for Go
| for backend services and CLI applications now. Just my 2cents.
| DarkNova6 wrote:
| Hey, thanks for the reply. That sounds really nice!
|
| I wonder, which aspects of the "Go" std lib are considered
| strong? Would you say it is more like .net where the std-lib
| also comes with framework-grade capabilities such as REST-
| endpoints and setting up applications?
|
| Because in the classical sense of a library, I think Java is
| fantastic (collections, strings, NIO, HTTP 2.0, etc.). But it
| misses framework-level out-of-the-box solutions.
| daghamm wrote:
| How can you call Go hype driven?
|
| It was literally designed to be "boring".
| cy_hauser wrote:
| I think it was the Go Marketing Team who decided to call it a
| boring language. "Boring" tested well for hyping the
| language.
| gnfargbl wrote:
| It feels extremely strange to see Go described as a "hype"
| language. It was _somewhat_ hyped around seven years ago, which
| is when I started using it almost exclusively. Before that, it
| had a strong hype peak about fourteen or fifteen years ago,
| just after it was born.
|
| However, it's not a young language any more. At this point I
| would actually submit the opposite criticism: it is a mature
| language which is perhaps starting to suffer from middle-aged
| spread, as the bored maintainers start to stuff in more
| features which the language doesn't genuinely need. (Example:
| Iterators. Sure they're nice, but does the language _really
| need_ them?) If anything, I would say it 's going more the way
| of Java than Rust or Node.
| kaba0 wrote:
| Count the number of posts with Go in the title, vs any other
| programming language. It easily beats out everything both
| here and on lobsters.
| gnfargbl wrote:
| Well, it's a very usable language which is strongly typed
| (by any layman's definition), easy to pick up, easy to get
| stuff done in, relatively easy to live with and easy to
| maintain. If it's hyped then it's only in the same way The
| Beatles and Pizza are hyped.
| markusw wrote:
| I like that! Go is basically pizza! :D
| kjksf wrote:
| Maybe, but 80% of those are complains of some sort.
|
| That's the opposite of hype.
| cy_hauser wrote:
| I did this about 1-1/2 years ago and just reran the
| numbers.
|
| Today: "written|built in Rust"
| 1113 (1036|77) "written|built in Go/Golang" 1050
| (889|25) / (119|17) "written|built in Python":
| 452 (422|30) "written|built in Javascript/JS" 286
| (233|14) / (34|5) "written|built in Java"
| 115 (109|6) "written|built in TypeScript" 97
| (89|8) "written|built in C#" 46 (43|3)
| "written|built in Stone" 13 (13|0)
|
| Feb 2023 "written|built in Go/Golang"
| 918 (792|17) / (102|7) "written|built in Rust"
| 832 (790|42) "written|built in Python": 390
| (364|26) "written|built in Javascript/JS" 269
| (220|14) / (32|3) "written|built in Java"
| 107 (101|6) "written|built in TypeScript" 66
| (61|5) "written|built in C#" 41 (38|3)
| "written|built in Stone" 10 (10|0)
| bborud wrote:
| I think the hype has already peaked for Go. When we switched to
| Go 8-9 years ago I already felt the hype had died down. We were
| late to the party. And I saw that as a good thing. To me it
| suggested Go was going to stick around.
|
| And now, almost a decade later, we're still using it.
|
| Note that at my company, we're a bunch of grumpy old guys with
| about 30 years of experience each. If you dangle a new and
| shiny language in front of us, our default instinct is to tell
| people to get lost. We don't do "fashionable". We tend to make
| investments in learning languages that we expect to get at
| least a decade out of.
|
| And I don't think Go is succeeding Rust. From what I can tell,
| people are going in both directions.
| jerf wrote:
| Go and Node have some significant overlap, but Go and Rust
| are barely even competitors. Of course there's a lot of
| programs that you can use either to write. There's a lot of
| programs where it hardly even matters which language you pick
| at all because they're all perfectly acceptable solutions,
| though, so that really isn't saying much. But if you map
| languages out by the programs where language choice matters
| at least a little and where a given language is legitimately
| one of the top contenders, Go and Rust don't have a
| particularly strong amount of overlap in my opinion. They do,
| but again, lots of languages have overlap; I don't see the
| Rust/Go relationship being particularly heavily overlapping.
| (Go/Java or Rust/C++, now there's overlap, for comparison.)
| bborud wrote:
| > Go and Node have some significant overlap, but Go and
| Rust are > barely even competitors.
|
| Among the people I know Go and Rust seem to be at the top
| of their list. Almost all people I know who program Rust
| also know Go. Not as many Go programmers I know program in
| Rust as well, but some know Rust and even more want to
| learn it. Which probably isn't too peculiar because Rust is
| more of a kerfuffle to program in.
|
| I'm not denying your observation. I'm just reporting that
| from where I am, things look a bit different.
|
| I agree that it mostly doesn't matter that much which
| language you choose -- as long as it is a language that can
| meet certain minimum standards. In my view there is only
| about a handful of languages to actually choose from.
|
| The first is that it must be possible to produce proper
| binaries. For instance, Python is unacceptable to me since
| it tends to place a large burden on the user. Next, it has
| to be a somewhat mainstream language with a sufficiently
| large community. With that sorted the more technical stuff
| needs to be evaluated. Like its standard library, how
| ergonomic the tooling, what quality software/libraries the
| community produces is etc.
| gavindean90 wrote:
| Honestly it gave me the feeling of not arguing to use Go but
| instead arguing to use the full featured language you know the
| best. The caveat being that it is of you are a single developer
| making all the decisions and writing all the code. Seemed to
| make a good case for that
| caerwy wrote:
| This article is not so much about Go but about choosing to
| specialize in one language ecosystem instead of spreading one's
| attention across several.
| dimgl wrote:
| Which is unfortunate because I think Go is very useful in a
| wide variety of business contexts.
| the_real_cher wrote:
| Then you would find this article very fortunate.
| the-grump wrote:
| It would be a misfortune indeed if I had nothing to
| complain about.
| nerdponx wrote:
| With the caveat that the broadened perspective you obtain by
| learning a variety of languages will make you better at your
| primary language.
| Cthulhu_ wrote:
| This is true, but it doesn't mean you should actually use a
| variety of languages for your day job if you're self-
| employed; that is, you lose some productivity if you choose
| an unfamiliar tool, and you'll shoot yourself in the foot if
| you choose a language unsuitable for the problem at hand.
|
| The other thing to watch out for if you're in a corporate
| setting is that if you use a language nobody else is using at
| your company, your project is doomed and / or it will be
| stupid expensive compared to other projects because it uses a
| different language from the rest of the organization. See
| also https://boringtechnology.club/
| markusw wrote:
| I would say there are many, many other ways to broaden my
| perspective, not just learning and using a different
| programming language. There are so many things to learn!
|
| (And I don't necessarily suggest not learning different
| languages, if one fancies that. I just don't use any other
| ones at the moment.)
| ziml77 wrote:
| I actually find it a bit of a curse to know too many
| languages. Because settling on one for any given project
| becomes very difficult. Like you start coding it up and
| then hit some friction and start thinking about one of the
| other languages you know that would be more elegant. Or you
| might have chosen a language that does a lot of things
| elegantly but then start thinking of the performance you've
| given up performance for that. Swapping languages will
| never stop those thoughts because there's always tradeoffs
| somewhere.
| markhahn wrote:
| I always wonder: why do some people like to do this
| (spreading)? I wonder the same about people who are "distro
| tourists". The latter tend to spend a lot of time on what seems
| like unproductive diddling (desktop skins, etc).
| randomdata wrote:
| 1. Because I like engineering more than programming. If a
| problem is best solved by, say, a mechanical system then I
| will do that instead. But even where programming provides the
| best solution, not all ecosystems are equal. If I have a
| problem best solved by, say, AI/ML, it is often impractical
| to avoid Python. Likewise, if I have a problem best solved in
| the web domain, it is often impractical to avoid Javsacript.
| SQL where databases are the best solution. So on and so
| forth.
|
| 2. Because I like to learn. In my younger days, I found a lot
| of value in exploring the different ways people live. In
| fairness, I've toured the programming world enough by now
| that I am less compelled to keep go on "programming language
| vacations" - at some point you start to feel like you've seen
| it all, but believe I would be a far worse programmer today
| had I not been able to take ideas from a wide range of
| different cultures over the years. There are some good ideas
| out there that don't seem to ever gain mass adoption outside
| of their originating ecosystem.
| CodeMage wrote:
| Because there's so much to learn from having different
| perspectives.
|
| Back in 2006, I was working mainly in C with a bit of C++.
| One of the things I was taught was that "macros are evil",
| period. Then, in my spare time, I decided to try Common Lisp.
| I had a blast. I never wrote anything more useful than a
| half-assed catalog for my MP3 collection, but I learned a
| lot. My main takeaway was the power of metaprogramming --
| with all of its footguns and pitfalls -- and took that
| knowledge with me to my day job, where I suddenly had a more
| nuanced view of how preprocessor macros can avoid being evil.
|
| Later, when I changed jobs, I went back to Java, which was my
| main language before the C stint. I slipped back into the
| comfort of having my memory managed for me and the
| expressiveness of OOP. But in my spare time, I discovered
| Self and Io, and the fact that you can have OOP without
| classes blew my mind.
|
| At that same job, I undertook the task to make our
| proprietary in-house language not only transpile to C++, but
| also compile to be executed on JVM. Understanding how JVM
| bytecode instructions work was easier than it might have been
| had I not dabbled in Forth in my spare time.
|
| These days my day job involves working with C++ full time,
| but my hobby projects in Rust taught me to structure my
| thinking about the ownership and lifecycle of memory
| allocations.
|
| So yeah, most of what I do in my spare time with other
| languages is largely "unproductive diddling" if you only look
| at the code I write in those languages, but the insights I
| take away with me are useful.
|
| Also, it's fun ;)
| matwood wrote:
| I can think of many reasons. Seeing other language
| perspectives definitely can help with your primary language.
| I have experienced this. But, I have also explored other
| languages as a means of procrastination or ways to do
| something _easy_ when bumping into the more challenging
| depths of my language of choice.
| packetlost wrote:
| For me, expertise in a particular language is _rarely_ very
| useful. Expertise /specialization is _mostly_ a time tradeoff for
| particularly thorny issues, but IME they _rarely_ come up in a
| programming language context (usually it 's domain or particular
| codebase-specific). That being said, Go is a really good
| "workhorse" language.
| read-bird wrote:
| "The world is laaaarge. The number of projects are basically
| infinite. Even if I carve out a tiny subset of infinite, that's
| still infinite." I liked the use of this wisdom in there.
| kingforaday wrote:
| You'll enjoy set theory then. Just call the first set aleph-
| null.
| markusw wrote:
| Thanks! I guess I have moments of insight sometimes. :D
| ultrablack wrote:
| You could have written the same article about C#.
| markusw wrote:
| Yes, I definitely could have. But I don't know C#, so that
| would have been an awful blog post. :D
| xnorswap wrote:
| Indeed, this article would read just as well after applying
| s/\bgo\b/C#/ig, or should I say:
| Regex.Replace(articleText, @"\bgo\b", "C#",
| RegexOptions.IgnoreCase);
|
| Or indeed most general purpose languages, which the article
| itself mentions.
| neonsunset wrote:
| The C#'s regex engine would have run circles around Go's here
| though while doing so :)
|
| https://github.com/BurntSushi/rebar?tab=readme-ov-
| file#summa...
| hk1337 wrote:
| This is the same thing everyone says about PHP, negatively.
|
| Don't make Go the next PHP. PHP has some good updates recently
| but it still has some people with a negative experience with it.
| Cthulhu_ wrote:
| PHP fell foul of adopting other languages' features to try and
| make itself more popular though (OOP, typing, err... I don't
| know PHP anymore), Go is actively resistant to it. Or,
| resistant as in, "sell it to us" where it's a really hard sell
| to add something to the language that can already be done in a
| different way. The error handling debate from a few years ago
| was great, a few really well thought-out proposals were made
| but in the end, people were like "...this is not an improvement
| over how we do it right now".
| aeyes wrote:
| You don't have to use all these new fancy PHP features as
| long as you don't use any third party libraries. I still
| write PHP just like I did in 2002 and it works.
|
| It's not as pedantic as Python which makes it pretty useful
| for small data manipulation tasks which I have to do every
| now and then.
| nj5rq wrote:
| > all popular programming languages can do basically anything
|
| That's just very not true...
| nerdponx wrote:
| Got an example?
| randomdata wrote:
| SQL might be _the_ most popular programming language. Perhaps
| you can think of something it cannot do, practically
| speaking[1]?
|
| [1] Theoretically it might be able to do anything, but the
| context is clearly talking about what is, not what could be.
| jimbokun wrote:
| It's true in terms of Turing Completeness.
| zarzavat wrote:
| Turing complete just means you can simulate a Turing machine.
|
| A Turing machine is a mathematical model of a computer, it's
| not a real computer.
|
| Real computers can do things that Turing machines can't do,
| e.g. generating random numbers[0], interfacing with hardware,
| etc.
|
| [0] https://en.wikipedia.org/wiki/RDRAND
| mapcars wrote:
| We need some example here, otherwise any language can generate
| code in the target language to do anything. And in the end all
| languages generate machine code one way or another so thats
| pretty much the same thing.
| jimbokun wrote:
| None of these reasons are specific to Go. They apply just as well
| to any Turing complete programming language.
|
| Not to say the arguments are bad. Just that the argument is for
| picking one tool and using it for everything to benefit from your
| investment in that tool across all your projects.
| markusw wrote:
| Yep, totally agree! But I learned Go, so I wrote about that. :D
| I tried Brainfuck once, but I don't think my brain can wrap
| that enough to make it a career.
| leecommamichael wrote:
| The author feels happy and contented and you all are getting
| defensive. He's a solo dev, just recognize that that scopes his
| projects and stop trying to shoot him down.
|
| Use what you want.
| markusw wrote:
| I choose to read most comments in a positive light, but thank
| you for your kindness. :)
| daghamm wrote:
| The author lists multiple reasons for this, but for me the
| biggest one is the first one: Go is good for almost _everything_.
|
| I have extremely good productivity when using Go. Once your
| project exceeds 100 lines it is usually even better than python.
| And yes, I am aware that Rustians did a survey where Rust was
| crowned as the most efficient language but in my reality (which
| may differ from yours) Go is simply the best tool for most tasks.
|
| Why is that? Well, for me there are 3 reasosns:
|
| 1. The language is extremely simple. If you know 20% of C you are
| already a Go expert.
|
| 2. The core libraries are extremly well thought.
|
| 3. Batteries are included. The toolchain and the core libraries
| alone can do 90% of what most people will ever need.
|
| When people argue about the validity of these claims, I simply
| point them to this talk
| https://go.dev/talks/2012/concurrency.slide#42
| kaba0 wrote:
| How is it different than, say, java for this generalist
| purpose?
| colonelpopcorn wrote:
| Just from an ergonomic standpoint it's a million times easier
| to deploy a go binary instead of a whole jvm and a jar file.
| Dansvidania wrote:
| java on its own is not a competitor to go, IMO, due to the
| batteries included "culture" in the go ecosystem.
|
| I would need to compare it with, for example, Java +
| Spring(Boot).
|
| I find Go to be simpler and more pleasant to use.
| matwood wrote:
| I agree with Go being simpler, but modern Java and Spring
| Boot is also _fine_. Backend programmers are spoiled with
| riches nowadays with all the completely workable options we
| have.
| lantry wrote:
| IME, there are two main differences between go and java:
|
| 1) go is more "batteries included". Modules, linting,
| testing, and much more are all part of the standard cli.
| Also, the go stdlib has a ton of stuff; in java, there is
| almost always a well-built third party library, but that
| requires you to find and learn more things instead of just
| reaching for stdlib every time.
|
| 2) golang is "newer" and "more refined". this is pretty
| subjective, but golang seems to have fewer features and the
| features are more well-planned. It's a more "compact" or
| "ergonomic" language. Whereas java has built up a lot of
| different features and not all of them are great. You can
| always ignore the java features you don't like ofc, but this
| is still a bit of cognitive overhead and increased learning
| time.
| nerdponx wrote:
| There are surprisingly few languages in this category,
| especially if you limit consideration to statically typed.
| Go, C#, Swift? Nim, Crystal? F#? Kotlin?
|
| Go is not my favorite language, but it really is
| exceptional in terms of its effective utilitarian design.
| hughesjj wrote:
| Eh, imo the go libraries still aren't up to par with out of
| the box java libraries. Like there's still no Set class,
| nor the equivalent of Map.keys. yeah they're easy to write
| but that's still not an included battery.
|
| Also, while the cli to add stuff is useful, there's still
| nothing to the level of maven or gradle for dependency
| management, and I usually find myself doing some fun stuff
| with `find -execdir` for module management.
|
| Different strokes for different folks though. Java (really,
| kotlin) still makes a ton of sense for backend to me given
| how the jvm is architecture independent and you don't have
| to make tradeoffs/switch to graal if it's a long lived
| service.
|
| Golang is nice, love it, but it's still got a bit to grow.
| I'm just happy they added modules and generics. I don't
| think it's a matter of being 'well thought out' as much as
| it's a simple language that cares a lot about simplicity
| and backwards compatibility and has iterated ever since.
| For my the killer app isn't go routines so much as you can
| produce a binary that's resilient even to
| shared/dynamically linked libraries in all platforms, which
| is awesome for portability independent of environment. No
| more gcc vs clang vs msvc headaches, no more incompatible
| shared libraries, no more wrong version of jvm or a bad
| python modules path etc.
|
| Oh, also java had like a 15 year headstart on golang, and
| it wasn't until java 8 that many of my biggest complaints
| were addressed. And yeah stuff like apache commons
| +log4j+mockito/junit are pretty much required dependencies,
| and maven/gradle aren't language native.
|
| The best STL is probably python imo but even that doesn't
| support a proper heap/priority queue inplementation. For
| data structures specifically I think java/kotlin has the
| best STL. All of this ignoring .NET or apple platforms.
| duskwuff wrote:
| > Like there's still no Set class
|
| map[T]struct{} ?
| erik_seaberg wrote:
| https://github.com/deckarep/golang-set offers a thread
| safety option and methods like contains all, intersect,
| and equal.
| aaomidi wrote:
| Dependencies in Java are a pain in the ass.
|
| Publishing libraries for your own consumption is even harder.
|
| Publishing libraries for world consumption means now you also
| need to be a PKI expert.
| conor- wrote:
| As someone who isn't super proficient in Java I usually find
| Java daunting to get started with full of buckets of "meta"
| issues like in my other comment.
|
| What JVM do I use? Does it matter?
|
| Does it matter what version I install, what if I have to
| install/manage multiple versions?
|
| If I want to write a web service can I use vanilla Java
| stdlib or do I have to use Spring or some framework? If I use
| Spring, do I have to get into the weeds of dependency
| injection and other complexity to actually get my app off the
| ground?
|
| With Go, none of those questions exist. I install the latest
| Go, create a main.go file, I use net/http and I'm off to the
| races.
| neonsunset wrote:
| I think it's good that Go, among other well-made
| toolchains, brought attention to importance of good CLI UX.
|
| But it's not something that is unique to Go:
| dotnet new web dotnet run curl
| localhost:5050
|
| also 'dotnet watch' for hot-reload.
| cube2222 wrote:
| Yeah, this. It's just good enough for 95% of use-cases, while
| being very productive.
|
| Personally, one of the biggest selling points for me is that
| imo modelling concurrency and asynchronicity via fibers
| (goroutines), rather than async/await, is just a ton easier and
| faster to work with. Again, there are use-cases for the
| alternative (mainly performance, or if you like to express
| _everything_ in your type-system) but it 's just great for 95%
| of use-cases.
| conor- wrote:
| Go is the only language I've ever felt highly productive
| working in. Oftentimes in other stacks I find myself in
| analysis paralysis on meta things that don't matter:
|
| - what design patterns/language features make sense to use
|
| - what is the best lib to accomplish X
|
| - how do you keep things up to date
|
| With Go, the language is so simple that it's pretty difficult
| to over engineer or write terse code. Everything you need is in
| stdlib. The tooling makes dependency management and upgrades
| trivial because of strong backwards compatibility.
| justinsaccount wrote:
| Yep.. say you wanted to make a simple http service that needs
| to
|
| * request a json.gz file from another HTTP service *
| decompress it * deserialize the json, transform it a bit
|
| That's net/http (and maybe crypto/tls), compress/gzip,
| encoding/json. I need to make zero decisions to get the thing
| off the ground. Are they the best libraries in the world for
| those things? no.. but will they work just fine for almost
| every use case.
| chubot wrote:
| Sounds like curl ... | jq ...
|
| to me!
|
| Not saying you shouldn't use Go for that problem, in a
| particular context, but it does drive home how much of
| programming is glue ... there is combinatorial amounts of
| glue, which is why JSON, HTTP, compression, etc. end up
| being part of so many problems
| dartos wrote:
| There's a big difference between building something on
| curl and jq and building something using a language's
| standard library.
|
| Everything is just bits at the end of the day. Just about
| anything can do anything.
| mapcars wrote:
| I do programming interviews and I found candidates struggling
| a lot in doing http request and parsing response json in Go
| while in Python its a breeze, what makes it particularly
| hard, is it lack of generics or dict data type?
| conor- wrote:
| I think it depends on what kind of data you're dealing
| with. If you know the shape of your data, it's pretty
| trivial to create a struct with json tags and
| serialize/deserialize into that struct. But if you're
| dealing with data of an unknown shape it can be tricky to
| work with that. In Python because of dynamic typing and
| dicts it's a little easier to deserialize arbitrary data.
|
| Go's net/http is also slightly lower level. You have to
| concern yourself directly with some of the plumbing and
| complexity of making an http request and how to handle
| failures that can occur. Whereas in Python you can use the
| requests lib and fire off a request and a lot of that extra
| plumbing just happens for free and you don't have to deal
| with any of the extra complexity if you don't want to.
|
| I find Go to be bad for interviewing in a lot of cases
| because you get bogged down with minutiae instead of
| working directly towards solving the exact problem
| presented in the interview. But that minutiae is also what
| makes Go nice to work with on real projects because you're
| often forced into writing safer code
| badrequest wrote:
| I think other languages cause folks to understand JSON
| responses as a big bag of keys and values, which have many
| convenient ways of being represented in those languages.
| When you get to Go and you want to parse a JSON response,
| it has to be a well-defined thing that you understand ahead
| of time, but I also think you adapt when doing this more
| than once in Go.
| ljm wrote:
| If I had one complaint, it's the use of 'tags' to
| configure how json is handled on a struct, such that it
| basically becomes part of the struct's type. It can lead
| to a fair bit of duplication of structs whose only
| difference is the json handling, or otherwise a lot of
| boilerplate code with custom marshal/unmarshal methods.
| In some cases the advice is even to do parse the json
| into a map, do the conversion, and then serialise it
| again!
|
| The case I ran into is where one API returned camelCase
| json but we wanted snake_case instead. Had to basically
| create another struct type with different json tags,
| rather than having something like decoders and encoders
| that can configure the output.
|
| I like Go and a lot of the decisions it makes, but it has
| its fair share of pain points because of early decisions
| made in its design that results in repetitive and overly
| imperative code, and while that does help create code
| that is clear and comprehensible (mostly), it can
| distract attention away from the intended behaviour of
| the code.
| cpuguy83 wrote:
| You could wrap it in another struct and use a custom
| MarshalJSON implementation.
| duskwuff wrote:
| As an aside, you may be interested in some of the ongoing
| work to improve the Go JSON serializer/deserializer:
|
| https://pkg.go.dev/github.com/go-json-experiment/json
| kloop wrote:
| var res map[string]any err :=
| json.Unmarshal(&res)
| jay_kyburz wrote:
| Hold on, did you just say Go doesn't have a Dictionary data
| type?
|
| I'm a Javascript, Lua, Python, and C# guy and Dict is my
| whole world.
| bitwize wrote:
| Go has had a dict-like data type from the jump; they're
| called "maps" in Go.
|
| Some of early Go's design decisions were kinda stupid,
| but they didn't screw that one up.
| AmpsterMan wrote:
| It does. https://go.dev/blog/maps
|
| What the poster was alluding to is that you usually
| prefer to deseialize to a struct rather than a
| record/dict/map
| zhengyi13 wrote:
| Not a programmer, so this is every programmer's chance to
| hammer me on correctness.
|
| No, Go doesn't have a type named Dict, or Hash (my Perl
| is leaking), or whatever.
|
| It _does_ have a map type[1], where you can define your
| keys as one type, and your values of another type, and
| that pretty closely approximates Dicts in other
| languages, I think.
|
| [1]: https://go.dev/blog/maps
| duskwuff wrote:
| And, if you hate strong typing, there's always
| map[string]any.
| dwattttt wrote:
| Really, the mismatch is at the JSON side; arbitrary JSON
| is the opposite of strongly typed. How a language lets
| you handle the (easily fallible) process of "JSON ->
| arbitrarily typed -> the actual type you wanted" is what
| matters.
| absoflutely wrote:
| Go has maps, json parsing and http built in. I'm not
| exactly sure what this person is referring to. Perhaps
| they are mostly interviewing beginners?
| randmeerkat wrote:
| > I do programming interviews and I found candidates
| struggling a lot in doing http request and parsing response
| json in Go while in Python its a breeze, what makes it
| particularly hard, is it lack of generics or dict data
| type?
|
| Have you considered that your interview process is actually
| the problem? Focus on the candidate's projects, or their
| past work experience, rather than forcing them to jump
| through arbitrary leet code challenges.
| travisd wrote:
| Making an HTTP request and dealing with JSON data is a
| weed-out question at best. Not sure if you are
| interpreting the grandparent comment as actually having
| them write a JSON parser, but I don't think that's what
| they meant.
| nrr wrote:
| It comes down to how the standard library makes you do
| things. I don't think there's any reason why a more
| stringly-typed way of handling JSON (or, indeed, a more
| high-level way of using HTTP) is outside of the realm of
| possibility for Go. It's just that the standard library
| authors saw fit not to pursue that avenue.
|
| This variability is honestly one of the reasons why I
| dislike interviews that require me to synthesize solutions
| to toy problems in a very tightly constrained window of
| time, particularly if the recruiter makes me commit at the
| outset to one language over another as part of the overall
| interview process. It's frustrating for me, and, having
| been on the other side, it's noisy for the interviewer.
|
| (In fact, my favorite interview loop of all time required
| that I dig into a diabolical system that was crashing with
| gdb, along with some serious code spelunking. The rationale
| was that, if I'm good with a debugger and adept at reading
| the source that's in front of me, the final third of
| synthesizing code solutions to problems and conforming to
| institutional practice can be dealt with once I'm in the
| door.)
| randomdata wrote:
| _> it 's pretty difficult to over engineer_
|
| I don't know about that. Every programmer's first Go program
| seems to like to go to channel city. Perhaps more accurately:
| Over-engineering your Go program is going to quickly lead to
| pain. It doesn't have the escape hatches that help you paper
| over bad design decisions like some other languages do.
| nasretdinov wrote:
| Yeah too much concurrency and too many channels definitely
| hit home hard...
| arp242 wrote:
| Also: interfaceiritus. Someone saw "accept interfaces,
| return structs" somewhere and now EVERYTHING accepts an
| interface, whether or makes sense or not. Many (sometimes
| even all) of these interfaces have just one implementation.
| hellcow wrote:
| Doing this allows you to mock out that implementation in
| unit tests.
| neonsunset wrote:
| Can't Go compiler statically prove that such single
| implementation interfaces are indeed that and
| devirtualize the callsites referring to them?
|
| Either way, the problem seems to happen in most languages
| of today, if they (or their community) ever happen to
| accidentally encourage passing an opaque type abstraction
| over a concrete one.
| pjmlp wrote:
| Sure, if everything one does is either CLI stuff, or UNIX
| daemons, containers, ....
|
| Because in the reign of graphics , GUI, GPGPU, HPC, HFT, ML,
| game engines,numeric analysis, ... there is hardly any
| library that really stands out.
| dartos wrote:
| Or servers, and about anything that really benefits from
| concurrency.
|
| Even a lot of games could be made with go. The gc wouldn't
| really kill the frame rate of a game unless you really push
| it.
| jayd16 wrote:
| I'm asking this earnestly but is Go suitable for native GUI
| apps (not web)? 3D graphics/Games? Audio processing?
| nasretdinov wrote:
| For games potentially Ebiten, I believe it has some audio
| processing support too.
| runeblaze wrote:
| Probably not Ebiten for 3d games. To be fair at this point
| when you are doing somewhat specialist things Go starts to
| lose its edge. I remember trying to replicate some Numpy
| code in Go and that was a pain. However that's just because
| Python is too good at scientific things.
| xyproto wrote:
| Yes, because one can either turn off the GC, allocate memory
| up front (arena style), or call C or Assembly from Go.
|
| The performance is likely to be good enough with GC turned
| on, though, because it is unusually fast.
| jayd16 wrote:
| Turning off the GC isn't the blocker. Plenty of GC
| languages manage.
|
| I'm more interested in how Go handles graphics APIs and
| binding a render thread or working with GUI threads
| considering how goroutines are done. Does one need to write
| non-idiomatic go, avoiding goroutines or is there some
| trick?
|
| For example, GTK isn't thread safe so you can't just use
| that library without considering that.
| 0cf8612b2e1e wrote:
| People write games and GUI apps in Python, so why not?
| jayd16 wrote:
| Is there some particular reason Python is similar to go
| with regards to GUIs or are you saying everything can do
| everything?
| 0cf8612b2e1e wrote:
| Python is a slow interpreted language (I write Python
| every day). Go is compiled and an order of magnitude
| faster for most everything.
|
| My prior is that compiled languages can always perform
| better than dynamic.
| api wrote:
| Go has very little story when it comes to desktop or mobile GUI
| apps, which is too bad because it would be a very productive
| language for that kind of thing.
| actionfromafar wrote:
| My personal Python threshold is 10k lines. After that I tend to
| loose track of what I am doing and I start to miss static
| typing and nowadays, an IDE to navigate it. Maybe future Python
| IDEs can AI scan the codebase and compensate.
| acyou wrote:
| Go is not a single tool. It's a vast set of tools. Using mostly
| Go is kind of like using mostly Milwaukee power tools. Then, when
| you need a tape measure or a level or a tool bag, if you're
| reasonable you can use another brand, where it makes sense.
|
| You still should always try to use the right tool for the job.
| Doesn't mean it has to be the absolute best tool or such a thing
| exists, the best tools are often the ones you have ready at hand
| and know or can learn how to use.
| Cthulhu_ wrote:
| While this is true, especially in larger corporate settings
| there needs to be some pushback if someone tries to introduce a
| new tool, because a new tool or language means you need to
| include it in hiring and training.
| omeid2 wrote:
| At the peak of my honeymoon phase with Golang, I went down this
| path too, and oh boy does it feels great and liberating, like
| finding a magic bullet, but soon as you start to scratch beyond
| the surface and dig deeper, you will find yourself trying to
| screw screws with a hammer, or tie your shoes with a chainsaw and
| ungodly things like that.
|
| No tool deserves more love or loyalty than the productivity it
| brings, anything more is infatuation and a game for naive and the
| fool.
| markusw wrote:
| It's not really about Go, I think. But it makes me productive,
| and I like that. I don't think it's a magic bullet at all. Lots
| of things annoy me about it. But it's _good enough_ for quite a
| lot of things IMO.
|
| But tying shoes with a chainsaw does sound kinda fun. :D
| omeid2 wrote:
| I completely understand, but the productivity is superficial
| in my opinion, once you need to dig your teeth deeper into
| anything not "cloud" and "system engineering" with Go,
| overall productivity plummets hard.
|
| This is from some 10 years of Go experience. But like you
| say, it is not really about Go; my point is about the
| illusion of productivity that familiarity brings; it is very
| deceptive and hurts productivity in the long term.
| markusw wrote:
| I don't understand. How can it be an illusion of
| productivity when it actually produces something that's
| very easy to see?
| randomdata wrote:
| He is saying what is very easy to see in certain contexts
| is not transferrable to the abstract. Go can be
| shockingly productive at certain tasks, but it also falls
| flat on its face at others. If you take your limited
| experience with Go (or whatever; this applies to all
| tools) where you found it to be highly productive and
| then conclude that it is always productive and therefore
| a tool you can use in all situations, you are bound to
| encounter negative productivity when you have a different
| problem to solve.
|
| Need to write, say, a network service? Go can no doubt
| give just about anything else a productivity run for
| their money. Need to solve a machine learning problem?
| ... Good luck. It _can_ be done, of course, but you 're
| quite likely in for a whole lot of extra work not needed
| in other ecosystems, destroying any semblance of
| productivity.
|
| In other words, the comment is a thinly veiled "use the
| right tool for the job".
| steve_adams_86 wrote:
| If someone can't tie their shoes with a chainsaw, they just
| haven't dedicated appropriate time to their tools :)
|
| Side note, this reminds me of a local YouTuber who mostly
| films himself using a chainsaw and has a remarkably large
| following (516k followers right now!). He also loves axes. I
| present to you Buckin' Billy Ray:
| https://www.youtube.com/@BuckinBillyRaySmith
|
| I'm pretty sure this guy ties his shoes with a chain saw
| markusw wrote:
| Haha, sweet. :D
| fifilura wrote:
| Where I feel go is lacking is for data wrangling.
|
| Group by, filter, map, join. It is just very error prone,
| inconvenient and slow to implement with for loops.
| Cthulhu_ wrote:
| Go does support functional programming constructs (as it has
| first-class functions) and there are some FP libraries out
| there, but they are discouraged because the execution is so
| much slower; Go is not optimized for FP, and chooses "clumsy"
| for loops over clever functional programming because the loops
| have mechanical sympathy and are simply faster in execution
| speed.
|
| That said, if you have a use case with a lot of data wrangling
| like that, Go may not be the best choice and a functional
| programming language may be a better fit.
| zarzavat wrote:
| Perhaps I'm thick but what kind of programming _doesn't_
| involve data wrangling?
|
| What are Go programmers doing that they don't feel the need
| for map/filter/etc?
|
| BTW there's no reason why map and filter would be slower than
| loops, efficiently lowering such functions to loops was
| solved a very long time ago.
| neonsunset wrote:
| > Go is not optimized for FP, and chooses "clumsy" for loops
| over clever functional programming because the loops have
| mechanical sympathy and are simply faster in execution speed.
|
| So are iterators in Rust which allow you to write idiomatic
| iterator experessions. Hell, even LINQ in C# has improved
| dramatically and now makes sense in general purpose code
| where you would have erred on the side of caution previously.
| You can pry 'var arr = nums.Select(int.Parse).ToArray();'
| from my cold dead hands.
|
| At the end of the day, it is about having capable compiler
| that can deal with the kind of complexity compiling iterator
| expressions optimally brings.
| erik_seaberg wrote:
| Mechanical sympathy now favors SIMD instructions and
| hyperthreads because sequential loops are slower even
| unrolled.
| jimbokun wrote:
| With generics you can now write all of those in Go.
| curious_cat_163 wrote:
| I grew up writing C/C++ and I could write this same blog post but
| about Python for the same reasons that the author cites :-)
|
| Sometimes I wonder if I am just being lazy and justifying not
| learning new stuff but then I look at the new stuff that keeps
| landing in the Python ecosystem and conclude otherwise.
| andrew_eu wrote:
| I can't really disagree with the points the article makes in
| favor of Go, and it's not selling it over some other
| language/framework/tool but just celebrating how great of an
| ecosystem Go has. And it's true -- Go's ecosystem has matured
| into something very pleasant to work with.
|
| By the same token I know professors who still write their
| simulation scripts in QBASIC because that's what they are
| familiar with and they can solve their problems quickly. You can
| use all sorts of tools to drive a nail.
|
| On Go, it's almost a footnote in the context of the post, but I
| think a seriously underrated feature is its C-interoperability.
| Here [0] is an example. It's not unique of course -- tons of
| languages have some FFI solution for C libraries -- but Go's is I
| believe one of the most straightforward to use if you're already
| familiar with the language. And while there are
| portability/stability sacrifices you make when you call a native
| library, it does also expand the available dependencies even
| beyond "basically infinite."
|
| [0] https://go.dev/blog/cgo
| markusw wrote:
| You're totally right about CGo. For example, I'm very happy
| that I can use the insanely well-tested original SQLite C
| library directly in Go, and sleep easy that it's not some half-
| ported pure Go library.
|
| (I know there's an auto-transpiled SQLite lib as well, which is
| probably just as good. But then I have to rely on no bugs in
| the transpilation process, and I don't like that. That may be
| superstition though. ;) )
| ljm wrote:
| You might like Zig too. The C interop is amazing. Last time I
| checked you could use Zig to just compile C straight up.
| metaltyphoon wrote:
| Go has one of the worst FFI support IMO. Code as comments? It
| doesn't ever support C callback without a "bridge" method. MSVC
| support? Try debugging when CGO is enabled. Worst of it all,
| it's also one of the slowest too.
| BrandoElFollito wrote:
| I like that.
|
| I have a similar attitude with Python and Go as back hammers and
| Quasar (Typescript + Vue + Vite + components) as the front
| hammer.
|
| Whenever there is a date in Python I exclusively use Arrow (even
| for the simplest, most basic ones).
|
| I know it is not effecive, but I am an amateur dev and having
| these hard rules keeps me from testing something new all the
| time.
|
| I leave this for home automation and docker services where my
| motto is "fix it until you break it"
| deergomoo wrote:
| There are a lot of aspects of Go that I'm really not a fan of,
| but I've been writing an increasing amount of it over the last
| few months and on the whole I'm finding it really enjoyable--even
| though I'm not sure I could empirically explain why.
|
| The tooling is _heaven_ compared to other stuff we do a lot of at
| work (TS /JS of course being the main offender), and generally I
| find I spend less time thinking about things that aren't directly
| related to the problem I'm trying to solve. Though, that might
| just be because I'm not an expert and simply don't yet know about
| other things I could be thinking about!
| znkr wrote:
| I have been writing Go code for many years, the fact that I
| don't need to think about things unrelated to the problem I am
| trying to solve is why I love Go. I definitely learned a lot
| about Go and I am thinking more about certain aspects than
| before, but usually only in the context of API design.
| bborud wrote:
| People always under-estimate the cost of properly learning a
| language. At any given time I tend to have a "main go-to
| language". I typically spend 2-4 years getting to the point where
| I can say I "know" a language. Then I try to stick to it long
| enough for the investment to pay off. Usually 8-10 years.
|
| A surprising number of people think this is a very long time. It
| isn't. This is typically the time it takes to understand enough
| of the language, the compiler, the runtime, the standard library,
| and idiomatic ways to do things. It is the time it takes to where
| you can start to meaningfully contribute to evolving how the
| language is used and meaningfully coach architects, programmers
| and system designers. It is also what you need to absorb novices
| into the organization and train them fast.
| cube2222 wrote:
| Agreed. Having a passing knowledge of many languages is of
| course easy (even being moderately productive with them, esp.
| with Copilot now), but knowing the ins and outs of a language
| and its ecosystem is a very nontrivial time investment.
|
| Thus, I'm mostly an anti-fan of the idea of polyglot
| environments.
| oooyay wrote:
| By now I _know_ three major languages: Go, Python, and
| Typescript. I know tradeoffs at-a-glance, I deeply understand
| the syntax and its various forms, the full array of tooling and
| what they do, and lastly (but maybe most importantly) I can
| estimate more accurately because I can architect in my head.
|
| I _can work_ in a myriad of other languages. I may be able to
| do some of the things above in Java or Rust but not nearly to
| the degree to which I can in languages I _know_. I think the
| difference is I 'm probably not going to be _leading_ a Java
| project or producing anything really innovative at a code
| level.
|
| To me, more important than picking _a hammer_ , is knowing a
| variety of hammers that are good at certain tasks. I don't
| focus on Rust or Java as much because, frankly, I can build
| most things that are pertinent to the constraints of my work
| environment with those tools and most people I encounter also
| know them. The other considerable factor I have is that most
| things I work on can be horizontally scaled so my need for Rust
| is very niche. With respect to Java, I have a lot of
| workarounds that are cleanly abstracted enough before I need
| its dynamism and subsequent mental overhead.
| Klonoar wrote:
| It's not just the time to understand those nuances, but to keep
| up with the pace of changes. There's an aspect of navigating
| those in some languages (JS...) that can be time consuming
| depending on where it's deployed.
| pjmlp wrote:
| Naturally one can't know all the languages of the world.
|
| Even so, I have done consulting since 1999, with a small 2
| years pause in research, and have several languages that I keep
| switching, every couple of months when project reassignment
| takes place.
|
| The usual T-shape kind of consultant, know some stuff really
| well, and others good enough to deliver.
| BiteCode_dev wrote:
| And then you have the ever changing ecosystem, that can take
| years so sort out on it's own and must be constantly studied.
|
| E.G: if you arrive in Python right now, numpy is in version 2
| and polars is stable. uv is all the rage, pydantic gained so
| much perf it's not even funny, toml is part of the stdlib and
| textual is looking very good. Type hints are much better than 2
| years ago, htmx is used a lot in the web department, fasthtml
| is having a moment in the light and pyscript got a platform. Is
| any of those information worth acting on? Should you ignore
| them all for the sake of productivity? Should you carefully
| evaluate each proposition?
|
| Now if you have to do that with rust and erlang as well, it's a
| lot of time you could spend on coding instead.
| nemo1618 wrote:
| One of the most important qualities of Go is that it is
| actually possible to _fully_ understand the language -- in the
| sense that you _never_ see a snippet of Go code and think
| "wtf, you can do that?" or "hang on, why does that work?"
|
| Getting to that point takes many years, to be sure. But the
| language is simple enough, and changes slowly enough, that it
| is not an unrealistic goal -- the way it would be in C++, or
| Rust, or just about any other mainstream language.
| igtztorrero wrote:
| I love Golang, I used for backend, have some GUI apps but I think
| GUI packages and frameworks for Go are still immature, none of
| them convince me.
|
| I would like a tool in go, that could handle nice GUI, compiled
| for WASM and run in the browser. Any ideas?
|
| I will follow you @markuwsw.
| ManBeardPc wrote:
| Go is my favorite general-purpose tool (combination of language +
| standard library + 3rd party libraries + tooling +
| documentation). Everything just works out of the box and is
| simple to use and understand. No collection of dozens of external
| tools with fiddly configuration, a simple command to compile and
| simple deployment via a single executable with no additional
| setup required. No other language gives me such a simple and
| hassle-free all-around experience.
|
| I certainly think other languages (Java, C#, Rust, JS/TS) have a
| lot of advantages over Go in some areas, but everything I've
| worked with so far has some other aspects that I absolutely hate.
|
| POV from a (mainly) B2B fullstack SE
| lairv wrote:
| Go is everything I don't want in a language for my personal
| projects. It's verbose, every simple task feels like a lot to
| write. It's not expressive, what would be a one-liner in Python
| makes you write three for loops in Go. I constantly need to find
| workarounds for the lack of proper enums, lack of sum types, no
| null safety etc.
|
| I'm sure these are the exact reasons why Go is good for
| enterprise software, but for personal projects, I get no fun out
| of using it
| Spartan-S63 wrote:
| I agree with this take. I find Rust a more exciting language
| from a personal project perspective--and it's what I go with
| even when it doesn't make 100% sense.
|
| Go is fine, though, and works well in a team environment. It's
| just clunky, but clunky in a productive way.
| stuff4ben wrote:
| Damn, everything new really is old again. Everyone said the
| same thing about Java. Yet it still works and gets the job
| done. Go does as well. I'd rather poke my eyes out with a nail
| than use Python.
| the_gipsy wrote:
| Do you write Go for fun as hobby, or do you agree with the
| OP?
| matwood wrote:
| > I'd rather poke my eyes out with a nail than use Python.
|
| Glad I'm not the only one. Every time I'm forced to use
| Python I cringe. What version disaster and I'm going to run
| into today? The 2->3 transition happened a long time ago at
| this point and I still run into lingering effects. Also, for
| short 'script' like things Python doesn't feel any quicker or
| easier to write. Go is my Goto (hehe) for short scripts.
|
| And while I'm ranting, I'll also say that modern/latest
| version Java is also really nice.
| maccard wrote:
| I would rather go had real enums, and I would _prefer_ if there
| were sum types.
|
| I agree it's more verbose, but I don't find that that verbosity
| really bothers me most of the time. Is res=
| [x for x in foo if "banned" in x]
|
| really actually more readable than var result
| []string for _, x := range foo { if
| strings.Contains(x, "banned") { result =
| append(result, x) } }
|
| ? I know it's 6 lines vs 1, but in practice I look at that and
| it's just as readable.
|
| I think go's attitude here (for the most part) of "there's
| likely only one dumb, obvious way to do this" is a benefit, and
| it makes me think more about the higher level rather than
| what's the most go-esque way to do this.
| aaomidi wrote:
| The new lines were eaten so it does make the python version
| more readable but I agree with you.
| maccard wrote:
| Thanks - updated!
| randomdata wrote:
| Go has real enums. All an enum does is count.
|
| You're probably thinking of value constraints? Or, perhaps,
| exhaustive case analysis? Go certainly lacks those future.
|
| And, indeed, they sound like nice features, but, to be fair,
| not well supported in any popular programming language. At
| best we get some half-assery. Which always questions if the
| popular languages are popular _because_ of their lacking type
| systems?
| maccard wrote:
| This topic has been beaten to death, and being pedantic
| about the definition of an enum to say "actually go has
| them" isn't helpful. There are dozens of articles from the
| last decade which explain the problems. Those problems
| don't exist in plenty of programming languages.
|
| No language is perfect, but go's particular set of bugbears
| is a good tradeoff
| randomdata wrote:
| _> being pedantic about the definition of an enum to say
| "actually go has them" isn't helpful._
|
| Incorrect. The term "real enums", where used to imply
| that enums are something other than the basic element of
| the same name, encompasses a number of distinct features
| that are completely independent of each other. In order
| to meaningfully talk about "real enums", we need to break
| it down into the individual parts.
|
| If you're just trolling in bad faith, sure, leave it at
| "real enums" to prevent any discussion from taking place,
| but the rules of the site make it pretty clear that is
| not the intent of Hacker News.
|
| _> Those problems don 't exist in plenty of programming
| languages._
|
| Plenty, but none popular. Of the popular programming
| languages, Typescript seems to try the hardest, but even
| then just barely shows some semblance of supporting those
| features - still only providing support in some very
| narrow cases. The problems these features intend to solve
| are still very much present in general.
| IshKebab wrote:
| Dude. Everyone knew what "real enums" meant _including
| you_. Please stop.
|
| And yes popular languages do have real type safe enums.
| C++, Typescript, Rust, god even Python.
| arp242 wrote:
| Words can have more than one meaning. As far as I know,
| no one voted you to be arbiter of all terms and their
| _One True Correct(tm)_ meaning. It 's pretty clear what
| the previous poster intended to say.
| thornewolf wrote:
| I argue:
|
| - The list comprehension is ever slightly more readable.
| (Small Positive)
|
| - It is a bit faster to write the code for the Python
| variant. (Small Positive)
|
| So this would be a small positive when using Python.
|
| Furthermore, I believe there is this "small positive" trade-
| off on nearly every aspect of Python, when compared to Go. It
| makes me wonder why someone might prefer Go to Python in
| almost any context.
|
| Some common critiques of Python might be:
|
| - Performance in number crunching
|
| - Performance in concurrency
|
| - Development issues in managing a large code base
|
| I believe the ecosystem is sufficiently developed that
| Numpy/Numba JIT can address nearly all number crunching
| performance, Uvicorn w/ workers addresses concurrency in a
| web serving context, ThreadPool/ProcessPool addresses
| concurrency elsewhere, and type hints are 90% of what you
| need for type safety. So where does the perceived legitimacy
| of these critiques come from? I don't know.
| maccard wrote:
| > The list comprehension is ever slightly more readable.
|
| I disagree - it's terse to the point of being hard to
| parse, particularly when you get smart ones like:
| [x for x in t if x not in s]
|
| > It is a bit faster to write the code for the Python
| variant.
|
| Code should be written to be read. Saving a few keystrokes
| vs time spent figuring out the `not in in not with` dance
| gives the the edge to Golang here. It's "high context"
|
| > - Performance in number crunching > - Performance in
| concurrency
|
| And "performance in all other areas". See the thread last
| week about massive speedups in function calls in python
| where it was still 5-10x slower than go.
|
| > So where does the perceived legitimacy of these critiques
| come from? I don't know.
|
| It's pretty hard to discuss it when you've declared that
| performance isn't a problem and that type annotations solve
| the scalability of development problem.
| laserlight wrote:
| Luckily, we are writing Python, not Go, so we can use
| variable names with more than one letter:
| [word for word in sentence if word not in bannedWords]
|
| Suddenly, nothing is hard to parse.
| bb88 wrote:
| I do think people should tend to be more verbose with
| variable names, in general.
|
| And since it's python, use snake case to add faux white
| space to help the eyes parse the statement.
| neonsunset wrote:
| Rust: let results = foo
| .into_iter() .filter(|s| s.contains("banned"))
| .collect::<Vec<&str>>();
|
| C#: var results = foo
| .Where(s => s.Contains("banned")) .ToArray();
|
| Convenient, easy to understand _and_ fast.
| maccard wrote:
| I think Rusts terseness shows here - I think C#'s
| approach is the best. Also, if you don't use
| `.ToArray()`, you still have an IEnumerable which is very
| usable.
| halfcat wrote:
| _"Is <python code> really actually more readable than <go
| code>?"_
|
| I mean, I mostly work in Python, but, yes absolutely.
|
| There's something to be said for locality of behavior. If I
| can see 6x as many lines at once that's worth a lot in my
| experience.
|
| This becomes blatantly apparent in other languages where we
| need 10 files open just to understand the code path of some
| inheritance hierarchy. And it's not nearly that extreme in
| go, but the principle is the same.
|
| But there is something to be said for the one way to do it,
| and not overthinking it.
| skitter wrote:
| I agree that list comprehensions aren't any easier to read. A
| proper streaming interface on the other hand lets you easily
| follow how the data is transformed: foo
| .stream() .filter(x -> x.contains("banned"))
| .collect(Collectors.toList());
|
| As an aside, Go conflating lists and views irks me, in part
| due to what weird semantics it gives to append (e.g. if you
| have two disjunct slices and append an element to one slice,
| that might modify the other slice).
| kjksf wrote:
| So you're ok with Python, which doesn't have sum types or null
| safety, 2 out of 3 things you say are missing in Go.
|
| In fact, Python didn't have any compile-type type until
| recently and compared to Go is slow and bloated.
|
| So maybe the issue is not Go's lacking some features but
| something entirely different.
| lairv wrote:
| class A: def __init__(): pass def f(self): pass
|
| def g(a: A | None): a.f()
|
| (edit: I don't know how to format code on HN)
|
| If I activate type-checking in VS Code this will highlight an
| error, although the python interpreter will indeed try to run
| it without compile time error
|
| As I said, for my side projects this is enough for me to
| model my problems properly without having to resort to
| multiple hacks
|
| And I took Python as an example, I also enjoy using Ocaml and
| Rust
| steveklabnik wrote:
| > I don't know how to format code on HN
|
| two spaces: https://news.ycombinator.com/formatdoc
| mapcars wrote:
| Mypy supports those for like 3-4 years already
| RandomThoughts3 wrote:
| That's why I love Go so much.
|
| You want to write a very clever library using elegant
| abstraction and generics to have a cool innovative interface to
| solve your problem? Tough luck, you can't. So instead, you will
| just have to write a bog standard implementation with for-loops
| and good old functions which you will have to copy and tweak as
| needed where you really need something more complicated. It
| will work perfectly fine and end up being very readable for you
| and for the other persons reading your code.
|
| Go is basically anti-Haskell. It forces you to be less clever
| and that's great.
| GaryNumanVevo wrote:
| Take a look at a JSON parser or ORM written in Go. It's god
| awful the things they have to do to work around Go's type
| system. The average developer won't see these things, they're
| typically just writing glue code between Go's great stdlib
| (which also contains wild things if you take a look) and
| other 3rd party dependencies.
| lpapez wrote:
| > The average developer won't see these things, they're
| typically just writing glue code between Go's great stdlib
| (which also contains wild things if you take a look) and
| other 3rd party dependencies.
|
| This is what most of us are doing every day, and exactly
| what Go excels at.
| kamov wrote:
| Sum types allow for more robust modeling of the API
| boundary in libraries, so in fact having a better type
| system is desirable even when "just gluing libraries",
| because it can make incorrect program states physically
| unrepresentable.
| anonzzzies wrote:
| I find Go akin to C ; it's really fast to pick up, I can use it
| without internet if I have to, it has enough functionality and
| enough stable libraries for me not really to have to bother with
| the latest and the greatest of everything like in the javascript
| world.
|
| I use it when I cannot use CL (for basically everything) or
| Racket (language / code generation), which basically means 'if my
| clients doesn't accept the above'.
|
| For web/desktop/backend CL and Go are both incredibly productive.
| CL for me is more productive, mostly because the effortless
| starting, far more expressive (do a lot with very little code),
| better repl, debugging, save and die etc. Single binaries are
| great about both and so is lightning fast compilation.
|
| I guess I have two hammers; one of them has a more comfortable
| handle for whacking in those slightly more difficult nails.
|
| Lately I cheat by using a subset of CL and generating the Go
| code.
| cybrexalpha wrote:
| I've been coding in Go for over five years. I _like_ Go, but I
| don 't _love_ it. It 's never my first choice, although I don't
| advocate for rewrites just to move away from it.
|
| The tooling is a mess. Go modules still feel like a 'first pass'
| implementation that never got finished. There's no consistency in
| formatting or imports (even though Go claims there is). Generics
| are a good step but are still very primitive (no generics on
| interfaces, no types as a first-class object).
|
| It still feels very unfinished as an ecosystem. I hope it'll get
| better as the Go team mature things, like iterating on generics.
| But I can't see Go modules continuing without a fundamental
| rewrite.
| acedTrex wrote:
| What do you mean by no consistency in formatting? go fmt is a
| solid formatter that does its job
| cybrexalpha wrote:
| Go fmt is pretty good, but it's not ideal. My biggest gripe
| is imports. Go fmt will just sort imports alphabetically in
| lists that aren't separated by a blank line. Goimports will
| separate out core from 3rd party imports, unless you run it
| with the local flag then it'll add a third block of "local"
| imports.
|
| But this spread means that it's not consistent across
| projects which style is preferred.
|
| Some examples, based on cursory looking at big Go codebases:
| - Kubernetes, one of the biggest public-facing Go projects,
| uses the 3-block style https://github.com/kubernetes/kubernet
| es/blob/master/pkg/con... - TIDB uses 2-block style https://g
| ithub.com/pingcap/tidb/blob/master/pkg/ddl/placemen... -
| MinIO uses 2-block https://github.com/minio/minio/blob/master
| /internal/grid/con...
|
| In all of those cases if you make a change and just run 'go
| fmt' it very well could inject any new imports in the first
| block, which would be wrong and you wouldn't know until
| project CI picks it up.
| jerf wrote:
| Not sure what you mean by "no generics on interfaces"?
| https://go.dev/play/p/jGINeUt1JTE
|
| Also echoing not sure what you mean by "no consistency in
| formatting or imports". It is increasingly difficult to use Go
| without gofmt getting run, since I have to imagine fewer and
| fewer people nowadays are using an editor that has neither
| custom support for their language nor LSP integration, and
| integration with gopls automatically runs goimports on save.
| cybrexalpha wrote:
| > Not sure what you mean by "no generics on interfaces"?
|
| I didn't word this very well. You can have a generic
| interface, and functions on that interface can refer to
| generic types. But you can't have a generic method on an
| interface that uses a different generic type. For example you
| can't have:
|
| ``` type YieldThing[T any] interface { Yield() T
| DoOperation[U any](U) } ```
| jerf wrote:
| I figured based on your comment you meant something by it.
|
| In which case I'd point out that it goes beyond interfaces
| and Go just doesn't permit that in general, for those who
| are playing along. All generics are always fully
| instantiated. You can have a type
| Holder[T any, U any] struct { Val1 T
| Val2 U }
|
| but you can never have anything like a variable of type
| Holder[int], with a type-currying effect or something where
| the U bit is still unbound, or a bare variable of type
| "Holder" without any further parameters. All types within
| the language are always fully instantiated after compile.
| cybrexalpha wrote:
| Yeah I get it. I've found workarounds in the past. But
| it's always involved some friction.
|
| In general, Go's generics are a huge step forward though.
| So I'm not that annoyed about it.
| foldr wrote:
| There are good reasons for not allowing generic methods:
|
| https://go.googlesource.com/proposal/+/refs/heads/master/de
| s...
| Nijikokun wrote:
| Realistically the reasons are this:
|
| > So while parameterized methods seem clearly useful at
| first glance, we would have to decide what they mean and
| how to implement that.
|
| They just didn't want to decide what they mean or how to
| implement them.
| foldr wrote:
| Right, but that's because it is not obvious what they
| should mean or how to implement them. In particular, it
| seems that intolerable complications to the linker would
| be required. Contrast that with, say, a proposal to add a
| more concise syntax to Go for anonymous functions.
| Everyone can see exactly what that would mean and how it
| would be implemented.
|
| I'm not saying that Go should never add generic methods
| to the language. But it's at least reasonable to hold off
| from doing so until these issues are clarified.
|
| There is a concise explanation of the central problem in
| a comment in the issue thread:
|
| > The crux of the problem is that with a parametric
| method, the generated code for the body depends on the
| type-parameter (e.g. addition on integers requires
| different CPU instructions than addition of floating
| point numbers). So for a generic method call to succeed,
| you either need to know all combinations of type-
| arguments when compiling the body (so that you can
| generate all bodies in advance), or you need to know all
| possible concrete types that a dynamic call could get
| dispatched to, when compiling the call (so you can
| generate the bodies on demand). The example from the
| design doc breaks that: The method call is via an
| interface, so it can dispatch to many concrete types and
| the concrete type is passed as an interface, so the
| compiler doesn't know the call sites.
|
| Rust allows generic methods on traits but doesn't allow
| these traits to be instantiated as trait objects. Perhaps
| Go could do something similar. https://docs.rs/erased-
| generic-trait/latest/erased_generic_t.... But it's far
| from obvious to me that this would be a good idea for Go,
| and I'm glad the Go team haven't rushed into anything
| here.
| icholy wrote:
| Not sure what you're comparing to, but Go modules are probably
| the best dependency management system in any language.
| cybrexalpha wrote:
| It does a lot well. For example it correctly pins
| dependencies by hash in go.sum. It's by no means the worst
| dependency management system I've ever used.
|
| IMO the biggest miss with Go modules is conflating the
| identity of a dependency with how you get it. This means that
| renaming a repo not only breaks the module itself (as you
| self-import other modules in the same source tree using the
| full path), but all of your dependencies. I've seen repos be
| renamed from github.com/foo/proj to github.com/bar/proj as
| part of organisational reshuffles, and then there's a big
| warning somewhere that says "never make a github.com/foo/proj
| repo or it'll break GitHub's automatic forwarding for renamed
| repos, and you'll break every package that depends on us."
|
| There are workarounds like using replace directives. But that
| makes an even worse situation where you can read a source
| file and assume a dependency is at github.com/foo/proj but
| actually it's elsewhere. But ultimately a real fix involves
| touching every single file that imports your dependency. If
| Go modules left the way of pulling a dependency in go.mod
| alone it wouldn't.
|
| You _should_ use a Go modules proxy to solve this, and a
| custom import path. But by the time most orgs realise they
| need this it 's too late and adopting one would be a huge
| change. So you end up with a patchwork of import issues.
| icholy wrote:
| > But ultimately a real fix involves touching every single
| file that imports your dependency.
|
| Why is that a problem?
| stuff4ben wrote:
| Java was my hammer back in the day. In a few more years, I'm
| banking on it being my post-retirement "daddy needs a new boat"
| solution.
| jillesvangurp wrote:
| I understand the sentiment. My goto hammer is Kotlin, which I
| like a bit better than Go. But that's a highly subjective thing
| of course. And I use plenty of other languages as well (including
| very occasionally some Go).
|
| It's not about what is better in general but about what is better
| for you. Better here means less time wasted with figuring out
| syntax, tools, APIs, frameworks, etc. Once you know how to do a
| certain thing in one language, having to relearn to do the same
| things in another is slightly annoying. Although, LLMs are
| actually hugely helpful for this these days.
|
| IMHO we're about to see a minor renaissance in web development. I
| was playing with the Kotlin WASM compiler a few weeks ago just to
| verify that I could use existing web APIs. As it turns out, it's
| are all there. Using them might not be the fastest right now but
| I'm sure that will get improved over time. Garbage collection is
| already in (and coming soon to Safari as well). There are some
| inefficiencies with making calls into js that need some
| attention. But that's not really a show stopper unless you are
| doing this many times per second.
|
| What that means is that you can just do web application in wasm;
| use all the stuff from the browser that you normally use but
| without any javascript (except for a tiny wrapper that loads the
| wasm). I actually use kotlin-js so it's not a big leap for me.
| But wasm loads a bit faster and probably compiles a bit faster
| too. No more webpack uglification needed (which is actually
| slower than the kotlin compiler). So that's 2x compiler
| performance right there.
|
| The point here is not kotlin or javascript but that this now
| works with any language that you can get going with wasm.
| Including Go if you want. Javascript becomes completely optional.
| I'm sure some will be upset about that. But that would be mainly
| because it's their preferred hammer.
| markusw wrote:
| Yeah, WASM is interesting! I haven't followed the space at all,
| but I guess the browser is the new JVM? :D
| ridiculous_leke wrote:
| I am planning a switch to Kotlin just because it seems more
| readable. As someone who has done both how do you rate Kotlin's
| STL?
| hintymad wrote:
| > So, what, I'm going to limit my career options?
|
| I don't quite get this sentiment. In my experience, the career
| opportunities come from solving worthy problems, as opposed to
| using a particular language. Plus, I don't believe that an
| engineer should be identified by a language, as in a Go
| programmer, or a Java programmer.
| markusw wrote:
| But often, a client needs a developer for an existing stack,
| and advertising as a Go programmer (for example) gives you an
| edge over someone who doesn't, in my experience.
| bitbasher wrote:
| Life is barely long enough to get good at one thing so you should
| choose your thing wisely. That's wisdom I've held for quite some
| time.
|
| Coincidentally, I chose Go as my language of choice as well. The
| factors that led me to that choice were many, but to highlight
| some:
|
| - incredible standard library
|
| - simple to read and write
|
| - single static binary builds (assets included, like html/images,
| etc)
|
| - don't need a container (my binary is the container)
|
| - can be used anywhere (webdev, desktop apps, gamedev, embedded,
| etc)
| jayd16 wrote:
| What game engines use Go?
| sedatk wrote:
| I chose C# for the same reasons. It's probably easier to make
| C# unreadable than Go due to plethora of features, but it all
| comes down to how you discipline yourself about writing code.
| mats852 wrote:
| https://github.com/bflattened/bflat
| bb88 wrote:
| I appreciate the Rust approach where Rust <-> C and Rust <->
| Python get along really well together. They really thought
| about interoperability with existing infrastructure.
|
| Java wanted everyone to rewrite everything in Java because that
| was easier than to interface with the existing libraries on the
| OS.
| textlapse wrote:
| Heard from someone: "C++ is a hammer, but then everything starts
| to look like your finger"
| blt wrote:
| I really like most aspects of Go, but as someone who writes a lot
| of numerical code, no operator overloading is a deal breaker.
| It's so hard to accept something like Add(Scale(s1, vec1),
| Scale(s2, vec2)) over s1 * vec1 + s2 * vec2. So I stick with
| Python and C++ for now.
|
| Rust is really appealing as a C++ replacement, but it has too
| many rules to replace Python for one-off scripts. Still need to
| try Nim and Swift, I guess...
| gcau wrote:
| Is this something Go intentionally didn't add?
| sbhitz wrote:
| https://go.dev/doc/faq#overloading
| jagged-chisel wrote:
| Yes. Because "things are simpler without it." Presumably
| "simpler" from the point of view of the language implementer
| as opposed to the user of the language.
| abtinf wrote:
| Operator overloading essentially makes code unreadable
| without deep diving past the interface boundary.
|
| In Go, you can generally look at any snippet of code and know
| _precisely_ what it does.
| hello_computer wrote:
| Something like Elixir's function composition operator (->)
| would go a long way toward smoothing that out, but they
| rejected that as well.
|
| I think the best we can do at the moment is runtime expression
| evaluation with something like this:
|
| https://github.com/expr-lang/expr
|
| or this: https://github.com/Knetic/govaluate
| dudeinjapan wrote:
| Elixir's function composition operator is |>
| SatvikBeri wrote:
| We switched from Python to Julia for numeric code. It's
| generally much faster (and easier to optimize), and has
| slightly better syntax for mathy code.
|
| It's worth noting that Julia is very similar to go, despite
| superficial differences. They're both small languages with big
| libraries, use the same concurrency model, use a mark-and-sweep
| GC with an emphasis on making it easy for the programmer to
| reduce garbage/allocations, and both use structs + functions
| rather than classes.
| dilyevsky wrote:
| Numerical programs seems like a great fit for DSLs, say
| Starlark[0] ;-) That's what many C++ libs basically achieve
| with their heavy use of overloading, tmp, etc
|
| [0] - https://github.com/google/starlark-go or alternatively
| https://github.com/facebook/starlark-rust
| amedvednikov wrote:
| Go with operator overloading: https://vlang.io
|
| Compiles to C.
| IshKebab wrote:
| Gotta admire the craziness of sticking with a language and
| apparently even building a community of fans even after such
| an insanely panned debut. I wonder if this will be the No
| Man's Sky of languages. Does it actually work yet?
| azangru wrote:
| > Go is my hammer, and everything is a nail
|
| > Less context switching
|
| For the very same reason, my hammer is javascript.
| beepbooptheory wrote:
| I know its great and powerful but Go was always the "Google
| language" to me and as an unsufferable hipster that just turned
| me off to ever touch it.
|
| I want all the things I spend my years studying to be built by
| committee or otherwise brief specimens of creative genius.
| Anything else makes me feel like I'm just learning Marvel lore.
| jmull wrote:
| > But why? When the common wisdom is to always take the problem
| at hand, analyze it, and then choose the tools, why would I
| ignore that and go
|
| Sounds like they _are_ choosing the right tool for the job.
|
| When considering languages, familiarity is a significant aspect.
| And, the smaller the duration/size of the project, the more
| significant it is. A decent analysis wouldn't ignore this.
|
| If the language you're most productive with is appropriate for a
| project (and go is appropriate for a wide variety of things), you
| need a good reason _not_ to use it.
| adrianlmm wrote:
| Does go even have a Generic list (ArratList in Java)?
| w10-1 wrote:
| Granting the indie-dev, limited resources, focus-is-good, to me
| the key is enablement by available libraries, platforms, IDE's,
| language survival and importance, etc. -- none of which the
| author mentions.
|
| Java for the most part has libraries and IDE's due to its
| history, but got tripped up on the essential web platform story:
| it's only achingly small/fast enough for real servers, and just
| flat out gave up on the browser after the javascript onslaught.
| For future-proofing, anti-Oracle bias has hamstrung Java of late
| (notwithstanding the excellent upgrades and engineering Oracle
| put in).
|
| Go is great if you're on the server side with Google-like
| concerns, and it's unlikely Google would ever drop Go.
|
| With Rust, the language offers the most for serious systems
| programming, but the learning curve limits available libraries
| (converse being true in javascript land). Rust is still early-
| adopters - likely the best talent-wise, but not scaling.
|
| Swift is interesting. Can be as easy as Java, but is becoming as
| correct as Rust wrt lifetimes and more deployable than Go, to
| both server and embedded. But no real incentive from Apple for
| deploying on Windows or to the web, so that's handled by a few
| heroes. And unfortunately, libraries are sort of an open-source
| zoo of minor offerings. But Apple's betting the company on Swift,
| so you can, too.
|
| Python pretty much lucked into popularity by supporting the
| scientific computing that would become data analysis and AI after
| building significant community inertia. It's sort of the default
| prototyping language in a time when prototypes are often good
| enough. It's gradually been adding typing and performance to stay
| good enough.
|
| So Python would be my recommendation as the one language to rule
| them all for indie developers, who are more likely to be plumbing
| together applications than writing database engines. It's also
| where the money is now for most developers.
|
| That said, it may depend most on the market for skills. It might
| be easier to build an indie business as a Go developer because
| the supply/demand curve favors you. And as far as I know, there's
| no good data on point for that.
| insane_dreamer wrote:
| I would argue that a language's ecosystem matters much more than
| the language itself. This is why Java is still so popular, and
| why certain languages are better suited to certain tasks than
| others. For example, if you're doing numeric or scientific
| related development, it's hard to beat Python even if Go itself
| is better, because of the great set of robust libraries you get
| for free. (Yes, Go has some equivalent, but not as tried and true
| as numpy, scipy etc.)
| riiii wrote:
| Go is nice but people either love or hate the error handling.
|
| There have been some good proposals but because people are so
| passionate about all their requirements and edge cases, that I
| don't think it'll ever get improved.
___________________________________________________________________
(page generated 2024-08-12 23:00 UTC)