[HN Gopher] Learn Go in five minutes
___________________________________________________________________
Learn Go in five minutes
Author : tate
Score : 178 points
Date : 2021-01-05 16:06 UTC (6 hours ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| eecks wrote:
| I'm a fast reader so I learnt Go in 4 mins. Who's hiring?
| ike77 wrote:
| According to Firefox reader view it should take 11-14min to read
| it
| kissgyorgy wrote:
| Don't trust a tutorial which intend to tech you the basics of Go,
| but forget to include the most important idea: interfaces...
| postalrat wrote:
| Where are channels?
| codenlearn wrote:
| Absolutely no offense to the author, but IMO for an experienced
| programmer the five minute intro does not make any sense. They
| will be better served by using the documentation (or) go by
| example in this case.
|
| If someone is new to programming this in no way does any justice.
| Programming is way too complex to be fit in 5 minutes intro.
| https://norvig.com/21-days.html
| ducktective wrote:
| Is this a response to that "learn rust in half an hour?" ;)
|
| https://fasterthanli.me/articles/a-half-hour-to-learn-rust
| goodoldneon wrote:
| Someone make "Learn Haskell in 50 seconds"
| jerf wrote:
| [Ancient Aliens Guy Picture Here]
| FUNCTIONS
|
| I've gotten it down to about two seconds here....
| ducktective wrote:
| https://imgflip.com/i/4snpcr
| bla3 wrote:
| It says so in the first line of the article, so probably yes.
| st1x7 wrote:
| If only we had known that all of these Rust vs Go arguments
| could be resolved by learning both languages in 35 minutes.
| bkovacev wrote:
| Is there something like this for Golang API development, that
| also incorporates best practices? Even a solid book
| recommendation would be helpful.
| cfors wrote:
| The repository and structure is free here, but I highly
| recommend the actual course for API development, which is not
| free but very valuable.
|
| https://github.com/ardanlabs/service
| [deleted]
| cfors wrote:
| This is neat, and a testament to the simplicity of Go.
|
| I normally point people to this tutorial if they want to learn Go
| quickly, it is interactive (able to navigate straight to go
| playground) and very well done in my opinion.
|
| https://gobyexample.com/
| mynameisash wrote:
| > the simplicity of Go
|
| As someone who's not written any Go, I found fasterthanlime's
| critique of the language[0] damning enough that I likely won't
| ever touch the thing. Maybe he's cherry-picked examples, but
| his article was thorough and technical enough to convince me
| that the Go mantra of simplicity is just surface-level.
|
| [0] https://fasterthanli.me/articles/i-want-off-mr-golangs-
| wild-...
| bird_monster wrote:
| It sounds like you've made up your mind, but I might suggest
| reading less overwhelmingly biased critiques. That post makes
| incorrect assumptions about go, and then exhibits the result
| of their incorrect assumptions, and then brings up how, when
| making the correct assumptions in Rust, the outcome is
| different. Can you see how this is a flawed strategy?
|
| Go isn't for everyone, and that's okay, but it seems kind of
| silly to make a judgement based off of a negative review
| hinging on a pretty poor understanding of a language.
| jrockway wrote:
| How is this damning, exactly? It's a very specific set of
| library quirks that are kind of expected -- Chmod doesn't do
| much on Windows. Arguably, maybe Chmod shouldn't be in the
| core library if it can't do everything on every
| OS/architecture combination, but I am not sure that damns the
| language. It does the best it can, but doesn't deliver a
| POSIX overlay for Windows. (The complaint continues into a
| discussion of build tags, to make Windows-only code compile
| only on Windows. Again, what's the alternative here? If you
| want your program to do different stuff depending on the
| platform, there's going to be some sort of conditional to
| apply that.)
|
| There is then a discussion about monotonic time. The author
| immediately knows they want monotonic time, but there is no
| method that specifically returns that. Instead, go embeds the
| wall clock and monotonic time into a time.Time when you
| create one with time.Now. It uses the wall clock time for
| display, and monotonic time to compute the difference between
| two timestamps. This is not what the author expected, but it
| ultimately allows them to do what they want. (There is then a
| complaint about how when you boot a Raspberry Pi without
| giving userspace any time to start up, the time is set
| incorrectly, and Go doesn't help. Well... yeah. You can add a
| hardware RTC if you want the time to be correct as soon as
| the i2c subsystem comes up, or you can wait for NTP, or you
| can live with the wrong time. Not sure how any of this
| involves Go -- it does expect the OS to do OS things for it.)
|
| If you were going to write a damning critique of why to never
| use Go, it would probably be something like "this dumb
| library uses channels, sync.Mutex, and atomic.AddInt64 all in
| the same code and it deadlocks and runs out of memory" or "I
| installed the most popular ORM on Github and it prints
| colored text to the console when there is a database error
| rather than returning an error from the function". I think
| the linked article totally misses the mark on what problems
| people are likely to encounter with Go. Let's be honest --
| 99% of programmers have no idea that their OS has a monotonic
| clock, and are quite surprised (and have no idea how to fix
| it) when start := time.Now(); time.Sleep(time.Second);
| fmt.Println(time.Since(start)) prints a negative number.
| But... with Go they don't have that problem. Pretty
| interesting.
| jrockway wrote:
| I guess I ignored the section on resolving the long
| dependency graph, and that's important to discuss. The
| community could do a better job of splitting their clients
| and servers into separate modules (writing to InfluxDB
| should not require downloading the code for an InfluxDB
| server). (I do love using servers written in Go, though,
| because my integration tests can just start one up at the
| beginning of the test and talk to it. No setup/teardown
| required outside of "go test"; no extra dependencies to
| make developers install. It's nice!)
|
| The language could do a better job of letting you choose
| "plugins" at runtime; if you use Prometheus for monitoring
| and not InfluxDB, it's not ideal to have a bunch of 'if
| UseInfluxDB { send to InfluxDB }' compiled into your
| binary. The alternative is to dlopen something that
| provides monitoring functionality; been there done that
| with Nginx and OpenTracing, and it's hugely painful. (There
| simply aren't binaries that work together; you can't wget a
| prebuilt plugin into your Nginx docker image. You have to
| build both from scratch.) Or, you can at least defer the
| monitoring library selection from library to application
| with an abstraction layer like OpenTelemetry. The cost to
| the code author is high, and it still doesn't let the
| operator choose the backend at runtime. Overall, this is
| something that a programming language should choose to take
| on, but it's also exceedingly difficult to get right. I
| haven't seen it done right, anyway; so all you have to go
| on is a list of ways to get it wrong.
|
| It is annoying that there are 600 different logging
| libraries. But people are VERY particular about logs, and
| one person's treasure is another person's "that is so
| horrible I can't even use it". If there is a programming
| language where everyone uses the same logging library and
| that library provides structured logging, the log levels
| are [trace, debug, info, warning, error, fatal], has built-
| in support for sending to third-party services (Sentry),
| rate-based sampling, and metrics generation... then that
| sounds great to me and I'll definitely take a look. But for
| some reason, I kind of doubt it. People have a lot of
| thoughts here, and are very committed to their thoughts. In
| the Go world, libraries with wonderful authors let you
| inject your own logger, and it mostly works well. GRPC,
| pgx, Jaeger, etc. all do a good job here. K8s's client_go
| does a bad job here, but they're working on fixing it :)
|
| Wasn't planning to get sucked into this discussion, but the
| article does raise some good points. I'll be very honest
| and say rants like this sound to me like a pre-rant for
| next year when it's "why I quit programming forever and
| became a beet farmer". To succeed at programming, you will
| have to endure in the face of minor problems with your
| tools. You will have to use those tools to program better
| tools, after all. And even then, it still won't be perfect,
| and you'll see a new set of problems to be mildly annoyed
| at. Such is life! Ultimately, for me, Go has supported my
| efforts to make stuff. I run it on STM32 microcontrollers.
| I run it on Beaglebones. I ran it on thousands of servers
| at Google. It just kind of gets out of the way and lets you
| turn your ideas into things that you can use. Who can
| complain.
| sundarurfriend wrote:
| Thanks for sharing this. I'm halfway through it, and it is
| indeed damning, if only mildly so (compared to, say,
| phpsadness). As the author says, the specifics are not the
| point, rather the overall picture they build: that simplicity
| in language design has its own price, and sometimes all it
| means is that the underlying complexity is passed on to you
| to handle in your program yourself; and the damning part is,
| Go does not seem to do a good job of making that process as
| smooth and clear as it could.
| capableweb wrote:
| > testament to the simplicity of Go
|
| Depends on who reads it I guess. Lispers would not see
| simplicity in Go, they would see all the different characters
| you need to use, how some things are statements and others are
| function calls, conditionals, type definitions and they all
| have different syntax for themselves, instead of being the
| same.
|
| Both have their places for sure, but I wouldn't go so far to
| say Golang is simple because of this example.
|
| At least it's not Rust, I give you that. pub
| fn metadata<P: AsRef<Path>>(path: P) -> Result<Metadata>
| [deleted]
| aabhay wrote:
| All of the details but with none of the heart. I would much
| prefer a 'wow' example utilizing concurrency than a primer on how
| to write a function
| Elgolfin wrote:
| My 2 cents without seeming harsh with the author.
|
| Articles with a title `Learn <programming language> in 5 minutes`
| are misleading. They should be renamed `Discover <programming
| language> in 5 minutes`. Replace the verb Discover by Introduce
| or something similar if you like.
|
| There is a lot of difference between learning a new programming
| language and discovering one.
|
| You will not learn any programming language in 5 minutes.
|
| This introduction to Go is quite nice, though.
| harrisonjackson wrote:
| Way less clicks for "Discover" than "Learn"
|
| My expectations were low enough because of the "5 minutes"
| part, and I actually found it to be better than expected.
| capableweb wrote:
| > There is a lot of difference between learning a new
| programming language and discovering one.
|
| Yeah, discover just lasts the moment you stumble upon it. Once
| you sit down to _learn_ the syntax and basics, you 're
| _learning_ the language.
|
| - _discover_ - find unexpectedly or during a search.
|
| - _learn_ - gain or acquire knowledge of or skill in
| (something) by study, experience, or being taught.
|
| I don't think anyone is reading the title and thinking "Huh, I
| can learn _all_ of Go in just 5 minutes?!". The time is an
| indicator that you'll just scratch the surface, not become a
| master gopher.
| falcolas wrote:
| Remember when we used to yell at 21 day books (Learn C++ in 21
| Days) as being mis-leadingly short? It's becoming a meme now.
| unethical_ban wrote:
| It glosses over a lot of nuance, which I can tell by not
| explaining that you can't use the implicit assignment := operator
| outside a function.
|
| And since this has turned into another "referendum on golang"
| argument, I'll say that I appreciate what it has to offer on my
| team at work. We historically write in Python, and we are a team
| of system engineers writing 100-500 line automation code that
| uses APIs.
|
| Static typing helps. Our enterprise has tooling that makes
| importing 3rd party code a lot easier in our bureaucracy. The
| linting and checks are more robust.
|
| From a language perspective, forcing linting and conventions
| makes the code a lot easier to write with a team. I may not like
| camelCase, but damnit if everyone doesn't learn how to read it
| quickly when the language/linter forces us to use it.
|
| The VSCode plugin is completely essential. Being able to type an
| import, and then quickly hop to the complete API documentation
| and expected inputs/outputs of everything, is so much help that
| I, a Python "skilled tradesman", gladly hopped on the golang
| train.
|
| My only gripe is that a lot of documentation seems to be third
| party, or very strictly an API reference. Nuanced, helpful docs
| are scattered in gobyexample, stackoverflow, etc.
|
| ---
|
| Bottom line, it is a great language/ecosystem for reasonably
| self-documenting, readable code for novice/intermediate
| "scripters" and coders who are not CS majors. Tooling is amazing.
| alexellisuk wrote:
| The only thing this missed, and sorely missed was unit testing.
| Disclaimer: I wrote this post a few years ago and it still seems
| to help folks, although I'm sure if I wrote it again it may look
| different. https://blog.alexellis.io/golang-writing-unit-tests/
| cweill wrote:
| You can save yourself a minute and generate the test case
| boilerplate for your with https://github.com/cweill/gotests :)
| jug wrote:
| This looks like it was written with the intent to "win" the
| simplicity battle in mind. Nothing on interfaces or goroutines.
| 37ef_ced3 wrote:
| Go can be understood as an improved C that keeps much of C's
| simplicity but adds small, powerful features like interfaces and
| channels and garbage collection
|
| Go fixes C's well-understood flaws (declaration resembling use,
| unintuitive operator precedence, unrestricted address math,
| silent casting, zero-terminated strings, etc.)
|
| Go puts essential C idioms directly into the language
| (pointer/length is formalized as slices, packages are part of the
| language instead of just being naming convention, etc.)
|
| Go is mature, stable, widely-used, well-supported, and well-
| understood. C++ is a clumsy mess, but C is quite elegant and Go
| is a continuation/modernization/enhancement of that
|
| If you like C, you will love Go
| alpaca128 wrote:
| I'm not a C fan but isn't Zig much closer to C's philosophy
| while fixing bad parts than Go? Especially due to the garbage
| collection, at which point Go suddenly competes with many more
| simple languages.
| jerf wrote:
| It depends on your definition of "C's philosophy", no
| sarcasm, and no implied preference by me for any particular
| definition, as I believe many have merit. Language
| philosophies evolve, and C, being so many decades old, has
| evolved a lot. The original philosophy is probably little
| more than a seed crystal at this point for the several
| philosophies that have been loaded on to it over the years.
|
| It is probably reasonable to say that Zig is closer to C's
| current philosophy in practice, which encompasses many
| additional developments over the decades to deal with various
| aspects of C and programming real machines that have arisen
| as both have changes, and Go closer to C's original
| philosophy of simplicity and relative ease of use. (In modern
| times, C is not one of the easier languages to use any more,
| due to significant advancements in the field of making easy-
| to-use languages. But it was originally intended to be an
| advancement there itself.)
|
| By similar logic, I can say with a straight face that all of
| Go, C++, Zig, Rust, and Swift (and more) are "evolutions in
| general-purpose programming languages like C", despite their
| wild differences, because the world has gotten larger, and
| there is room for a lot of variations like that, each
| addressing different aspects of the newer, larger world.
| burnthrow wrote:
| I thought this sounded familiar
|
| https://news.ycombinator.com/item?id=25622389
|
| https://news.ycombinator.com/item?id=25555457
|
| https://news.ycombinator.com/item?id=25531118
| booleandilemma wrote:
| So the account was created 34 days ago and he's posted that
| same message 4 times already.
| Jnr wrote:
| If I would have to replace C with anything, I would choose Rust
| and not Go.
| simias wrote:
| To me Rust is more like "C++ done right". It's massively
| bigger, more complicated and slower to compile than C. The C
| ABI is also the de-facto lingua franca for language interop,
| something that's not easily achievable with Rust or C++ (or
| Go, for that matter).
| Jnr wrote:
| Have you tried Rust?
|
| The ABI in Rust is doable:
| https://people.gnome.org/~federico/blog/rust-stable-
| abi.html
|
| And it doesn't feel like C++ when writing it. The syntax
| and language features are nice and feel modern.
|
| It does require more attention because of what it compiles
| down to, but the compiler is there to help with it.
|
| I haven't been excited about any programming languages in
| years, but Rust has certainly taken my attention lately.
| simias wrote:
| I love Rust so dearly that I wish I could marry it, but I
| still feel that it's a massively more complicated
| language than C.
| kevbin wrote:
| > If you like C, you will love Go
|
| That may be true. But if you _love_ C you're going to hate Go
| like you've never hated any thing ever before.
| [deleted]
| cute_boi wrote:
| I like C but I would prefer Rust over Go. Go may be simple but
| I really hate using conventions like init(), comments working
| like syntax, captial letter means published etc.
| corytheboyd wrote:
| Doesn't Rust have "comments working like syntax" in the form
| of #[derive] etc.?
|
| I've only read through the rust book without using it for
| anything (yet) and have done no work on golang, so I'm
| legitimately curious to hear your input, not challenging you
| on semantics :p
|
| Edit: Rust does not use # for comments. Sorry I just had that
| mixed up in my head, but thanks for the answers!
| brundolf wrote:
| #[...] is an attribute, more like @foo annotations in Java,
| not a comment. Comments do not use # in Rust
| corytheboyd wrote:
| > Comments do not use # in Rust
|
| Oof what a dumb mistake, sorry about that!
| felipellrocha wrote:
| It's ok. Other people probably had the same question!
| cesarb wrote:
| These #[...] and #![...] are not comments; they're
| attributes (somewhat similar to Java's @Something
| annotations). Comments in Rust start with // or /<star>
| like in C or C++. There's only the special case that "doc
| comments" (starting with /// or /<star><star> or //! or
| /<star>!) are automatically converted into #[doc="..."] or
| #![doc="..."] attributes.
|
| The difference is that attributes are always meaningful to
| the compiler (and can only be used in specific places);
| other than doc comments (which turn into attributes),
| comments never are meaningful to the compiler.
|
| (edit: HN's comment markup eats the * character, I replaced
| them with <star> above)
| steve_adams_86 wrote:
| Do Go comments work like syntax? Do you mean that they need
| to be formatted a certain way like they're language syntax?
| _ph_ wrote:
| No, Go comments are just comments. They have been used
| though to add meta-information to special tools. So unless
| you use those tools and require to add the specific meta-
| information, you can treat comments as plain comments.
|
| Hiding certain meta-information, like exporting a function
| with a C-compatible signature when building a shared
| library is not a great way of doing things, but on the
| other side, it is a special usage which isn't part of the
| language itself, so not part of its syntax.
| grey-area wrote:
| The Go authors have (ab)used comments to extend the
| language in experimental ways for code generation, build
| pragmas and recently file embedding.
|
| They've done this to avoid breaking the language stability
| guarantee, not sure if there were other reasons. I think
| it's a mistake personally to create this sort of
| metalanguage in comments (now you have two problems!) but
| it's easy to avoid using this most of the time as the uses
| are pretty esoteric.
| skrtskrt wrote:
| File embedding is a common enough use case (HTML
| templates, config files) that it really makes me cringe
| that it's being done with comments.
| grey-area wrote:
| I just keep my templates and config in separate files.
|
| There are good reasons to keep them separate anyway
| (allows config without recompile for example) and for the
| apps I work on distribution isn't a problem. So I haven't
| really had to use comments as code in 7-8 years of go.
| Perhaps it'll become more common with the embed stuff.
| But then I don't use struct tags either so I guess I'd
| prefer Go to be even simpler.
| Thaxll wrote:
| init() is not a convention and it's not used that much. For
| comments I don't understand what you're saying. And for caps
| I think it's better than public / private keyword.
| fwip wrote:
| Certain comments have a special meaning to some tooling. In
| this sense, it's not very different from Javadocs.
|
| For some examples: A comment that appears right before a
| type or function definition is exported as documentation by
| the "go doc" tool.
|
| Another one is build constraints, which appear as a comment
| at the top of the file, like: `// +build linux` to say
| "only include this file if the build target is linux."
|
| Other tools use their own comment format to recognize
| comments meant for them.
| simias wrote:
| My main small day-to-day usability gripes with C are lack of
| type inference, lack of destructors and terrible ergonomics for
| error handling. Go solves two out of three, but it really
| dropped the ball hard on error handling which is very
| disappointing IMO.
|
| Things like generics and garbage collection involve some deep
| tradeoffs, so I get Go's take on them, even if I don't
| necessarily agree with it. On the other hand IMHO Go's crappy
| error handling boilerplate is not something I find acceptable
| in a modern programming language.
| enw wrote:
| How would you design the error handling?
|
| Personally I'm glad Go has stayed out of exceptions (panics
| don't count), at scale it's so much easier to reason about
| flow.
| bmn__ wrote:
| Monadic error handling like in ML work-alikes, Rust etc.
| would be a good start. Adopt:
|
| * https://github.com/rebeccaskinner/gofpher
|
| * https://speakerdeck.com/rebeccaskinner/monadic-error-
| handlin...
|
| I've been talking to the local Go user group. No one even
| knows about that concept. This continues a pattern of
| general ignorance/lack of looking beyond one's horizon I've
| noticed.
| steve_adams_86 wrote:
| The error handling feels deeply wrong to me too. I love the
| explicitness and how hard it is to ignore errors - all
| languages should make it so easy to expect and handle
| potential errors - but other features (or lack thereof) of
| the language make it so you can't handle any of it in concise
| or sane ways. Code is plastered with the same boilerplate,
| everywhere, always. It makes up a significant mount of all Go
| code.
| autarch wrote:
| I agree that the error handling is terrible, but I'm not sure
| how much better it could be without generics.
|
| For me, the gold standard in error handling is Rust, where
| the type system simply does not allow you to ignore errors.
| This means that the existence of error handling is checked at
| compile time. Of course, this doesn't mean your error
| handling is _good_, but I think that's beyond any language
| design to enforce.
|
| But the Rust system is entirely built around a generic Result
| type, where both the non-error result (an int, string,
| struct, etc.) _and_ the error type itself are both generic.
| simias wrote:
| Go uses compiler magic to have effectively generic
| collections, why not hardcode a Result type in the same
| fashion? It's not very elegant, but it's pragmatic and
| error handling is important enough that it may well warrant
| it.
| autarch wrote:
| Yeah, that's a fair point. I imagine this could be better
| than what's there now.
| papaf wrote:
| _the type system simply does not allow you to ignore
| errors_
|
| Which is excellent.
|
| _the gold standard in error handling is Rust_
|
| Really? What library is in fashion this week for handling
| errors? I have so far used vanilla Rust, error-chain and
| Failure.
|
| Seems like there is so much choice to improve the gold
| standard:
|
| https://blog.yoshuawuyts.com/error-handling-
| survey/#librarie...
| dpryden wrote:
| I'd like to chime in and say that I also like C but really
| dislike Go.
|
| C is simple, to what today is nearly an absurd degree, but it
| at least integrates well with an enormous ecosystem of existing
| tooling and libraries. Go, by contrast, feels the need to re-
| invent every possible wheel, often with a seemingly intentional
| effort to be different _just because_.
|
| C ABIs are rock solid on every platform. Any language or
| tooling in the world can load functions from a C library. By
| contrast, try calling Go from another language. You will
| quickly give up and use network protocols or subprocesses
| instead.
|
| The converse is true too: on major platforms, the C library
| defines the operating system more than the kernel does. (I
| mean, in a Unix sytem, the entire libc is documented in the man
| pages. Documentation for writing C is literally built into the
| operating system.) By contrast, Go decides to avoid the
| standard platform ways of calling every operating system
| function, and instead implements syscalls directly into the
| kernel, basically just because Go hates interoperating with
| anything that's not Go.
|
| C is a good language not because it is a good _language_ , but
| because it is a good _ecosystem_. Unix and C are closely
| intertwined. (Even Win32 and C are pretty closely intertwined!)
| I could imagine a Go-based Plan9-like system -- if that
| existed, and had decades of engineering behind it, I could see
| the argument being made that Go 's ecosystem compares to C's.
| But while Go may aspire to that, it isn't anywhere near there
| yet.
|
| And when you start comparing Go with other languages on the
| basis of _language_ features, I think Go fails laughably more
| often than not. (I 'll give you "C++ is a clumsy mess",
| though.) But compare Go with Rust, with C#, with Haskell -- for
| that matter, compare Go with _Java_ and I think Go is a less
| powerful, less _useful_ language to write real code in.
|
| If I want a lightweight, quick-and-dirty program, I'll use
| Python. If I want to write a reusable library that gets plugged
| into other software, I'd go with C (or at least write the
| interop layer in C). If I want a high-performance server, these
| days I would probably go with Rust. If I want a pragmatic,
| well-rounded language to write a large project in, I think C#
| would probably be my first choice.
|
| What space does that leave for Go? Outside of microservices
| (where I contend that Rust is a _much_ better choice, and there
| are lots of other options), Go 's niche seems to be command-
| line tools. I sort of understand that, because Go's static
| linking makes redistributing binaries relatively easy (although
| Go by no means has a monopoly on that). But in the space of
| command-line tools, Go's argument handling is frankly bizarre:
| it looks at decades of precedent about what users expect from
| argument syntax and behavior and decides to throw it all away
| and reinvent the wheel.
|
| I guess that means this comment (rant?) has ended up where it
| started: Go defies convention, basically "just because". By
| contrast, C _defines_ convention. "If you like C, you will
| love Go"? Nope, not at all.
| simpleguitar wrote:
| Disclaimer: I wrote mostly Java for 10 years, and Go for
| about 5.
|
| Go straddles an interesting space. Currently I work on a
| back-end data crunching software, distributed (running on
| hundreds or sometimes thousands of nodes), each node running
| 64 or 128 cores with 128 or 256GB RAM. The problem we solve
| is both IO, CPU, and memory bound. Anyway to look at it, it's
| a hard problem.
|
| The old version of this program was written in C. Then it was
| rewritten in Go.
|
| The people who decided to switch to Go was looking for the
| following features: - Be able to manually lay out memory for
| performance. So not Java. - Mmap binding to file system, for
| performance. - More abstractions than C, for adding software
| features. - Cross platform. The program sometimes runs on
| Android and IOs. - Easy to learn for beginners. It's not
| possible to only hire PhDs or C++ gurus. - Easy to dig down
| into assembly, for performance. - GC doesn't get in the way,
| for performance as well as adding features.
|
| Maybe these days, C# might work? May Rust? But 6-8 years ago,
| Go fit the bill and it worked out very well. And the language
| doesn't feel "limited" in any way. Yeah, I miss generics
| sometimes. Maybe error handling could be better? Sometimes I
| need to work around the GC. But day-to-day, I think I focus
| more on solving actual problems (performance bottlenecks,
| adding features), instead of pondering if I need to create
| another AbstractFactory, or tuning GC knobs, or figuring out
| which pointer type to use.
|
| To me, Go feels very balanced. I can write python or Java
| like code and get decent performance. If I need more
| performance, I can dig down pretty deep make CPU work faster.
| The abstractions are light enough that a new person can
| figure out what's going on and add features, fix bugs, or
| improve performance.
|
| I like Go.
| xscott wrote:
| > Go fixes C's well-understood flaws (declaration resembling
| use
|
| This seems to be a common belief, but since Go kept pointer
| syntax as prefix, you're still stuck needing parens in some
| unfortunate cases:
|
| https://blog.golang.org/declaration-syntax (see the part about
| pointers near the bottom)
|
| As Rob Pike notes in that link, they could've fixed it and
| still had declaration resembling use if they had chosen a
| suffix operator for pointers. He notes that Pascal uses ^, but
| it seems like @ might be a better choice: int
| foo // an integer int foo@ // pointer to
| int int foo[10]@ // 10 pointers int foo@[10]
| // pointer to array int foo()[10]@ // function that
| returns an array of 10 pointers
|
| In my opinion, they _almost_ fixed it and then punted. As such,
| it 's just different, but not really better.
| Lariscus wrote:
| I like C but strongly dislike Go. They share nothing other than
| having a small(ish) feature set.
| BoorishBears wrote:
| I agree.
|
| Go feels like it's aimed at creating applications that run at
| a level above where C traditionally runs while keeping the
| pared down feature set of C, and it just doesn't work well
| imo.
|
| I loved playing with Go, but eventually it feels like you're
| conditioning yourself to be ok with a lot of "bad" code. Tons
| of repetition, tons of boilerplate by other names.
|
| It's like the simplicity gets in the way of itself.
|
| -
|
| My take is, use Go for a bit, take the "less is more"
| mentality with you to a language more suited for real work.
|
| ps: I'm not saying you can't use Go for real work before
| someone flies at me. I'm just saying that Go's strength is
| the mentality people have when using it, as a language it's
| not particularly enabling, and that's by design if
| anything...
| steve_adams_86 wrote:
| I agree about becoming okay with bad code. But I think if
| you understand and embrace that, there's a place for it and
| it can be quite powerful and easy to use at times. It's a
| trade off that makes sense sometimes. I think the problem
| appears when people treat Go like it doesn't have any
| problems. All languages do.
|
| As I've mentioned recently though, I don't think I'd ever
| want to use Go as a forever solution to a complex problem.
| I'm sure some people could do it and do a great job, but
| I'm not one of those people. I need the ability to abstract
| and ensure more safety, or I'll never feel secure with what
| I'm building.
| Thaxll wrote:
| The last couple of years are showing that Go delivers, it's
| pretty easy to find dozen of "real" software written in Go
| that are weidly used.
| BoorishBears wrote:
| Sometimes I don't know why I bother talking about Go.
|
| It's proponents are so quick to go defensive that no one
| is capable of reading any complaint in an even mildly
| charitable light.
|
| I mean I shouldn't literally have to say "I'm not saying
| you can't use Go for real work before someone flies at
| me." When talking about a language as widely used as Go
| right? Like that's common sense!
|
| And yet of course I'm getting replies that do exactly
| that because of how darn defensive people need to be
| about it.
| Thaxll wrote:
| Maybe don't use things like " to a language more suited
| for real work."
| BoorishBears wrote:
| There is a literal full paragraph dedicated to explaining
| it, maybe don't ignore the oodles of context I left to
| avoid exactly what you did.
|
| Saying other languages are more suited to real work
| doesn't mean Go isn't suited at all, it literally means
| other languages are more angled towards the "end product"
| or the "real meat and potatoes" of just making a thing
| work than Go.
|
| It's literally a strength of Go. Go doesn't want to
| include the kitchen sink or even confine you to having a
| kitchen at all and I respect that.
|
| But I'm saying that other languages that include more in
| the way of _affordances_ can help one be more productive,
| and I believe combining a language that includes more,
| with the _mindset_ of not abusing the buffet is a winning
| combination.
|
| Ymmv, I'm not an oracle, I just expect people to read
| things in a _reasonably_ charitable way which usually
| works fine as long as they 're not being defensive.
| blablabla123 wrote:
| > I loved playing with Go, but eventually it feels like
| you're conditioning yourself to be ok with a lot of "bad"
| code. Tons of repetition, tons of boilerplate by other
| names.
|
| Not well or hastily written Go is easily like that. I can
| only guess why you point out the repetition but when you
| look at well written Go code like in the Go std library,
| there isn't much repetition happening and it looks rather
| elegant. At the same time it can be quite some effort to
| create such code and might take several iterations.
| Documentation-wise I like the official documentation, it
| gives a lot of pointers why Go is how it is.
|
| Also obviously it's not for every use-case. Where it works
| really well IMHO is where error handling is a vital part of
| the application. (And of course anything concurrent is
| quite a breeze)
| BoorishBears wrote:
| Not having generics, by definition, invites a lot of
| repetition and boiler plate. I know generics are
| overrated and coming soon, but right off the bat that
| stuck out.
|
| I recall a point where I had written a function that
| needed to return a channel, but of course had to forgo
| types due to the lack of generics.
|
| The end result was having to wrap that channel in another
| channel that added typing at each call site.
|
| I asked around in go circles if that made sense, and
| called out how bad the felt but the answer was "no that's
| great! channels are cheap! the repetition is good because
| it's simple!"
|
| -
|
| The error handling has some sore points to that end too,
| and the implicit shadowing with shorthand assignments on
| one hand makes it easier to deal with multiple errors,
| but on the other hand introduced subtle logic bugs on one
| than more occasion where "err" was silently shadowed,
| which I greatly disliked.
|
| I'm actually suprised Go didn't forgo shadowing for the
| shorthand operator and force people to label their errors
| when dealing with multiple, it seems very "in brand", but
| I guess even Go draws the line somewhere lol
|
| -
|
| Then there's the whole stack trace situation. Which after
| plenty of reading still just wasn't making sense. I mean
| the idea of logging a stack of wrapped messages sounds
| very nice, but man proper stack traces not being _the_
| first class citizen of error handling just did not make
| sense to me in a language I hear referenced for systems
| work so much (and I realize they can be had)
|
| I saw proposals to rework Go's error handling, I don't
| know if any progress has been made to that end, but it's
| another example where simplicity can get in the way of
| itself
|
| -
|
| And I'll balance this all out by saying it was still fun
| to write, I don't want to seem like I'm just shitting on
| Go for existing.
|
| It's just these little warts that I kept getting over
| with just a little bit of "idiomatic Go" which I often
| found was just writing a little bit more code than you're
| used to, started to add up.
|
| And eventually I realized I was creating something that,
| while very easy to reason about, had a lot more to reason
| about than it needed to. That's where I kind of petered
| out in my personal usage.
| blablabla123 wrote:
| It probably doesn't work to convince you, still I see
| that differently ;)
|
| About generics, it depends on the problem at hand. When
| writing a generic Matrix multiplication type that for
| instance should work both on real and complex numbers (or
| more obscure types) generics are a thing. On the other
| hand, when working for instance with
| golang.org/x/net/html, I really appreciate the interface
| definitions and the possibility to do type switches on
| those.
|
| The error handling problem can also be dealt with. I also
| prefer to not shadow variables, IMHO the ideal function
| has all its variables defined already in the signature.
|
| I mean there are stack traces when a panic is called, or
| something that wraps it like a log.Fatalf. I guess the
| idea is the author is giving much more thought to how
| errors are dealt with and how they are printed in a both
| useful (=greppable) and beautiful way. As an end user
| that doesn't want to dive into the code I probably always
| prefer to see a nicely formatted error message (or even a
| gracefully handled error) instead of a 100 line stack
| trace. Probably Go is not just the language spec but also
| how to use it. Therefore saying "Learning Go in 5
| minutes" is probably a bit far-fetched ;-) (Probably for
| any language that would be true...)
| BoorishBears wrote:
| I'm aware of stack traces on panics, but my understanding
| is you only get them if you let them bubble up and kill
| the application (so not really a "first class" option for
| errors in places like web handlers) Has that changed, or
| did I misunderstand?
|
| But I also think the stack trace message example is the
| perfect example of what I mean by "take the Go mentality
| with you"
|
| In a language like Kotlin for example, Go got my in the
| habit of attaching more information to exceptions as they
| bubble up.
|
| I was already generally in the habit of wrapping library
| exceptions, but I started religiously using a Result
| nomad implementation and wrapping errors with additional
| information so that my stack traces looked very "Go-like"
| in terms of human readability, but kept traditional stack
| trace information.
|
| It's small things that I think using Go makes you "re-
| appreciate" in other languages
| bak3y wrote:
| Meanwhile the place I work writes all microservices in go
| and all of my team's (DevOps) tools are also written in
| go...
| BoorishBears wrote:
| I explicitly added the "ps" to avoid the situation where
| all the replies are fairly empty comment saying "Well we
| use it!"
|
| I get that you can use it for real work, I'm not saying
| you can't. I'm saying, even by design to some degree,
| it's not particularly enabling compared to other
| languages.
|
| That's meant to be a strength if anything, but I did not
| find the tradeoff of simplicity was able to overcome the
| additional effort it took to deal with what was missing
|
| There's an implicit ymmv here of course, because I'm not
| saying _no one_ can find Go useful, I can see how in
| certain worlds with certain teams with certain priorities
| it 'd all work out.
|
| It's just not for me.
| murukesh_s wrote:
| I have used Go in production. I found it roughly takes
| 2-3x additional time it takes to develop the same
| functionality in Node.js (with typescript). But it runs
| faster. If you want to write code that is probably not
| going to be thrown away it may be wise to invest the
| additional time in Go. However can't recommend that for
| building experimental code/APIs etc which are time bound
| and may/can get replaced (or split into micro services)
| in future if it becomes massively successful..
| erik_seaberg wrote:
| If I'm willing to take a productivity hit because I can't
| afford the footprint of Scala/Java (or Typescript), I'd
| be thinking Rust. Go seems to fall somewhere in between
| without a clear advantage in either perf or clarity.
| jtdev wrote:
| Any examples of Node being faster to write than Go? Did
| this have anything to do with the plethora of npm
| packages available?
| H1Supreme wrote:
| This is purely anecdotal, and simply suggests you know
| Node.js better than Go.
| AlchemistCamp wrote:
| And that's saying something give that neither Node nor
| TypeScript have ever had productivity as a main selling
| point!
|
| Imagine evaluating the time to market for an experimental
| back-end written in Rails, Laravel, Phoenix, etc vs Go!
| The difference is staggering.
| konart wrote:
| >Rails, Laravel, Phoenix, etc vs Go!
|
| Comparing frameworks and a language, really?
| AlchemistCamp wrote:
| Go can be nice for simple domains where performance is
| very important. In most cases like that, I'd use Rust,
| though.
| skrtskrt wrote:
| I will take sometimes-tedious boilerplate over many-many-
| layered abstractions.
|
| You can write any language any which way, but some
| languages just have a culture of boilerplate vs
| abstractions. The most popular Python and Java libraries
| seem to love endless layers of indirection, and when it
| doesn't fit exactly what you need, you bang your head
| against the wall monkeypatching it to make it work since
| your whole app is already written in X mega library.
|
| Go culture seems to be quite a bit more boilerplate-y and
| uses smaller more composable libraries. It's just
| refreshing.
|
| Really I just need to buckle down on Rust, but I think it's
| a fair bet that teams and shops that bring in a lot of
| young programmers and want to ramp them up fast may cringe
| a bit at the learning curve of Rust.
|
| That's why for now in terms of a bet on employability, I am
| prioritizing experience with Go.
| 37ef_ced3 wrote:
| Take Go's slices, for example
|
| Realize a Go []int ("slice of int") is just a C struct like
| this, passed by value: struct intSlice {
| int* addr; int len; int cap; };
|
| The memory at addr is not owned by the slice. All the slice
| operations are simply notation for manipulating the struct.
| Go's garbage collection makes the whole thing work well
|
| This can be confusing if you're used to C++'s std::vector
| (which owns the memory) or Python's slices. Go's slices are a
| shallow pointer/length system exactly like is used in C all
| the time. For example: void sort(int* addr,
| int len);
|
| becomes func sort(a []int)
|
| A Go slice is just a formalization of C's pointer/length
| idiom, with terse notation for manipulation
| mhh__ wrote:
| Slices should be the absolute bare minimum for a modern
| systems language, it's not really a reason to switch in my
| case
|
| If I want to write flat/simple code I'll just C, Go doesn't
| really offer anything to me because I want to be relatively
| low-level _and_ able to make the compiler save my time.
| nyanpasu64 wrote:
| Go's slices don't act like what I thought were called "non-
| owning references"(Rust's &/&mut [T] or C++'s std::span<T/T
| const>), which reference memory whose lifetime is bounded
| by something else (like a vector or array or shared
| pointer). Instead it's "shared ownership" where memory is
| referenced by one or more slices (and no single owner)
| which can reference and mutate the slice simultaneously,
| and it's freed by the GC sometime after _all_ the slices
| are gone.
|
| This reminds me of Numpy's ndarrays, which act more like
| "owning containers" (which may sometimes share ownership
| and alias) than "non-owning references".
| erik_seaberg wrote:
| Slices are kind of a mess. They should either be
| uniqueness types or passed by reference (the way maps and
| channels are, and NIO buffers from Java). Instead they're
| passed by value so multiple copies exist whose sizes and
| sometimes contents aren't in sync.
| traes wrote:
| I'm not really sure saying that features in Go can be
| modeled in C really suggests that they are similar as
| languages. Syntax is very important.
| jonnycomputer wrote:
| Learn linear algebra ... in just 5mins!
|
| Learn the lambda calculus ... in just 5mins!
|
| Learn how to write a novel ... in just 5mins!
|
| Learn how to be a stand up comedian ... in just 5mins!
|
| Learn kung fu ... in just 5mins!
|
| Learn how to be a world class lover in bed (or out!) ... in just
| 5mins!
|
| Man, that was the best half-hour I've ever spent in my life.
| Sorry, I couldn't fit in Go, though.
| adenadel wrote:
| This seems like a good place to recall Peter Norvig's article
| "Teach Yourself Programming in Ten Years"
|
| https://norvig.com/21-days.html
| brickmort wrote:
| should have opted for the four minute courses ;)
| falcolas wrote:
| Remember "Learn C++ in 21 Days" and the furor around how silly
| it was to try and learn a programming language in less than a
| year?
|
| It's become a meme now.
| ibraheemdev wrote:
| Nice article! I wrote a more comprehensive version a while ago.
| Estimated reading time: 20 minutes [0]
|
| [0]: https://ibraheem.ca/posts/go-in-twenty
| whalesalad wrote:
| No offense to the author here ... but I need to vent some
| personal frustration. Every tutorial goes through these exact
| same motions for learning a new language. It sucks! Programmers
| can figure out what a variable is, or how to use an array or a
| map. Those things really don't change a whole lot between
| languages. What about how to import code from different modules?
| Best practices for organizing code? How your language differs
| from its competitors as far as usage. Testing practices (which
| often influence how your code is written), etc...
|
| Learning Elixir was tough for me until I found Dave Thomas'
| "Elixir for Programmers" where he skipped all of the basic stuff
| that every programmer is assumed to know and went right to what
| makes Elixir unique and how to leverage it correctly.
| (https://codestool.coding-gnome.com/courses/elixir-for-progra...)
|
| I have been hunting for the same thing for the Go language for
| years because frankly I haven't been able to grok the appeal. I
| am hoping to find a 'Go for Programmers' one day. I asked on
| Reddit a while back and was pretty much handed the "what are
| variables" document.
| moksly wrote:
| 99% of the "learn programming language" literature is written
| by people who likely couldn't do your job because they haven't
| ever been programming.
|
| This is why languages need good documentation.
|
| It seems like it's a booming industry though. I mean, there are
| entire sites like udemy where amateurs teach amateurs things
| they'll never use in a real job, and that place, and others
| like it, seems to be doing just fine. Hell, every PACKT book
| ever written was worth more as blank paper.
|
| Why do I care? I'm an external examiner, sometimes I need to
| read some of these god awful books to see what students are
| expected to know. I'm not sure why professors ever stray from
| the true CS classics, but they unfortunately do. Especially at
| the academy level.
| url00 wrote:
| This 100x. If you find it please share with the rest of us!
| nickelcitymario wrote:
| > How your language differs from its competitors as far as
| usage.
|
| Yes! I'm always tempted to ask "How is this different or better
| than XYZ lang?"
|
| I don't have the time/inclination to learn every new fangled
| language that comes by, so it would be nice to have an easy way
| to understand what scenarios any given language is best suited
| for.
|
| For example, every time I read about Go, I'm left wondering:
| How is this better than C or Java? Presumably it's better in
| some ways I'm not perceiving, otherwise why would it be built
| and used?
| dinkleberg wrote:
| That elixir course looks fantastic, thanks for linking it.
| dpc_pw wrote:
| Seconded. Especially for Go, because it's mostly a lowest
| common denominator of language features it's not hard to write
| the code itself. The problem is that the module system is
| different and had plenty of changes along the years, What I
| would really like is an up to date "learn how to handle Go
| project in 30 minutes" tutorial (initialize new project with
| all best practices, add modules, publish, fork&clone&submit&pr
| including 3rd party submodules, test, CI, profile, debug).
| konart wrote:
| >What I would really like is an up to date "learn how to
| handle Go project in 30 minutes"
|
| 1. git init
|
| 2. git remote add %something%
|
| 3. go mod init %name_of_your_module% (where in most common
| case name is your repo address without the https part)
|
| 4. https://github.com/golang-standards/project-layout - this
| repo has the default project structure. Each subfolder has
| README that describes the purpose of the folder
|
| 5. go get -u github.com/gin-gonic/gin to add gin (web lib)
| for your project. Same for any other package. The will be
| added to your go.mod and go.sum files
|
| 5.1 import "github.com/gin-gonic/gin" in your code to use gin
|
| 5.2 package may have more than one major version (tag). If
| you want to use package at latest tag 2 - you add '/v2' when
| you 'go get' the package (i.e. go get -u github.com/gin-
| gonic/gin/v2)
|
| 6. git commit && git push to publish
|
| 7. Not sure what to you mean by 'fork&clone&submit&pr
| including 3rd party submodules'. You may use vendoring but in
| most cases you don't need it as you have your dependencies in
| your go.mod && go.sum files. You may want to read more about
| vendoring and gomodproxy though.
|
| 8. Testing is pretty easy but I guess you want and article
| about best practices? I won't post any link as I find the
| topic as too controversial regardless of the language\stack
|
| 9. CI - not sure that does this have to do with the language
|
| 10. haven't done much profiling or debugging to fill you in.
| hactually wrote:
| Damn.
|
| > https://github.com/golang-standards/project-layout
|
| I was almost with you but please don't share that repo.
| It's a terrible layout and the docs aren't accurate. The
| issues are full of Go community folk saying it's misleading
| and looks official but isn't.
| phernandez wrote:
| I have had this issue with my current golang projects. I
| haven't found any clear standard for project layout. We
| have a bunch of microservices with grpc api endpoints,
| and some which are event driven. Has anyone found a
| better resource? As it is, even our internal projects are
| fairly inconsistent in their project structure, which is
| a bit annoying.
| codenlearn wrote:
| One resource that atleast comes close to what you are talking
| about is the information at go101.org, not sure if you have
| seen this before. Especially the section on Go Type System and
| Concurrent Programming is really very good and they focus on
| how to leverage the feature correctly for the most part.
| Hopefully you like it https://go101.org/article/101.html
| runjake wrote:
| Good stuff. There is another >5 minute tutorial here:
|
| https://learnxinyminutes.com/docs/go/
|
| This website has something similar for nearly every language:
|
| https://learnxinyminutes.com
| adriancooney wrote:
| I love this website! I use it every time I find a new language
| to get a basic understanding of it. It's an incredibly valuable
| resource.
| potta_coffee wrote:
| I think this is pretty good but I think you ought to commit a
| paragraph to pointers as well.
| svnpenn wrote:
| I maintain a bunch of Go examples here, with links to standard
| library as well:
|
| https://89z.github.io/autumn/tags/go
| diehunde wrote:
| Something it's missing in the CS teaching industry is material
| (and probably a method too) for experienced programmers who want
| to learn a new language. It's so hard to find resources to learn
| the spirit and philosophy behind a language and at the same time
| learn the syntax without spending time on basic stuff like
| declaring variables or functions.
| djeiasbsbo wrote:
| I don't think that there is a lack of material, almost every
| new language has an extensive documentation. I did have to
| learn how to read something that takes more than a couple
| days/weekends though, but now I mostly have no problem with
| documentation.
|
| I do still have trouble with standards or other huge documents,
| e.g. the Arm Architecture Manual. The kind of documents that
| are huge, yet assume a lot of previous knowledge so a lot of
| googling has to be done.
___________________________________________________________________
(page generated 2021-01-05 23:02 UTC)