[HN Gopher] Half a million lines of Go
___________________________________________________________________
Half a million lines of Go
Author : nickcw
Score : 120 points
Date : 2021-05-16 13:45 UTC (9 hours ago)
(HTM) web link (blog.khanacademy.org)
(TXT) w3m dump (blog.khanacademy.org)
| ebingdom wrote:
| Why would anyone want to use a programming language that uses
| product types instead of sum types for the return types of
| functions which can return errors? Or why would anyone want to
| use a language that doesn't even let you write a type safe hash
| table? Also, the fact that Go suffers from the billion-dollar
| mistake is downright inexcusable. Go is way too error prone for
| me to sleep comfortably at night, because the lack of a
| reasonable type system is a constant liability.
| hedora wrote:
| I think of Go as a better Python. If those are your two
| choices, Go is the clear winner.
| linkdd wrote:
| How is Go the clear winner?
|
| Python has been around since 1994 (2 years before Java:
| 1996). It's heavily used in Data Science and Science in
| general.
|
| The C API allows you to write code in most compiled language
| (C, C++, Rust, ...) and Python serves as a glue between
| business logics.
|
| Go simply does not serves the same purpose. There is no
| winner/loser here, just different use cases...
| void_mint wrote:
| It would be kind of a fun experiment to require a rough estimate
| of LoC written in a given language be included in feedback about
| that language. These comments are kind of a cesspool of poorly
| written feedback that wraps ambiguous complaints about
| "readability", "maintenance" and even the silly take of "Go is a
| language for engineering managers", whatever that means. I
| suspect most of the negative comments on any language come from
| people that have spent practically no time writing it, and thus
| are inherently uninformed.
|
| Of course, if you hate a language, you're not going to write lots
| of code in it (unless you have to, and then I would expect your
| feedback to be pretty negative but at least informed). Feedback
| from beginners/programmers external to a language is super
| important for the success of that language of course, but lots of
| debates about things like programming language are cluttered with
| feedback that isn't really made in good faith. Someone that
| doesn't like static typing is going to leave feedback about Go
| that may not directly say "I just don't like static typing", but
| ultimately is as simple to reconcile (and thus, should mostly be
| discarded).
| f430 wrote:
| Should I learn Go and if so Why?
|
| I work with python and node.js but should I give Go a chance?
| fouc wrote:
| 500,000 lines but it's "services written in Go", so it's not a
| monolith, which leads to a lot of duplication I'm guessing.
|
| What are the chances if it was a monolith written in Go, it could
| be closer to 300,000 lines instead?
| dangoor wrote:
| I'm not sure what kind of duplication you're thinking of.
|
| _Some_ of the services tax is taken up by our use of Apollo
| Gateway. When the client requests data that comes from multiple
| services, Apollo will actually pull that data together.
|
| Beyond that, the only additional code required due to services
| is that it's more verbose to make a cross-service GraphQL call
| than it is to make a function call into another package.
| Through tooling, we've reduced that verbosity where we could. I
| don't think it's anywhere near 200,000 lines of overhead,
| though.
| kubb wrote:
| Here's a take: Go is a language for engineering managers who
| occasionally contribute a ten liner. You can learn just enough in
| between your many meetings to make a simple change. You can feel
| proud and happy with how easy it was for you to contribute. And
| you can dump the verbose, repetitive drudgery onto the people
| below you in the org chart, it's their job to deal with this
| after all. But in a language that you can easily understand,
| you'll make sure to push for that.
| baby wrote:
| Golang is:
|
| - the language with the best and most complete standard library
|
| - the language that is the easiest to read due to: the lack of
| expressiveness/generics/OOP/etc., the forced convention (by the
| compiler, go build, go mod, etc.), the fact that gofmt can't be
| customized, etc.
|
| - due to this it is the easiest language to maintain or
| contribute to, because you won't spend hours trying to decipher
| what it's doing. You can't be too clever when you write Golang.
| In many languages the complexity is on the reader, but in
| Golang it is much more balanced. People complain about Golang
| being harder to write, but how boy they should really start
| appreciating how easy it is to read.
|
| - and in turn one of the most secure language you can use
| because it's extremely simple to audit and review code in
| Golang. As an ex security-consultant I've reviewed many
| codebases in many different languages and Golang codebases were
| in general the most secure one (albeit nil dereference bugs).
| halfmatthalfcat wrote:
| > the language with the best and most complete standard
| library
|
| How can this be true when language is still adopting[1] table
| stakes collection operators?
|
| > he language that is the easiest to read
|
| Generic programming is now a part of Go[2]
|
| [1] https://github.com/golang/go/issues/45955
|
| [2] https://github.com/golang/go/issues/43651
| baby wrote:
| Tell me one other language, a single one, that has this in
| its standard library:
|
| - hex / base64 / json / xml / etc.
|
| - TLS (1.3) / x509 / aes-gcm / sha-2/sha-3 / X25519 / ECDSA
| / ed25519 / crypto.rand
|
| - http / html templates / json-rpc / etc.
|
| - big integer math
|
| - zip
|
| There's just so much more, and the documentation is top
| notch: https://golang.org/pkg/
|
| Actually, this is just my take on what I end up using, but
| what's your own favorite package in Golang std lib :D?
| morelisp wrote:
| > hex / base64 / json / xml
|
| Literally everyone. Go is not exactly a stand-out XML
| handler either.
|
| > TLS (1.3) / x509 / aes-gcm / sha-2/sha-3 / X25519 /
| ECDSA / ed25519 / crypto.rand
|
| The prevailing idea even within the Go community today is
| that probably too much of that is exposed and instead the
| stdlib should be focusing on higher-level primitives.
|
| > http / html templates / json-rpc
|
| Go's HTTP stack is very good. Most languages do have a
| worse one, though.
|
| The templating language is interesting, I'm glad it's
| there, but I think there will be widespread
| dissatisfaction among developers coming from other
| languages within in the next few years and you'll see it
| languish in favor of a 3rd party library. I would not
| choose a language based on its stdlib templates (and if I
| did I'd choose Perl).
|
| I bet they will come to regret jsonrpc in stdlib.
|
| > big integer math, zip
|
| Table stakes.
| halfmatthalfcat wrote:
| Javascript has all of that minus some of the crypto
| stuff. They introduced BigInt in ES2020. JS has built in
| json, Node has built-in tls/http.
| josephg wrote:
| Javascript has a built in crypto library now too. Mind
| you, Go's standard library is way better designed than
| javascript's. A lot of Javascript's API is an
| inconsistent mess. (Eg btoa, new
| TextDecoder().decode(str), string.length, etc.)
| gallexme wrote:
| Erlang, doesn't has json rpc tho, but a whole cluster
| technology and rpc if u really wanted it
| chrisandchris wrote:
| C# on DotNet will have most of it? Java probably too?
| ziml77 wrote:
| But there's a downside to putting things like that in the
| standard library. Python also went for a "batteries
| included approach" but it hasn't been all sunshine and
| rainbows. There's a reason why the Python standard
| library is known as the place where modules go to die:
| https://leancrew.com/all-this/2012/04/where-modules-go-
| to-di...
| [deleted]
| morelisp wrote:
| I like Go, and it's not _just_ that, but you 're also not
| wrong.
| avl999 wrote:
| It is a language for people who like to get things done and get
| reasonably performant code for free. Relative to folks grinding
| in some of these dynamic languages doing contortions to deal
| with basic things like concurrency, twisting themselves into
| unimaginative ways to get that code coverage bump from 90% to
| 100% (the hardest part) just because their language cannot
| provide a semblance of guarantee that code "works" or has no
| syntax errors unless it is ran, unable to refactor without
| confidence unless the entire team is willing to commit to 100%
| test coverage and even with the test coverage the refactorings
| taking orders of magnitude more time than Go as now you need to
| parse through your test results to see exactly what your simple
| refactoring of changing a method name or moving a method from
| one file to another broke and then fixing it as opposed to the
| superior tooling of Go (or some other similar statically typed
| language) just doing all that for you in the press of a few
| keystrokes. It is also a language for those who like seeing a
| lower memory foot print, a lower cpu foot print, a simpler
| distribution story (literally copying over a binary to the
| target system)
|
| The verbosity of Go (and even Java for that matter) is 100%
| worth it for me for all those reasons. It allows me to iterate
| fast, make changes with confidence and not have to feel guilty
| that my test coverage is only 92% because I am not going
| through the trouble of covering some branches of code that
| returns an error message (that would otherwise require annoying
| effort to trigger in your tests) as the compiler guarantees
| that all those
|
| `return errors.New("some error")`
|
| will execute if the error condition is ever hit in production
| which was not the case when I was working in python unless I
| went through the effort of having my test cover that bit of
| code.
| closeparen wrote:
| After four years using Go all day professionally, I agree
| with all of these pros, and yet, the code volume to impact
| ratio is just _so bad_. Everything is very straightforward
| and understandable, the next step is always clear, I can
| spend an afternoon grinding out those 500 lines without
| thinking too much. But then I look back at what was actually
| accomplished in that time and it feels pathetic.
|
| Go is a language for teams. All the cogs in the machine will
| spin, they will almost never get jammed, but nobody's fingers
| are fast enough to be particularly more productive than
| anyone else. Maybe this is the gray reality of mature
| collaborative software development. But every day I work in
| Go I get this gnawing feeling that software development could
| be so much better, that we could have been done weeks ago.
| throwaway894345 wrote:
| > 500 lines
|
| But line counts are nearly meaningless. Something like a
| quarter or a third of those lines are going to be a single
| closing brace character. So mostly we're saying that Go's
| style involves a lot of beeline characters, but that
| doesn't tell us much about even boilerplate much less
| complexity. And to be quite clear, Go _does_ have more
| boilerplate than many other mainstream languages, but line
| counts are a particularly bad way of measuring it.
| megameter wrote:
| My read on Go versus other options, having used it for a
| year or so and then switching back to other old
| favorites(Python, Haxe, Lua), is that it really doesn't
| want you to redefine the language. Go code is Go everywhere
| and asks you to work with a largely homogenous set of
| concerns everywhere.
|
| That is great if you are building the environment for your
| application, but it's not great if you are building the
| application, because a differentiated app will always
| possess a unique application "vocabulary" - it's a thing
| that gets thought about in terms of a medium that is not
| the host language. Go resists extension, so most teams opt
| for primitivism rather than developing proprietary
| compilation mechanisms to express their spec. Everyone gets
| worried about the risks of generating code and how to
| maintain that: it's a "known" to have a larger fungible
| uniform codebase. The result is that "slow and steady"
| feeling when working with Go to do relatively high-level
| things - it lets you do it, but you have to work hard.
| nicoburns wrote:
| > But every day I work in Go I get this gnawing feeling
| that software development could be so much better, that we
| could have been done weeks ago.
|
| You should definitiely give Rust a try if you haven't. It
| has all the pros above without the boilerplate (and even
| better type safety)
| meinfuhrer wrote:
| Not sure why you suggest Rust as if it's a 1:1
| replacement for Go when it's not in reality except maybe
| for CLIs. Rust also has its own trade offs that may make
| it unsuitable for OP.
| omginternets wrote:
| >But then I look back at what was actually accomplished in
| that time and it feels pathetic.
|
| Surely that must depend on the problem space you're working
| in.
|
| My impression is exactly the opposite of yours, though I
| must confess it took me a bit of time to build up an
| armamentarium of patterns that I could apply to a problem.
| This seems like the flip-side of the "go is a simple
| language" coin.
| morelisp wrote:
| The thing is... that's all the major languages. Even the
| ones that aren't necessarily like that, the culture / style
| ends up like that. The Python I'll write and pass review at
| work is vastly different than the Python I would like to
| write, because I know the next person isn't going to
| understand my brilliant __metaclass__ and nested decorator
| approach that cuts 10k of imperative bullshit down to 20
| lines - or worse they will understand it enough to make a
| change that causes an unacceptable performance degradation
| and not enough to realize that they did it.
|
| There's the famous line from GLS about Java:
|
| > We were not out to win over the Lisp programmers; we were
| after the C++ programmers. We managed to drag a lot of them
| about halfway to Lisp.
|
| And probably there's some equivalent idea about Go not
| trying to win over the Clojure programmers, but rather
| dragging the enterprise Python/Ruby/JS/Java programmers
| halfway to C.
| rlonn wrote:
| >Everything is very straightforward and understandable, the
| next step is always clear, I can spend an afternoon
| grinding out those 500 lines without thinking too much. But
| then I look back at what was actually accomplished in that
| time and it feels pathetic.
|
| I sometimes feel that also, but strongly suspect it is a
| way of thinking that omits very important parts of the
| equation. When you build things, most of the time you're
| not spending writing code, but deciding what code to write.
| That is the work you want to optimize and Go makes that
| simpler, I think, as it is often obvious how something
| should be done in Go. With e.g. Python, there are too many
| options and that, I suspect, actually slows you down. For
| me, using Go feels like steady progress all the time, while
| e.g. JS development involves short bursts of productivity
| followed by long contemplation and sometimes backing out or
| refactoring a lot of stuff. Could of course also indicate
| my JS skills suck I guess ;)
| katbyte wrote:
| Not to mention maintenance - consistent style consistent
| implementation makes digging into 4 year old code from
| some random contributor oh so much easier
| kubb wrote:
| Sounds like you just want a statically typed language,
| because you've been scarred by Python. I'm sorry that you had
| to deal with what sounds like poorly maintained medium or
| large Python code base.
|
| After you get some experience with Go, you might want to
| explore other modern statically typed programming languages
| (I suggest Kotlin and Rust).
|
| When you know the strengths and weaknesses of each, you'll be
| able to pick the best one for the job. And the concepts
| learned often translate from one language to the other, which
| will make it easier to pick up new ones in the future.
| avl999 wrote:
| Rust does not solve the problems that I deal with in the
| kind of work I do. I have no interest in picking up Kotlin.
| Java/Go/C# solve all the problems that Kotlin solves
| without the interop headaches and I pick between them for
| production code depending on the team and the platform we
| are targeting. For the projects that I am working on right
| now I specifically want Go because of its faster startup
| time than Java/C# and the ability to spin up 10s of
| thousands of threads without breaking up sweat which is
| needed for the sort of work I currently do.
| kubb wrote:
| The constraints of fast startup + "green threads" + easy
| deployment are actually a sound argument for using Go.
| The simplicity of the language isn't.
|
| Kotlin and Rust also have the "green threads" [1] that
| Java lacks, both of them can also produce a native binary
| giving you fast startup. So the claim that "Java solves
| all the problems that Kotlin does" is not completely
| true.
|
| Finally both Kotlin and Rust can let you write safer
| concurrent code, because their type systems actually can
| enforce constraints on what's shared between threads, and
| what's immutable and safe to accesss. Go gives you
| nothing in the type system, but there is a thread
| sanitizer.
|
| [1] Here's a Kotlin program that spins up 100K
| coroutines: https://github.com/Kotlin/kotlinx.coroutines/
| blob/master/kot...
| vips7L wrote:
| Here's a Java program that spins up 1 million virtual
| threads: https://webtide.com/do-looms-claims-stack-up-
| part-1/
| kubb wrote:
| Yes, Loom is an exploratory project to enable this, as
| far as I know, it is not a part of the mainstream Java
| release yet.
| throwaway894345 wrote:
| > The simplicity of the language isn't.
|
| There's a pretty strong consensus among people who have
| used Go professionally (irrespective of whether or not
| they liked the language on balance) that the ability to
| look at any project and immediately understand it is a
| Good Thing, and this property follows directly from the
| language's simplicity.
|
| That doesn't mean it outweighs all other criteria--we can
| say that there is a tradeoff between readability and
| expressability or something like that--but it absolutely
| follows that simplicity is a merit.
|
| To boot, some other things that I would prioritize well
| above any particular type system feature set (at least
| features in excess of what Go provides) include:
| ecosystem, reproducible build tooling, general tooling,
| performance, a solid standard library, friendly
| community, static compilation by default, easy learning
| curve. Note that "tooling" must also be simple to be a
| boon--I don't want to have to learn a DSL to script my
| dependencies, wire up test targets, build static
| artifacts, etc.
| amirkdv wrote:
| > these dynamic languages doing contortions to deal with
| basic things like concurrency
|
| I get the concurrency gains, esp with older versions of
| dynamic languages without native support for coroutines.
|
| But the test coverage argument seems quite contorted. If
| you're accepting 92% coverage because the "return an error"
| lines are not worth testing (fair) then why is that harder to
| achieve in, say, Ruby or Python? Is the argument that your
| 92% coverage in Go is _effectively_ 100% because compiler?
| tptacek wrote:
| Because Ruby and Python force you to unit test for typos.
|
| I like and use both of them but if you're trying to argue
| that the testing problem in Python is the same as that of
| Go or Rust, that argument will fail.
| amirkdv wrote:
| > if you're trying to argue that the testing problem in
| Python is the same as that of Go or Rust
|
| Wasn't trying to make that case, but I can see how my
| comment could be read that way.
|
| I was genuinely trying to understand what the parent
| comment meant. Specifically whether they were saying
| error control code is _the_ critical but hard to test
| part of a code base (which I don't think is typically
| true), or rather error control code is just an example
| among many of less frequently executed paths in code,
| which categorically is easier with a static type checker.
| I think they meant the latter and I don't disagree with
| that.
| mixmastamyk wrote:
| Pyflakes should be the first "test" run, and it finds
| those kind of issues.
| avl999 wrote:
| Yeah the compiler guarantees that a certain class of errors
| can never happen and thus you don't need to go through
| significant effort to cover things like error returns.
|
| Additionally with a dynamic language where the codebase has
| less than a 100% test coverage I would find it very hard to
| refactor anything without sweating bullets. The compiler is
| giving you a free test suite.
| mseepgood wrote:
| It's for large teams and people who do lots of code reviews.
| You don't have to question the language during the review and
| can focus on the code. For example, when you see a language
| construct like a loop or an operator you know that it is what
| it says on the page and that it was not overridden by someone.
|
| https://talks.golang.org/2012/splash.article
| msplash9 wrote:
| It's funny how far you are away from truth.
| throwaway894345 wrote:
| Counterpoint: There are lots of engineers who are pretty
| excited about Go. Go ranked #5 in the 2020 StackOverflow
| Survey's "Most Loved Languages" section, for example, and I've
| never even heard of an account in which the _manager_ lobbied
| to use Go for a project--it 's almost always bottom up. Seems
| like it's not just managers who appreciate being able to come
| into a project and quickly come up to speed and contribute.
| It's strange to me that you portray that property so
| negatively.
| ghostwriter wrote:
| > Counterpoint: There are lots of engineers who are pretty
| excited about Go.
|
| true, there are lots of junior engineers who don't know
| better tooling yet and that are still excited about taking
| random surveys.
| ironmagma wrote:
| It was also the #21 (37% of respondents) most dreaded. For
| context, the "love" rating was a 62% response, so that means
| it's something like a 2:1 love to dread ratio. At my current
| company it's definitely leadership pushing for Go and not the
| other way around, and lots of startups have chosen Go early
| and are stuck to it inflexibly.
|
| Edit: I retract this. Looks like the metrics are simply
| inverses (even though they shouldn't be).
| tptacek wrote:
| This is deeply silly (so is that "dreaded" metric). Go is
| here less dreaded than Julia and Swift, two enthusiast-
| driven languages, as well as Ruby, and is just 2 slots up
| from Python.
|
| You gave away the game when you pointed out it was the "#21
| most dreaded". What is anyone supposed to do with that very
| specific number?
| Google234 wrote:
| You would really put Swift over rust as an enthusiast-
| driven language??
| ironmagma wrote:
| The whole survey is fuzzy data of course, it could even
| be the same people dreading a language as loving it.
| That's why I provided the percentage respondents. Citing
| either one as the value of a language is of course
| dubious, but if we're acknowledging one metric we may as
| well acknowledge the other.
| morelisp wrote:
| > it could even be the same people dreading a language as
| loving it
|
| Are they not literally inverses of each other? It's two
| ways of stating the same number, not something you can
| take as two data points.
| ironmagma wrote:
| The survey doesn't say how the data was collected, but
| there has to at least be a middle "neutral" option
| because the two numbers don't always add to 100%.
| Semantically they are opposites, but so are love and
| hate, and we know that a person can love and hate another
| person at the same time, or so the songs tell us.
| morelisp wrote:
| They do always add up to 100%.
| ironmagma wrote:
| I think you're right, it was confusing because sometimes
| it was only to 99% but that's probably rounding.
| Disappointing and a poor survey methodology or at least
| poor presentation. There are definitely some languages I
| both love and dread, like Java and it would be nice to
| see those as separate metrics.
| tptacek wrote:
| It would be one thing if Go was one of the top 5 most
| loved and one of the top 5 most dreaded languages. That
| would suggest (imperfectly, but meaningfully) that it was
| a polarizing language. But it's the #21st most dreaded
| language; it is less dreaded than Julia, which is a pure
| enthusiast language. Your data point actually doesn't
| show anything.
|
| I think you'd be on rhetorically surer footing just
| arguing that these surveys don't mean anything.
|
| The fact of the matter is that while Go certainly has a
| squadron of haters on message boards (it made several
| design decisions that were almost precision-targeted to
| alienate PL connoisseurs), huge numbers of working
| programmers really like Go. It's silly to argue that
| isn't true.
| ironmagma wrote:
| It is looking like I was wrong about the dreaded metric
| and that it's actually just an inverse. If so, I have a
| strong disagreement with the way this data was collected.
| That said, what matters is the actual qualities of a
| language rather than how popular it is.
| morelisp wrote:
| Geez, just take the L.
| ironmagma wrote:
| Like I said previously, citing any of these values to
| prove a point is dubious. That said I have retracted my
| top level comment and admitted that my analysis is wrong.
| What more do you want?
| throwaway894345 wrote:
| Props for admitting your error, but falling back to
| "there must be a problem with the way the data was
| collected (because it contradicts my priors)" isn't
| particularly admirable.
| ironmagma wrote:
| It's pretty ridiculous that in order to be in the clear I
| would have to agree with the way the survey was conducted
| and presented when it obviously causes confusion, but
| okay.
| throwaway894345 wrote:
| No one suggested you have to agree with the survey's
| methodology. It's one thing to identify specific problems
| with the survey and quite another thing to cite the
| survey yourself, then when your argument is rebutted, to
| argue that there must be something methodologically wrong
| with the survey.
| ironmagma wrote:
| The survey isn't wrong because it says something I don't
| want it to, it's wrong because it says something other
| than what it reads as. Elsewhere I said it was either the
| methodology or the presentation. If they had measured
| dread and it said something other than I wanted it to,
| fine. If they hadn't measured dread but hadn't presented
| it as if they had, also fine. But as it is, the survey is
| misleading because it shows dread as though it was an
| actual quantity and it's not. For instance we know that
| in psychology, you can't measure unhappiness, invert the
| numbers, and call it happiness, because happiness and
| unhappiness are not mutually exclusive.
| throwaway894345 wrote:
| > lots of startups have chosen Go early and are stuck to it
| inflexibly.
|
| Is the implication here that it's a common experience among
| startups to pick Go and regret the decision? Can you give
| any evidence to support this (e.g., a survey of startups
| that chose Go and whether or not they regret their
| decision)?
|
| Or perhaps the implication is that Go is uniquely difficult
| to migrate away from? I have a hard time believing that--
| it's expensive to change languages across the board except
| for a handful of special cases that were designed for
| interop from the start (e.g., Java and Kotlin, C and C++,
| etc)--I don't see anything that makes Go uniquely difficult
| to migrate away from.
| ironmagma wrote:
| There's no implication intended, it's just related
| information that I have which could spark a discussion.
| (I obtained it through speaking to a lot of companies
| I've been interviewing with in the past weeks.) I'm sure
| Go is possible to migrate from, it's just that companies
| that have it are decided on it and not interested in
| alternatives.
| beforeolives wrote:
| > It was also the #21 (37% of respondents) most dreaded.
|
| This could trick someone who doesn't know that there are 25
| languages in that survey and that the most dreaded chart is
| just an inverse of the most loved chart. You could also say
| that Typescript is the #24 most dreaded language (32.9% of
| respondents)... it's also the second most loved language.
| Rust is the #25 most dreaded language (because there are 25
| languages on that list).
|
| https://insights.stackoverflow.com/survey/2020#technology-
| mo...
| ironmagma wrote:
| Rust is an 86% to 14% ratio (6:1 love to dread) which
| would for example mean it's less controversial. Not that
| I put any stake into these numbers.
| beforeolives wrote:
| It's important to note that Rust is not used nearly as
| much commercially which means that most of the people who
| use it are enthusiasts who like the language. So when you
| have a metric like
|
| > % of developers who are developing with the language or
| technology and have expressed interest in continuing to
| develop with it
|
| you then get a very strong selection effect which is the
| main reason why Rust has been at the top of that survey
| for a number of years now.
| fnord123 wrote:
| Senior developers also like to be able to jump into a remote
| part of the code base and also immediately understand what is
| going on.
|
| https://news.ycombinator.com/item?id=27051629
|
| > Bingo, Go is geared towards junior programmers. Somebody who
| exits the university has to be able to feel productive within
| two weeks of using it. That's literally the cornerstone of the
| entire design and all things follow from it (C-like syntax,
| attempt to minimize the number of language constructs, and the
| heavy focus on imperative programming which is what they teach
| in college).
|
| Your two critiques opine how easy it is to pick up Go. Clear
| code, like documentation, is drugery. It's not exciting. It's
| boring and that's fine. It's what I personally want. And
| looking at GitHub and Gitlab repos it seems a lot of people
| want it too.
| kubb wrote:
| I'm always impressed by how effortlessly this claim of the
| extraordinary readability of Go code is thrown around by the
| language's apostles, given how substantial that claim is, and
| that it's only backed up by anecdotal arguments with no
| context about things like the problem solved or the size of
| the code base involved.
|
| Simplicity is a good thing. Oversimplification in fundamental
| spaces like the framework for expressing your ideas is a
| tempting, seductive short-term win that will squeeze the life
| out of you when it's too late.
|
| Here are some ways in which Go code is harder to read and
| reason about it because of the language's low capacity for
| abstraction:
|
| * The need to inspect loop bodies to understand which simple
| algorithm is being used. Is it a sum, or a find?, or
| something more complex? Well, let's look for all the ifs and
| breaks and accumulators, and reason about it, before we can
| be sure.
|
| * The difficulty in verifying guarantees about your program,
| for example ensuring that the caller doesn't append to a
| slice passed to a function if we want to append to that slice
| ourselves.
|
| * The tendency to have logic spreading multiple screens
| vertically, because of verbose error handling, and data
| transformation. You need to keep a part of a function in your
| short-term memory in order to understand the whole (or zoom
| out and get a magnifying glass).
|
| * The difficulty of managing and verifying the correctness of
| concurrently executed code. A wait group needs to be
| incremented with the number of the joined goroutines
| manually. There's no abstraction over common operations, like
| merging channels, and their manual implementation is error
| prone and complex.
|
| * The need to roll your own implementation of menial tasks,
| like cloning a map, or getting a list of map's keys. This
| introduces distractions into the code, almost meaningless
| sections of it that nevertheless need to be understood and
| classified as unimportant by the reader, and take up precious
| visual field.
|
| * No support for immutability makes it less obvious to the
| reader which parts of the gadget they're looking at can move.
|
| * Almost every more sophisticated data structure needs to
| have a custom implementation, that needs to be audited for
| bugs.
|
| I think this belief in the readability of Go code might come
| from the misconception that if a tool that you use to build
| something is simple, the resulting thing will be simple too.
| I can forgive that mistake, but the misconception has to be
| cleared up. We can't have unsubstantiated arguments about
| simplicity till the ends of time.
| fnord123 wrote:
| > I'm always impressed by how effortlessly this claim of
| the extraordinary readability of Go code is thrown around
| by the language's apostles, given how substantial that
| claim is, and that it's only backed up by anecdotal
| arguments with no context about things like the problem
| solved or the size of the code base involved.
|
| > I think this belief in the readability of Go code ...
|
| I guess you'd be the one to know since you're the one who
| originally made the claim.
|
| To be fair, Some of the items in your bulleted list are
| downsides to the language. It can't be all things to all
| people.
| andresp wrote:
| Readability is not a characteristic of Go code. People are
| either confusing readability with lack of features or too
| biased by what they have been working on.
| philosopher1234 wrote:
| Specific reasons go is more readable than your run of the
| mill language off the top of my head:
|
| 1. Culture of small api surfaces. The number one cause of
| complexity is having large apis with many arguments and
| knobs and whistles. Every time you interact with a large
| api you pay a decision/comprehension tax. Go culls this
| dramatically.
|
| 2. Small api in the language itself. When reading and
| writing the language itself you do not have to scratch your
| head at new creative constructs. This is the most commonly
| cited reason, and it's a real reason.
|
| 3. No inheritance. The lack of immense hierarchies of data
| structures means it's dead simple to find out where the
| implementation for a given function lives.
|
| 4. Gofmt
|
| 5. Simple error handling. Easy to wrap with all the
| contextual info you would need to fix a bug.
|
| 6. preference for short names. This visually lightens the
| page when you're reading code, enhancing clarity.
|
| 7. Packages. You always know when code is being imported
| from somewhere else and precisely where it's imported from,
| as you must reference the package every time you reference
| its code.
|
| 8. No constructors.
|
| So no, it's not a misconception, go actually is very
| readable and more so than most languages.
| josephg wrote:
| I have some text based operational transform code I port to
| each language I learn to get a feel for it. (And I've got a
| version in C, JS, rust, swift and go). The go version is
| _clunky_. It's longer than the others, and the lack of
| parameterised enums (or any type of simple polymorphism)
| makes it much harder to understand and reason about. The
| code is longer and uglier than the rust and swift
| equivalents. And it runs slower than the C and rust code.
| (I didn't benchmark swift). After my experiment I find I
| have little appetite for the language.
|
| I feel like programming is like electrical engineering. A
| lot of people graduate expecting to design transmission
| systems and power stations. But most of the work in the
| field is simple stuff like wiring up a new light switch at
| grandma's house. Go feels like a language designed for that
| group of engineers - boring as a feature, reliable, simple
| to reason about, anti-clever (so whoever comes in after you
| can understand your work). It's a predictable language for
| code-as-content. It's great that people who do that kind of
| work have better tools. But I also accept that that's not
| the type of software engineer I am. I want my code to be
| clever. I like to push at the limits of expressibility in a
| language. For the types of work I do (lately implementing
| various CRDTs), small, tight, fast code is better than
| simple, verbose code that any tom, dick or Harry could
| comfortably maintain.
|
| Does this distinction have a name?
| senko wrote:
| > I want my code to be clever. I like to push at the
| limits of expressibility in a language. For the types of
| work I do, small, tight, fast code is better than simple,
| verbose code that any tom, dick or Harry could
| comfortably maintain.
|
| > Does this distinction have a name?
|
| Yeah. Write-only code.
| ironmagma wrote:
| There is some complexity that needs to be in a language. Why?
| Because applications are complex. The complexity will therefore
| either live in the language or in you. If it lives in you, the
| language is being unhelpful. For a prime example of this, look
| at Assembly. It provides nothing and is as simple as possible;
| it's just a transparent wrapper around machine code. Yet it's
| incredibly complex to write Assembly code.
| SergeAx wrote:
| Let me see how much code was contributed by managers in Docker,
| Kubernetes, Terraform, Hugo, Traefik, CockroachDB etc
| codebases...
| tptacek wrote:
| This isn't so much a "take" as a "regurgitation" of the most
| hackneyed PL-fight slur against Go, that it's a language for
| managers and not for programmers. Of course, large numbers of
| programmers who work in Go by choice for personal projects
| argue against that. But the argument thrives because there's a
| kernel of truth to it, in that if you wanted to pick a
| programming language based purely on expressive shininess,
| you'd write in OCaml.
|
| What makes the argument superficial is that the list of things
| PL-connoisseur languages have that mainstream languages lack is
| long, and can be used to exclude almost all programs; the
| argument proves far too much, and isn't really saying anything.
| The fact is, it's not managers making people pick Go and
| Python; the assertion is false.
|
| There are real arguments you can bear against Go. This just
| isn't one of them.
| sweeneyrod wrote:
| "But the argument thrives because there's a kernel of truth
| to it, in that if you wanted to pick a programming language
| based purely on expressive shininess, you'd write in OCaml."
|
| Eh, I think OCaml is actually the least shiny language in its
| reference class: Haskell, Scala and Rust are all shinier.
|
| I think that taste for languages varies a lot, and certainly
| plenty of excellent programmers find Go is to their taste and
| statically typed functional languages are not. But I think
| it's also true that there are lot of people who like Go with
| Java/Python/JavaScript as their only points of comparison,
| and who would actually prefer OCaml or F# if they tried them.
| computerex wrote:
| I prefer easy things over complex things. Only a fool would
| prefer complexity for complexity's sales. Repetitive,
| boilerplate is easier to understand and work with than highly
| abstract, extremely clever code.
|
| For personal projects I'd say write the code however you want.
| But for professional work, I think the emphasis should be
| firmly on code readability. I'd almost always forego some
| beautiful abstraction that's hard to grok without the necessary
| background in favor of dumb abstractions that are easier for
| most people to understand.
| Quekid5 wrote:
| Easy is not the opposite of complex. Simple is the opposite
| of complex.
|
| Once systems grow, 'easy' quickly turns bad because of lack
| of abstraction capability.
|
| EDIT: A good video on this is 'Simple Made Easy' by Rich
| Hickey.
| ironmagma wrote:
| Relevant talk by Rich Hickey, "Simple Made Easy":
| https://youtu.be/kGlVcSMgtV4
| nicoburns wrote:
| > Repetitive, boilerplate is easier to understand and work
| with than highly abstract, extremely clever code.
|
| I think much of the reason for disagreement is that this
| isn't universal. I find boileplate heavy code much harder to
| reason about than abstracted code. Especially if the
| abstractions are either standard ones (map, filter, etc), or
| well-documented.
|
| I guess there's a happy medium. Personally I find Java too
| abstracted. Go not abstracted enough, and that lanaguages
| like Rust and JavaScript strike a good balance.
| Philip-J-Fry wrote:
| That's a take alright. I wouldn't say it's particularly good
| though.
|
| Why shouldn't all languages be easy to understand? Why would
| anyone want a hard to understand language unless it provides
| benefits significant enough to offset that? Newsflash, most
| don't. Go has your cross platform, it has your simple code, it
| has your single executable and it has your performance. That
| suits the needs of most developers should they be interested in
| Go at all.
|
| The fact that someone with little knowledge can contribute
| easily to any Go project is a huge benefit to the language.
| It's simple enough and the code most people write is idiomatic
| enough that you can drop into any project and know where to
| start. That is something I can't say of any Java or C# project
| I've looked at before.
| philosopher1234 wrote:
| Smart engineers underrate, and are even insulted by (I.e this
| comment) simplicity. If the language is simple enough that a
| manager can write in it, maybe it also means that smart
| engineers can dedicate their limited brainpower to solving
| business problems not language puzzles. I assert that this is
| true in gos case.
| bilal4hmed wrote:
| Is Go no longer worth it to learn? Seeing a lot of posts where
| over the long term go code base is not fun to manage.
|
| Was looking at my next language after python. Rust is one ,
| should something like kotlin be the other ?
|
| For interviews python seems to be nice and fast to type.
| spamizbad wrote:
| A language isn't going to save you from a bad codebase. And the
| longer I work in this industry the more this has become
| apparent to me.
| alert0 wrote:
| Go is my favorite language but I'm still learning Rust. Would
| highly recommend either. I hate Python as a language but use it
| for web scraping and the occasional data transformation.
| baby wrote:
| It's funny but I'd still say that Golang is the easiest
| language to maintain, due to the code being harder to write but
| easier to read.
| Philip-J-Fry wrote:
| Go is 100% worth it. If you're seeing these posts on HN then
| you should know that the majority of Go posts here are just
| "why Go is bad" posts. You'll rarely find an upvoted post about
| why Go is good.
|
| From a Go dev who came from .NET, Go is one the best tools I've
| learned in a very long time. Code is incredibly readable, I
| never come back to an old code base and have to wrap my head
| around the weird abstractions like
| "MapperServiceFactoryFactory" because they're no idiomatic.
| Code can be verbose, but the verbosity is what aids its
| readability.
|
| I haven't had any issues maintaining large Go codebases, the
| only issues you come across are the same regardless of the
| language you use. And that's things like ensuring consistent
| style across a team of developers.
| dangoor wrote:
| I hope you didn't get an impression like this ("Go not being
| worth it to learn") from my post. We think it's great and that
| our Go is going to be much easier to maintain over the long
| term than our Python was.
|
| It's all rock solid and easily understandable by the whole
| team.
| bilal4hmed wrote:
| Thank you for the reply. I didnt get that impression from
| your post at all, but from the larger comments & posts on HN
| and programming subreddit. I have wanting to learn Go, but
| seeing so much negativity around it was making it harder to
| start learning.
| dangoor wrote:
| Go may be more polarizing than a lot of languages. It makes
| tradeoffs that aren't as exciting, which turns people
| against it, I think.
|
| There are plenty of legitimate reasons to choose a
| different language, so it makes sense to figure out what's
| important for oneself and go from there. The only problem
| is that it's hard to know all of the aspects that may be
| important without trying a tool out... so we do, quite
| reasonably, turn to blog posts with other people's
| opinions.
|
| I do think it's good to differentiate the opinions of
| people who have really worked with the tool vs. those who
| are just e.g. complaining about Go's error handling because
| they're used to exceptions but they haven't done any
| significant work with Go.
|
| For deciding on whether or not to learn a language: I'd say
| it depends on _why_ you want to learn a language. If it's
| for getting a different job, then look at the kinds of jobs
| you want and learn the languages/skills to do that. If it's
| for pure knowledge, then learning languages that teach you
| something new are useful. Go's concurrency might be
| interesting in that regard. Rust's borrow checker is
| certainly interesting.
| cle wrote:
| I maintain hundreds of thousands of lines of Go code, for a few
| years now. I would not pick another language for that.
|
| The important properties with maintaining code bases like that
| are language regularity (most code is written the same way and
| you don't have to make personal "taste" decisions on things),
| good documentation and online communities, well-maintained
| libraries, tooling features for versioning and namespacing,
| deployment simplicity, etc. Go nails those things.
|
| I agree that Python is great for interviews. I would not use it
| for a large codebase maintained by a bunch of people for years,
| unless there is a _really_ compelling reason.
| mixmastamyk wrote:
| Typing is available now, and other QA tools for years.
| gct wrote:
| I want to like Go but it's just too much of a mess of a language,
| and the power it gives you isn't enough to justify it. C++ is at
| least fast. You can see this in the proposal for generics[0],
| where they have to tap dance around the fact they didn't consider
| generics in the language from the beginning.
|
| [0]:
| https://go.googlesource.com/proposal/+/refs/heads/master/des...
| jamra wrote:
| Are there any web frameworks you particularly like in C++?
| [deleted]
| karolist wrote:
| Just want to add that Go is ready for webdev pretty much out
| of the box, you don't need a framework to work with HTTP
| requests, routing, basic auth etc. There are things like
| gin/mux that makes it more convenient, but absolutely not
| necessary.
| baby wrote:
| The whole point of Golang is that it is easy to read,
| contribute to, and maintain. This is because it is less
| expressive, and you have less freedom when you write code. In
| turn this can make writing code harder, but that's the trade
| off you have to take if you want to make reading code easier.
|
| I firmly believe that people have managed to write amazing and
| large applications without generics, and the addition of
| generics will simply kill one of the biggest feature of Golang:
| simplicity.
| throwaway894345 wrote:
| > it's just too much of a mess of a language
|
| This is vapid criticism, and it's only going to invite language
| flame wars. There's certainly room to criticize Go, but just
| saying it's "a mess" isn't contributing anything to the
| conversation.
| mseepgood wrote:
| The language has barely changed since 1.0.
| andreygrehov wrote:
| Just a minor note on Go vs C++.
|
| C++14 specification: 1354 pages.
|
| Go specification: 50 pages.
| ris wrote:
| And brainfuck is 340 lines: https://github.com/brain-
| lang/brainfuck/blob/master/brainfuc...
| DangitBobby wrote:
| Not sure why this is downvoted. It pretty clearly
| demonstrates the point that there is a such thing as being
| too simple, and that simplicity for its own sake is not a
| virtue.
| gct wrote:
| R5RS is 40 pages and you can do so much more in that
| language.
| synergy20 wrote:
| for c++ spec, many are due to back compatibility. if you
| stick to modern c++ for new projects, it's much concise with
| much less pages.
| kevindong wrote:
| Can you link to such a document (one that details the spec
| for only recent versions of C++)?
| gher-shyu3i wrote:
| Could you elaborate on what power it give? After working on
| several projects in a golang monorepo, it's exceedingly weak at
| modeling, which results in verbose code that is also thin -
| meaning that it takes a lot to write to say a few things. You
| can see the for loops and if conditions in front of you, but
| it's difficult to extract the underlying logic its trying to
| convey.
|
| The code bases were a complete mess to work on, and even new
| projects are suffering because of it - no lessons learned can
| fix it because the language is so weak.
| baby wrote:
| Engineers who complain about that are usually the ones who
| want to write extremely clever solutions that nobody will be
| able to understand nor maintain after they have left.
| gct wrote:
| I said it _doesn't_ give you enough power to justify the
| baggage, apologies if I wasn't clear. Iteration/modeling is
| one of my gripes in fact. The only way to copy a map is a for
| loop, really?
| gher-shyu3i wrote:
| Sorry about that. You wrote that the power it gives you
| does not justify the mess of the language. I agree that the
| language is messy, but that it also lacks any power
| whatsoever worth speaking about :)
| DangitBobby wrote:
| This isn't really fair. Despite requiring overly verbose
| code with lots of repetition and boilerplate, it is still
| quite powerful.
| gher-shyu3i wrote:
| Could you list some of its powerful features? The only
| thing that gets a passing mention is goroutines, and even
| they are not implemented in a great manner.
| DangitBobby wrote:
| Portable binaries, good cross-compilation support, easy
| to make shared libraries for use in, say, Python code for
| easy performance gains, goroutines and channels (they are
| a mixed bag).
|
| Apart from these, the language does make it easy for
| novices to write performant one-offs similar to how
| Python enables them to write slower one-offs. I
| personally hate writing in it, but I will when I think it
| makes my life easier.
| philosopher1234 wrote:
| Small compromises in generics doesn't make it a mess.
| throwaway894345 wrote:
| It's also weird to use C++ to support the argument that Go's
| generics are too bolted-on (as though C++ generics resemble a
| holistic upfront design). I like C++ and everything, but I've
| also _used it_ and thus know better.
| gct wrote:
| You're not wrong, mistakes were obviously made with C++
| (and Rust for that matter).
| azth wrote:
| > Our former .NET engineer now says, "Being able to call a
| function that doesn't return an error and know for sure that it
| must succeed is really nice."
|
| Except when it panics. The article lacks substance honestly.
|
| That being said, it further cements the notion that golang has
| been a replacement for Python and Ruby, not Java/C#/C++ as
| originally planned.
| philosopher1234 wrote:
| Panics are prevented by culture, and I fail to see how a c# dev
| complimenting go invalidates gos competitive edge over c#?
| Philip-J-Fry wrote:
| If code can panic it should be documented. Code you write
| shouldn't ever panic without good reason during the regular
| runtime of your application. A panic means that the current
| goroutine has encountered an unrecoverable error, which is
| usually only the case for bugs such as out of range indexes or
| nil pointers.
| baby wrote:
| I'd say Golang has successfully started replacing Java
| everywhere...
| corty wrote:
| Java is the new COBOL. It will not be replaced in this
| century.
| AnimalMuppet wrote:
| (Checks calendar.) Oh. That's... quite a while. Longer than
| the entire history of high-level languages, in fact.
|
| Not sure you're wrong, though...
| corty wrote:
| Go can easily replace Python or Ruby (because it is faster and
| libraries are available to do what you need). Go can replace
| Java and C# especially because concurrency is easier and
| performance is on par, if you can get along with the inferior
| libraries Go provides. Go cannot replace C++ in any function,
| because its compiler is just too primitive, low-level things
| are impossible and libraries will never be on par with what C
| and C++ have.
|
| But generally, Go is nice because there is sufficient tooling
| to do most things nicely and the language is primitive enough
| to make the tooling work in almost all situations. Which is
| different from C++, because tooling there is always too stupid
| for templates, macros, inheritance and pointers. And it is
| different from Java where tooling is unusably complex, slow and
| enterpricey. Also, Go didn't accumulate too many "surprise"
| misfeatures yet, so code can be more reliably written and
| reviewed than in any of the other languages the parent named.
| Panic can be seen as the rare instance of such a misfeature,
| but usually it is only used to signal typically unrecoverable
| problems like "out of memory". So it is far from the footgun
| that exceptions are.
| zozbot234 wrote:
| Rust has great tooling compared to C++, at least on
| mainstream platforms. It's a no-brainer choice for green-
| field projects where low-level development is required.
|
| And the misfeatures of C++ are the stuff of legend, so Rust
| does way better from that POV as well.
| dangoor wrote:
| Panics that pop up in our logs are serious problems that we
| address. If you've got Go code panicking frequently, you're
| doing something wrong.
| lima wrote:
| That's exactly the point - it must succeed, or panic. Panics
| are for programming errors and crash the program.
| avl999 wrote:
| panics != errors
|
| that person is talking about application level error handling.
| In most cases if a functions panics generally the caller isn't
| expected to do anything about it other than perhaps have a
| panic handler at the top level of the app that logs things and
| lets it crash. So in general you don't need to think about
| catching or handling panics in most of your application code.
| It is the equivalent of a method that you are calling from your
| java code returning an undocumented NPE.
| emehrkay wrote:
| I cant wait for that slices package. If I have to write this one
| more time im going to have a breakdown func
| inSlice(needle someType, haystack []someType) bool{}
| SergeAx wrote:
| I would use hashmap and get O(1) instead of O(N).
| omginternets wrote:
| Linear search through a slice is almost always going to be
| faster than a map operation, because N is almost always small
| and slices have great cache locality.
|
| If your slice has a million entries, it's definitely a
| different story.
| inertiatic wrote:
| You know, inserting N elements into a hashmap is O(N).
| zabzonk wrote:
| The number of lines written is no measure of success, rather the
| reverse. How many lines of Python did this re-write replace?
| BiteCode_dev wrote:
| > we needed 2.7x lines of Go to handle the same features as our
| Python code
|
| But it's for a rewrite, so:
|
| - you can use the most modern language features. Python 3.9 is
| less dense than Python 2.7 (E.G: a silly 2.7 example would be
| https://0bin.net/paste/xpnCov-3#3s2AgDReXpeqG4knegGwdnYNi523...
| which is 37 lines, the equivalent in 3.9 is https://0bin.net/pa
| ste/b4DVZIS5#372LGWNLBJfDUNQGAMsDlJPNlkVy..., down to 25
| lines). Also note that it's not just less lines, but way
| shorter, yet clearer, lines. Something LoC fails to take in
| consideration.
|
| - you can use the most modern stack. E.G: fastapi is less dense
| than flask as soon as you use data validation, plus it adds
| typing for free.
|
| - you know very well the problem to solve so you get it right
| the first time.
| ojhughes wrote:
| Is rewriting everthing from scratch ever a good idea? I can
| understand the need to get off Python 2 but migrating the entire
| stack to Go sounds very risky and hard to justify.
| dangoor wrote:
| I blogged about this[1] as we were starting the project. The
| short story is that moving from App Engine 1st
| Generation+Python 2 to App Engine 2nd Generation+Python 3 would
| have _also_ been a ton of work, but would have given us fewer
| benefits out the other end.
|
| We reduced risk in the project by making it very
| incremental[2]. All of this Go code has been incrementally put
| in front of users without anyone really noticing.
|
| As a non-profit, we absolutely did need to justify it to our
| senior leadership and board. They've been super supportive
| because they know exactly what we're dealing with and how this
| benefits us for the long term.
|
| [1]: https://blog.khanacademy.org/go-services-one-goliath-
| project... [2]: https://blog.khanacademy.org/incremental-
| rewrites-with-graph...
| andrewfromx wrote:
| i'm forced to work in Kotlin vs. Go sometimes at my job and I
| agree 100%, go is the best. Just a few items:
|
| 1) if thing vs if (thing) kotlin makes you add un-needed ()
|
| 2) a string is always "" vs null!
|
| 3) you can follow the logic always 100% of the time vs. getting
| lost in a maze of clever kotlin.
| gher-shyu3i wrote:
| > you can follow the logic always 100% of the time
|
| You can see the bare bones if conditions and for loops sure,
| but what are they actually trying to do? golang code is very
| thin - it takes a lot to write to convey a particular piece of
| logic. What a few lines of map/filter/accumulate/group by in a
| more expressive language like Java or Kotlin becomes dozens of
| lines in golang. It becomes challenging to extract the
| underlying logic and to follow it. Java and Kotlin are strictly
| superior.
| kubb wrote:
| You might have missed the part of the article where they
| describe the weaknesses of Go that they've discovered while
| porting their Python code, but they downplay them to make the
| whole thing sound more like a success.
| LanceH wrote:
| It's getting the job done, it's faster, and the developers
| are happy. It sounds like a success because it is.
| DangitBobby wrote:
| The developers say positive things after having spent
| months on this effort. It's just as likely a psychological
| defense mechanism against melancholy as it is an actual
| optimism for the new Eldritch Horror that's been unleashed
| on them. Especially if they weren't given a choice on what
| language they would be using.
|
| > Our engineers come from a variety of programming
| backgrounds, so we certainly do have a diversity of opinion
| on Go vs. other languages. That said, Go is doing the job
| we "hired" it to do when we started Goliath, and we're
| thankful for the team driving its continued evolution and
| the community that has built up around it!
|
| If you were calling a reference for a potential new hire,
| would you consider this a glowing review?
| entire-name wrote:
| Isn't item (3) more of a policy thing rather than a language
| thing? Granted, I actually never coded in Kotlin (and very very
| little in Go), so if it's "encouraged" in Kotlin, then your
| point (3) makes sense.
| isbvhodnvemrwvn wrote:
| I've worked with systems where some of the things were
| defined as a DSL within Kotlin (with implicit receivers and a
| shitton of extension functions), so you can definitely shoot
| yourself in the foot.
| lima wrote:
| Yes and no - that this kind of policy is hard to enforce, and
| only affects your code base.
|
| The nice thing about Go is that its simplicity permeates the
| entire ecosystem.
| dangoor wrote:
| This is actually one of our reasons for choosing Go! We
| recognized that we'd have to come up with a fairly detailed
| style guide for Kotlin to reflect how we wanted to generally
| approach things so that it's possible to jump into another
| part of the codebase and not get lost.
| newnamenewface wrote:
| I feel like go by itself is very nice but dependency management
| across inter-opping projects really sucks. I feel like an idiot
| every time I run into dependency versioning issues and have to
| spend half a day figuring out what mixture of versions of each
| dependency to set. Any advice?
| andrewfromx wrote:
| i don't think dependency management is great in any language.
| Maybe cargo and rust win at that? But I happen to know go's
| well at this point. Ruby is terrible! And don't even get me
| started on node.js. But recently I got a go build error and
| had to just put in printlns:
| https://andrewarrow.substack.com/p/installing-go-from-
| source...
| house9-2 wrote:
| > i don't think dependency management is great in any
| language. Ruby is terrible!
|
| If you use bundler and Gemfile.lock everything 'just works'
| in Ruby.
|
| Node/npm/yarn is a nightmare
| tmk1108 wrote:
| One of the reasons I love Go is that it's just so easy to read Go
| code written by other people on my team or third party libraries.
| There have been tons of cases where I'm working with another
| library and I just step into their code in my editor to
| understand how something works. And the code is always so easy to
| follow.
|
| It's very rare that I come across weird patterns or someone
| trying to be very clever. Its always straightforward code.
| zozbot234 wrote:
| Yup, Go is certainly easier to read than Python.
| meinfuhrer wrote:
| This has been my experience. I love the fact that the standard
| library itself is written in Go, so it's easy to see what
| exactly is going on and even learn some idioms that way. It's
| refreshing for me personally as I had a JavaScript background
| before learning Go
| [deleted]
| andresp wrote:
| Haha this must be ironic or Stockholm syndrome. With duck
| typing and channels, missing basic modern language
| constructions... it is definitely not known for readability.
| doggodaddo78 wrote:
| Depending on functionality delivered, it sounds over-engineered
| if their codebase is 500 KLoC. Bragging about removing LoC would
| be better.
| gher-shyu3i wrote:
| It's the nature of golang to be verbose like that. It has very
| low code density, meaning it takes writing a lot of code to
| express something that could have been expressed in a much more
| concise manner in a stronger modeling language like Java or C#.
| throwaway894345 wrote:
| I'm strongly of the opinion that people make much too big a
| deal out of line counts and character counts. I'm very
| doubtful that there will be a significant difference in
| quality between two equally-complex programs which differ
| only in that one is more terse.
| dangoor wrote:
| > Depending on functionality delivered
|
| This comes up often in Hacker News discussions, though usually
| without the qualifier I've quoted above, which I appreciate you
| adding. It's really easy to underestimate how much there is
| beneath the surface of almost any product.
|
| People start by looking at Khan Academy and thinking "it's just
| a collection of videos, and even those are hosted on YouTube."
| But we've also got exercises and articles. Mostly created in-
| house, in a CMS that can handle the needs of creating math and
| science content. Translated into dozens of languages mostly by
| volunteers. Organized into courses based on, in some cases,
| regional curriculum.
|
| We need to keep track of which content a learner has worked
| with and which skills they've mastered so that we can help them
| keep improving.
|
| We connect with The College Board to help with specific SAT
| prep based on test results you've had.
|
| Accounts can be logged into using Clever, which is common in
| school districts. They can be connected to Google Classroom,
| and teachers can assign content (and manage classes on the
| site).
|
| We offer higher-level reporting for school districts, plus
| special tooling to get all of the district's students loaded
| into Khan Academy.
|
| Around all of these features are the inevitable tricky edges.
| All of this needs to be able to handle millions of users every
| month.
|
| In the process of doing this port, we _are_ actually
| deprecating some old and outdated stuff. Our site is 10+ years
| old. But most of what we have are features used by lots of
| people all the time.
| thiht wrote:
| Agree, 500kloc seems excessive. Maybe they're counting
| dependencies somehow? Or maybe there's a lot of hidden
| complexity but in the case of Khan Academy I don't have enough
| imagination to see where.
| avl999 wrote:
| They are referencing the LoC metric to show that they are not
| using it for some toy CLI app used by 2 members in the team and
| therefore justifying the reason for this blogpost. 500k LOC
| doesn't seem that unreasonable, not sure how you can call it
| "over-engineered" without even knowing what the system is
| actually doing or having access to their architecture.
| thr1123 wrote:
| or maybe even toy apps becomes eccessively verbose in go,
| given the abundance of if err != nil and 5-rows cycles
| instead of item.map(fn)
| dkarras wrote:
| I'm not very familiar with KhanAcademy besides the beginnings of
| it where it was just a youtube channel. What are they doing now
| to warrant half a mil lines of code?
| _rpd wrote:
| At least in mathematics, after each video, they have a fairly
| sophisticated set of tests that are quick to pass if you've
| understood the concept, or that adapt in difficulty to your
| level of understanding and attempt to fill in any gaps. It's
| quite impressive. Kids can definitely use it to catch up or
| work ahead on their own if they are interested.
| dkarras wrote:
| Thank you, that sounds pretty cool.
___________________________________________________________________
(page generated 2021-05-16 23:00 UTC)