[HN Gopher] Russ Cox is stepping down as the Go tech lead
___________________________________________________________________
Russ Cox is stepping down as the Go tech lead
Author : bojanz
Score : 709 points
Date : 2024-08-01 19:29 UTC (1 days ago)
(HTM) web link (groups.google.com)
(TXT) w3m dump (groups.google.com)
| ainar-g wrote:
| Thank you, rsc, for all your work. Development in Go has become
| much more enjoyable in these 12 years: race detector,
| standardized error wrapping, modules, generics, toolchain
| updates, and so on. And while there are still things to be
| desired (sum types, better enum/range types, immutability, and
| non-nilness in my personal wishlist), Go is still the most
| enjoyable ecosystem I've ever developed in.
| vyskocilm wrote:
| Well written list of what made Go better language during last
| years. I'd add iterators, the recent big thing from Russ.
| galkk wrote:
| Wow. I haven't followed Go for a while, thanks for that note.
|
| Iterators are very nice addition, even with typical Go
| fashion of quite ugly syntax.
| mseepgood wrote:
| They don't have any syntax that differs from the previous
| Go versions.
| kjksf wrote:
| Just last week I've implemented an iterator for my C++ type
| and lol to your comment. It was fucking nightmare compared
| to how you (will) implement an iterator in Go.
|
| I didn't study the reason why Go chose this way over
| others. I do know they've considered other ways of doing it
| and concluded this one is best, based on complex criteria.
|
| People who make value judgements like this typically ignore
| those complex consideration, of which playing well with all
| the past Go design decisions is the most important.
|
| Frankly, you didn't even bother to say which language does
| it better or provide a concrete example of the supposedly
| non-ugly alternative.
| galkk wrote:
| C#, python - here are the most mainstream examples of
| syntax that doesn't look alien.
| valyala wrote:
| Iterators and generics go against the original goals of Go -
| simplicity and productivity. They complicated Go language
| specification too much without giving back significant
| benefits. Iterators and generics also encourage writing
| unnecessarily complicated code, which makes Go less pleasant
| to work with. I tried explaining this at
| https://itnext.io/go-evolves-in-the-wrong-
| direction-7dfda8a1...
| jdnendjjd wrote:
| This argument is brought up again and again, but it is just
| wrong.
|
| Go had both generics and iterators from the get go. Just
| not user defined ones.
|
| Thus it is obvious that the creators of the language always
| saw their need for a simple and productive language
| joeblubaugh wrote:
| I do agree with his point that the implicit mutation of
| the loop body for an iterative will be difficult to
| debug.
| eweise wrote:
| Not obvious to me. We just implemented a streaming
| solution using the iterator interfaces. They are just
| functions so reading the code its easy to understand.
| Adding special language support only serves to obfuscate
| the actual code.
| nasretdinov wrote:
| I'm not sure I can agree about generics. In many cases Go
| code is already fast enough, so other things come to play,
| especially type safety. Prior to generics I often had to
| write some quite complicated (and buggy) reflection code to
| do something I wanted (e.g. allow to pass functions that
| take a struct and return a struct+err to the web URL
| handlers, which would then get auto-JSONed). Generics allow
| to write similar code much easier and safer.
|
| Generics also allow to write some data structures that
| would be useful e.g. to speed up AST parsing: writing a
| custom allocator that would allocate a large chunk of
| structs of a certain type previously required to copy this
| code for each type of AST node, which is a nightmare.
| everybodyknows wrote:
| Nomination for RSC's greatest technical contribution: module
| versioning. Absolutely fundamental to the language ecosystem.
|
| https://research.swtch.com/vgo-intro
| maxmcd wrote:
| Agreed, see the index of those posts:
| https://research.swtch.com/vgo
|
| Other contenders I find myself sharing and re-reading:
|
| - https://swtch.com/~rsc/regexp/regexp1.html
|
| - https://swtch.com/~rsc/regexp/regexp4.html
|
| - https://research.swtch.com/bisect
|
| - https://research.swtch.com/zip
| agumonkey wrote:
| One I enjoyed a lot (a lot) was this one
| https://research.swtch.com/pcdata
|
| Hope he gives us more in the future
|
| thanks rsc
| trustno2 wrote:
| The interesting thing is - this went pretty much against the
| community at the time.
|
| At the time, the community seemed to have settled on dep - a
| different, more npm-like way of locking dependencies.
|
| rsc said "nope this doesn't work" and made his own, better
| version. And there was some wailing and gnashing of teeth,
| but also a lot of rejoicing.
|
| That makes me a bit sad that rsc is leaving.
|
| On the other hand, I don't really like the recent iterator
| changes, so maybe it's all good.
|
| Btw if you reading this rsc, thanks a lot for everything, go
| really changed my life (for the better).
| nasretdinov wrote:
| Iterators definitely have one of the strangest syntaxes
| I've seen, but if you promise not to break the language you
| better not introduce new syntax without a Major reason
| (like generics, but even those actually introduced next to
| no new syntax, even re-using interfaces o_O).
| foldr wrote:
| Iterators don't really introduce any new syntax, strange
| or otherwise.
| jdnendjjd wrote:
| That's what he said
| foldr wrote:
| In part of the comment yes, kind of, but the comment
| begins by saying "Iterators definitely have one of the
| strangest syntaxes I've seen". As there is no syntax
| specific to iterators in Go, I find this a bit hard to
| understand.
| makkes wrote:
| s/syntax/API/
|
| It's not that hard to understand what OP means.
| mseepgood wrote:
| It's just the visitor pattern, taught in software
| engineering 101. A function that takes a callback
| function that gets called for each visited value. Nothing
| strange about it. Many standard library functions such as
| sync.Map.Range or filepath.Walk have always used it. The
| new thing is that it now gets easier to use on the caller
| side.
| nasretdinov wrote:
| Well, yes, that's the thing: you don't get any special
| syntax for generators (like "yield" keyword), which makes
| them look quite weird compared to other languages that
| have native support for them. You need to have very
| clunky and verbose syntax (at least I view it as such)
| which consists of having to define an extra nested
| closure and use a function pointer that was passed to
| you. Having a new keyword would allow for a much nicer
| looking generator functions, but that would break all
| existing tooling that doesn't yet support that keyword
| (and potentially break existing programs that use yield
| as a variable name or something like that).
| foldr wrote:
| Seems like a total non-issue to me. It's conceptually
| very easy to grasp and follows the normal Go syntax for
| defining functions. And what percentage of your code base
| is really going to consist of custom iterators? A
| syntactic shortcut might save you two lines of code for
| every 5000 you write. A lot of Go programmers will
| probably never write a custom iterator from scratch. The
| important thing is to make the custom iterators easy to
| _use_ , which I think has been achieved. I'm sure they'll
| consider adding some syntax sugar in time, but it would
| be a trivial convenience.
|
| The benefit of Go's generator implementation is a huge
| simplificacion of the language semantics compared to
| other approaches. The generator function has no special
| semantics at all, and when used with 'range', all that
| occurs is a very simple conversion to an explicit loop
| repeatedly calling the function. Other popular approaches
| require either special runtime support for coroutines of
| some form, or a much more elaborate translation step
| within the compiler.
| yencabulator wrote:
| Plenty of people in the community considered dep way too
| messy to be the real solution.
| kiitos wrote:
| Fundamentally broken model of versioning, but I guess nobody
| really cares.
| jeremyloy_wt wrote:
| Can you elaborate on what problems you have with the MVS
| algorithm?
| nvarsj wrote:
| Not really a fan at all. Dep and its predecessors followed
| kiss principles, were easy to reason about, and had great
| support for vendoring.
|
| I've wasted so much time dealing with "module hell" in go,
| that I never dealt with in the prior years of go usage. I
| think it has some major flaws for external (outside Google)
| usage.
| LudwigNagasena wrote:
| > non-nilness
|
| Ah, I still remember this thread:
|
| https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
| p1necone wrote:
| Wow, that discussion is infuriating. I'm shocked that many
| people on there don't seem to understand the difference
| between compile time checks and runtime checks, or the very
| basics of type systems.
| skybrian wrote:
| I think people do understand the basics of static type
| systems, but disagree about which types are essential in a
| "system language" (whatever that is).
|
| An integer range is a very basic type, too, conceptually,
| but many languages don't support them in the type system.
| You get an unsigned int type if you're lucky.
| edflsafoiewq wrote:
| > An integer range is a very basic type, too
|
| Not really, its semantics get hairy almost instantly. Eg
| does it incrementing it produce a new range?
| randomdata wrote:
| The semantics are always complex. The same type of
| question arises for all basic types. For example, what
| does adding a string to an integer produce?
|
| Or do you give up on answering that and simply prevent
| adding strings and integers? When one wants to add them
| they can first manually apply an appropriate type
| conversion.
|
| That is certainly a valid way to address your question -
| i.e. don't allow incrementing said type. Force converting
| it to a type that supports incrementing, and then from
| that the developer can, if they so choose, convert it
| back to an appropriate range type, including the original
| range type if suitable.
|
| Of course, different languages will have different
| opinions about what is the "right" answer to these
| questions.
| noelwelsh wrote:
| I think you're confusing the type and value level.
|
| The original statement was about a range _type_ , that is
| something like an integer that is statically constrained
| to a range of, say, 1..4 (1, 2, 3, 4).
|
| To work with this _as a type_ you need to have type level
| operations, such as adding two ranges (which can yield a
| disjoint range!), adding elements to the range, and so
| on, which produce new types. These all have to work _on
| types_ , not on values. If 1..4 + 5..8 = 1..8 this has to
| happen at the type level, or, in other words, at compile-
| time.
|
| Range _types_ are very complicated types, compared to the
| types most people deal with.
|
| Converting a string to an int is very simple to type
| (String => Int if you ignore errors) and adding integers
| is also simple to type ((Int, Int) => Int)
| foldr wrote:
| OP is just saying that you don't have to permit
| operations such as addition or incrementation on range
| types, in which case you don't need the corresponding
| type-level operations.
| noelwelsh wrote:
| > That is certainly a valid way to address your question
| - i.e. don't allow incrementing said type. Force
| converting it to a type that supports incrementing, and
| then from that the developer can, if they so choose,
| convert it back to an appropriate range type, including
| the original range type if suitable.
|
| The quoted part above is an argument for dependent types.
| The conversion back to a range type creates a type that
| depends on a value, which is the essence of dependent
| typing.
| foldr wrote:
| No, I think the idea is that you'd get a runtime
| exception if the value was outside the range. No need for
| dependent types. It is no different conceptually from
| casting, say, a 64-bit integer to a 32-bit integer. If
| the value is outside the range for a 32-bit integer, then
| (depending on the language semantics) you either raise a
| runtime error, or the result is some kind of nonsense
| value. You do not need to introduce dependent types into
| your language to enable such casts (as long as you're
| willing to enforce the relevant checks only at runtime,
| or forego such checks altogether).
| noelwelsh wrote:
| I think the original comment is imprecise. E.g. "don't
| allow incrementing said type" can be read as either
| "don't allow incrementing _values_ of said type " or
| literally as don't allow incrementing the type. I can see
| both your and my interpretation, depending on how one
| chooses to read the comment.
| skybrian wrote:
| A range type could be very simple if it were just used
| for storage - you couldn't do anything with it other than
| passing it around and converting it to something else,
| and there would be a runtime check when creating it.
|
| But such a thing would be useful mostly for fields in
| data structures, and the runtime checks would add
| overhead. (Though, perhaps it would replace an array
| bounds check somewhere else?)
| dwattttt wrote:
| I regularly find quite smart people assume Rust's
| references must be fat pointers to handle lifetimes, and
| check them all at runtime.
| fooker wrote:
| > An integer range is a very basic type, too,
| conceptually
|
| Just signed vs unsigned makes this a complex topic.
| jrimbault wrote:
| It's like they don't speak the same languages.
| noelwelsh wrote:
| Many people on here as well! :-) Reading the comments on
| this post is stepping into an alternative universe from the
| PL crowd I usually interact with. Very conservative. It's
| quite interesting.
| thayne wrote:
| Wow, that's painful to read.
|
| Separating the concept of pointers and nullable types is one
| of the things that I think go having from the beginning would
| have made it a much better language. Generics and sum types
| are a couple of others.
| ahoka wrote:
| False things programmers believe:
|
| All reference types should be able to take a null value.
|
| It's impossible to write complex and performant programs
| without null.
|
| It's impossible to write complex and performant programs
| without pointers.
|
| References always hold a memory address in a linear address
| space. (Not even true in C!)
|
| Every type is comparable.
|
| Every type is printable.
|
| Every type should derive from the same common type.
|
| All primitive types should support all kind of arithmetic
| the language has operators for.
|
| The only way to extend an existing type is to inherit from
| it.
|
| What else?
| lnggahc wrote:
| > It's impossible to write complex and performant
| programs without null.
|
| Well, clearly there is a need for a special value that is
| not part of the set of legal values. Things like
| std::optional etc. are of course less performant.
|
| If I can dream, all of this would be solved by 72-bit
| CPUs, which would be the same as 64-bit CPUs, but the
| upper 8 bits can be used for garbage collection tags,
| sentinel values, option types etc.
| dwattttt wrote:
| > If I can dream, all of this would be solved by 72-bit
| CPUs, which would be the same as 64-bit CPUs, but the
| upper 8 bits can be used for garbage collection tags,
| sentinel values, option types etc.
|
| https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ch
| eri...
|
| Address space is 64bit, pointers are 128bit, and encode
| the region the pointer is allowed to dereference. And
| there's a secret 129th bit that doesn't live in the
| address space that gets flipped if the pointer is
| overwritten (unless it's an explicit instruction for
| changing a pointer)
| sapiogram wrote:
| > Well, clearly there is a need for a special value that
| is not part of the set of legal values.
|
| There's a neat trick available here: If you make zero an
| illegal value for the pointer itself, you can use zero as
| your "special value" for the std::optional wrapper, and
| the performance overhead goes away.
|
| This is exactly what Rust does, and as a result,
| Option<&T>, Option<Box<T>>, etc are _guaranteed_ to have
| zero overhead: https://doc.rust-
| lang.org/std/option/index.html#representati...
| pwdisswordfishz wrote:
| Every type must have some sort of a default value. (A
| generalization of the first item, really.)
| sirsinsalot wrote:
| Never met a programmer that thought these things were
| true.
| thayne wrote:
| A few of those myths are stated as fact in the
| aforementioned thread.
| bayindirh wrote:
| > It's impossible to write complex and performant
| programs without pointers.
|
| Well, I'd rather not copy around a multi-hundred-megabyte
| (or gigabyte) 3D object around to be able to poke its
| parts at will.
|
| I'll also rather not copy its parts millions of times a
| second.
|
| While not having pointers doesn't make impossible, it
| makes writing certain kinds of problems hard and
| cumbersome.
|
| Even programming languages which do not have pointers (
| _cough_ Java _cough_ ), carry pointers transparently
| prevent copying and performance hits.
| marcosdumay wrote:
| Well, looks like the GP missed a very common false fact:
|
| The operations written in a program must literally
| represent the operations the computer will execute.
|
| This one stops being true on high-level languages at the
| level of x86 assembly.
| bayindirh wrote:
| Exactly. A MOV is reduced to a register rename. An
| intelligent compiler can rewrite multiply/divide by 2 as
| shifts if it makes sense, etc.
|
| "Assembly is not a low level language" is my favorite
| take, and with microcode and all the magic inside the
| CPU, it becomes higher level at every iteration.
| twic wrote:
| It's going to be much faster to enumerate the true things
| programmers believe.
| dgb23 wrote:
| Without pointers in some form or another, you can't refer
| to allocated memory. You can change the name of pointers
| but they are still pointers.
| thayne wrote:
| It is possible to write complex and performant programs
| without allocating memory.
|
| And in some languages, where you only operate on values,
| and never worry about where something is stored,
| allocation is just an implementation detail.
| dgb23 wrote:
| > It is possible to write complex and performant programs
| without allocating memory.
|
| I assume you mean by only allocating on the stack? Those
| are still allocations. It's just someone else doing it
| for you.
|
| > And in some languages, where you only operate on
| values, and never worry about where something is stored,
| allocation is just an implementation detail.
|
| Again, that's someone else deciding what to allocate
| where and how to handle the pointers etc. Don't get me
| wrong, I very much appreciate FP, as long as I do
| information processing, but alot of programming doesn't
| deal in abstract values but in actual memory, for example
| functional programming language compilers.
| LudwigNagasena wrote:
| > Every type is printable.
|
| It's 2024, every type is jsonable!
| klabb3 wrote:
| > Wow, that's painful to read.
|
| And the dismissive tone of some people including Ian. But
| to be fair before Rust there was definitely this widespread
| myth in the dev hivemind that nullable pointers is just the
| cost of performance and low level control. What's
| fascinating is how easy and hindsight-obvious it was to rid
| code of them. I've never had to use pointers in Rust and
| I've worked on quite advanced stuff.
| lupire wrote:
| Nullable pointers are fine for those who need them. What
| we're asking for is non-nullable pointers.
| yencabulator wrote:
| Everyone just keeps repeating the same old gripe, without
| bothering to read the responses.
|
| Go needs a null-like thing because the language forces every
| type to have a zero value. To remove the concept of zero
| value from Go would be a major change.
| sharno wrote:
| I'm sure if Go had nullable types and/or sum types from the
| beginning, it's have been much more popular
| hu3 wrote:
| I'm sure of the opposite given the ideas behind Go's design.
| segfaltnh wrote:
| It's already quite popular. I'm less convinced there's a
| large pile of people wishing for a fairly high performance
| garbage collected language that are not using Go because of
| this. There just aren't many viable alternatives.
| ReleaseCandidat wrote:
| Java and C# being the obvious (and more performant)
| alternatives. And compared to them, Go already wins because
| of not being, well, "enterprisey". And with that I mean
| less the languages itself, but also the whole ecosystem
| around them.
| pjmlp wrote:
| Go's is already "enterprisey" enough, thanks to
| Kubernetes ecosystem.
| wordofx wrote:
| For the 3 people who actually need Kubernetes.
| valenterry wrote:
| There are definitely lots, I'm one of them. I use Scala,
| which is very powerful and imho much nicer language than
| golang. But the tooling and other support is slow and
| subpar. But I just can't go back to a brain-dead
| language(!) like golang because it hurts to program in such
| languages to me. So I hope that either golang catches up
| with Scala's features, or that Scala catches up with
| golangs tooling.
|
| And I think there are many similar people like me.
| foldr wrote:
| Perhaps, but other languages that look a lot like Go with
| these additions (e.g. OCaml) have not gained much popularity,
| despite getting much more love on forums like HN. It's
| important to remember that the people expressing strong
| opinions about sum types on the internet are a tiny and non-
| representative fraction of working programmers.
| lupire wrote:
| OCaml has a huge number of challenges besides "popular
| language plus sum types"
| lupire wrote:
| Go has nullable types! We want non-nullable types!
| chuckadams wrote:
| I blame C# for the confusion. Think of it this way: the
| ability to explicitly express a type Foo|null implies the
| existence of a non-nullable Foo as well. IOW it's shorthand
| for "nullable and non-nullable types".
| tapirl wrote:
| Don't forget that the semantic change of traditional 3-clause
| "for" loops: https://go101.org/blog/2024-03-01-for-loop-
| semantic-changes-...
|
| Because of this change, Go 1.22 is actually the first Go
| version which seriously breaks Go 1 compatibility, even if the
| Go official doesn't admit the fact.
| dgb23 wrote:
| Are there cases where people actually rely on the previous
| behavior?
|
| I always assumed that it was considered faulty to do so.
| rsc wrote:
| There were certainly buggy tests that relied on the old
| behavior. We didn't find any actual code that relied
| _correctly_ on the old behavior.
|
| https://go.dev/wiki/LoopvarExperiment
| dgb23 wrote:
| Love it, even though it must have been incredibly
| confusing when old tests failed at first. The assumption
| being that the tests were correct. They _passed_ all
| those months or years!
|
| I'm just also watching your YT video on testing and
| enjoying it very much!
| kiitos wrote:
| > since Go 1.22, every freshly-declared loop variable used in
| a for loop will be instantiated as a distinctive instance at
| the start of each iteration. In other words, it is per-
| iteration scoped now. So the values of the i and v loop
| variables used in the two new created goroutines are 1 2 and
| 3 4, respectively. (1+2) + (3+4) gives 10.
|
| I think you are assuming more guarantees than are actually
| guaranteed.
|
| You have a well-documented history of making incorrect claims
| about Go compiler and runtime behaviors, so this isn't
| surprising.
|
| > since Go 1.22, you should try to specify a Go language
| version for every Go source file
|
| What on Earth?? Absolutely 100% not.
| paride5745 wrote:
| I wish they would opt for ARC instead of a GC, to have a more
| deterministic memory objects lifecycle.
|
| Other than that, I agree with your comment.
| tschellenbach wrote:
| Thank you, amazing language :)
| throwawaygo wrote:
| I have so many disagreements on goals for the language with Russ,
| but have been a fan since his early days of writing the regex
| package and the c-to-go conversion code. Glad to hear he will
| still contribute to the lang, and hoping for a bit different
| direction from the new leads.
| tomcam wrote:
| IMHO Go has been one of the best-managed open source projects
| ever. Hats off to Google for supporting it.
| hoten wrote:
| What are some things that make it well managed?
| ein0p wrote:
| Almost zero drama and almost no feature creep or breaking
| changes. The team seems to have a focus, and does not change
| it easily. That is important for a programming language, and
| it doesn't happen organically.
| dom96 wrote:
| Zero drama is easy when you get paid (a lot) to work on
| something.
| muratsu wrote:
| Huhhh? Have you ever worked at a large enough company
| where stakeholder interests are not aligned?
| IshKebab wrote:
| That's private drama. For all we know there has been
| loads, but it's private so you can't see it.
| ncruces wrote:
| Where would you expect to see this drama unfold if it
| were private? Nowhere? That'd be incredible opsec.
|
| Code review happens in public, not on GitHub but on
| Gerrit. The main issue tracker is public, on GitHub.
| Proposals are largely handled on the issue tracker. There
| are public mailing lists, etc.
|
| Surely, there are face to face private meetings. And
| there are likely also private issue trackers, mailing
| lists, and etc. And, yes, sometimes, a seemingly
| arbitrary decision pops up, that was clearly discussed
| elsewhere.
|
| But these comments seem to come from people who never
| even tried to contribute, or deal with the process.
|
| I've done docs fixes as a total newb, had to convince the
| Windows maintainer to let me fix a Windows issue (that a
| year later produced flaky tests, which I fixed), made and
| got a proposal accepted, have a project in the linkname
| hall-of-shame, which led to another successful proposal
| to open up APIs (which then failed tests on some
| platforms, which I fixed).
|
| All with little drama, pure engineering.
| ein0p wrote:
| That's unfair. There's plenty of drama in projects with
| all sorts of funding situations. Look at eg Rust. Lots of
| drama and it's anyone's guess if the code you wrote a
| year ago would work today.
| lkirkwood wrote:
| > It's anyone's guess if the code you wrote a year ago
| would work today
|
| Is that true? In what sense? I was under the impression
| the editions took care of that.
| seeekr wrote:
| Not true, not sure why GP said that. Been writing Rust
| for many years and code does not just break on compiler
| upgrades. Super stable overall, including the wonderfully
| evolving ecosystem!
| sangnoir wrote:
| And yet we've had lots of drama in Linux and Redhat
| mailing lists, involving people paid to work on the
| respective projects, and using their work email.
| goalonetwo wrote:
| I would rather say that it is easy to have zero drama
| when most of the committers come from a single large
| companies.
| Maxatar wrote:
| Getting paid has nothing to do with drama. Plenty of high
| paid people get involved in drama and infighting across
| all walks of life including tech.
| segfaltnh wrote:
| Pretty sure Musk gets a decent paycheck, and manages to
| be involved in plenty of drama.
| richardwhiuk wrote:
| I suspect all the drama happens internally.
| zja wrote:
| Are there any Go team members that don't work for Google?
| It's a lot easier to remain civil/avoid drama when people
| know each other personally, and work together at a big
| company with an HR department.
| markkrj wrote:
| Does ex-googler counts? Then Filippo Valsorda...
| tomcam wrote:
| One reason I consider it so good
| sidewndr46 wrote:
| Absolutely inaccurate. Pointer de-reference operator had a
| breaking change after 1.x
| arp242 wrote:
| I don't recall this off-hand; which change was that?
| tweenagedream wrote:
| I mean they did say almost no breaking changes, depending
| how much has changed in the language, a small handful of
| breaking changes in niche use cases may be considered
| almost none by some. I'm not sure I would say the comment
| is absolutely inaccurate.
| vdqtp3 wrote:
| The cost being that they [generally speaking] ignore
| proposals, pull requests, and new features - even if they
| are valuable to their users and AREN'T breaking.
| segfaltnh wrote:
| Mostly this comes down to recognizing the value of
| simplicity. I like Rust and Go, but I am infinitely
| grateful that Go is as minimal as it is. I wouldn't have
| had as much success ramping my team on Rust.
| ahci8e wrote:
| Almost zero drama, yeah. I do remember the dep drama
| though...
| justinclift wrote:
| And the telemetry drama.
| gunapologist99 wrote:
| Exactly. And it's in writing!
|
| The backwards compatibility promise:
|
| https://go.dev/doc/go1compat
| Onavo wrote:
| They are the programming language equivalent of GitHub
| repos that maintain a low open issue count by closing most
| issues as "won't fix" or "won't build".
| lolinder wrote:
| Yes. And?
|
| Programming languages more than almost any other type of
| project end up swamped with thousands of competing
| requests to implement mutually incompatible features.
| Some languages do better than others at saying no, and
| those languages tend to be the ones that achieve
| widespread adoption.
| pansa2 wrote:
| > _Some languages do better than others at saying no, and
| those languages tend to be the ones that achieve
| widespread adoption._
|
| Unfortunately that's not at all true - Go is a real
| outlier here. If it were true, we'd all be writing C
| instead of C++, Lua instead of Python and ES5 instead of
| TypeScript.
| cookiengineer wrote:
| The choice is yours. Don't blame your choices on other
| people's opinion that you don't agree with. Everything in
| life is a tradeoff.
|
| If you don't agree with the available languages, make it
| better. That's the power of open source :)
| randomdata wrote:
| _> The choice is yours [pansa2]._
|
| Who gave him control over what sees widespread adoption?
| flohofwoe wrote:
| FWIW I switched from C++ to C about 7 years ago and never
| looked back (can't quite escape C++ completely though
| because some important libraries are still written in C++
| unfortunately). I vastly prefer TS to JS, Python and Lua
| though.
| pansa2 wrote:
| > _I switched from C++ to C about 7 years ago and never
| looked back_
|
| I'm definitely considering the same, and you're right -
| it's not C++ itself that appeals to me at all, it's the
| libraries. I'm not sure what C libraries I'd use for
| collections (instead of the STL and Abseil [0]), or in
| lieu of CLI11 [1] or Dear ImGui [2].
|
| [0] https://abseil.io/about/design/swisstables
|
| [1] https://github.com/CLIUtils/CLI11
|
| [2] https://github.com/ocornut/imgui
| hsaliak wrote:
| DearImgui's coding style is a good compromise.
| ein0p wrote:
| Good
| segfaltnh wrote:
| Yep. It takes a lot of bravery and I appreciate it!
| truncate wrote:
| Couldn't agree more. Always felt community had trust in the
| team. Its not the fanciest language, but whatever they push
| for usually works. In contrast, recently I've had to deal
| with Swift, and they are often pushing like 10 features,
| but each of them is full of holes and annoyances. Great
| respect for doing the boring of keeping it stupid and
| simple.
| moogly wrote:
| > almost zero drama
|
| Hm. Wasn't (the lack of) generics pretty drama filled?
| Especially the way they fought against it for so long.
| quectophoton wrote:
| s/fought against it/rejected superficial proposals that
| were mostly about syntax bikeshedding and didn't include
| enough research on how the proposal would play along with
| the rest of the language and ecosystem/
| tomcam wrote:
| Your question answers itself. It's growing in popularity in
| every year and has apparently suffered exactly zero scandals
| or embarrassing gaffes of any kind. Just not fucking up is
| _huge_ in making any serious enterprise successful and very,
| very difficult to achieve.
| treyd wrote:
| Just from the top of my head there's the Google proxy
| shenanigans and the telemetry proposal that they backed
| down from. There may be others I'm not aware of.
| kjksf wrote:
| Explain how Google proxy "shenanigans" are any different
| than "npm proxy shenanigans" or "cargo shenanigans" or
| "pip shenanigans". It's a service to improve Go ecosystem
| with anti-spoof security design (which can't be said
| about those other code download services).
|
| telemetry design is actually very thoughtful, limited and
| reasonable about what and how much data it sends.
| Motivation for sending the data is clear (improving Go).
| It's only a scandal for unreasonable people.
| cookiengineer wrote:
| The reluctancy to introduce new syntax too quickly (looking
| at you, TC39 and Babel) makes go an almost maintenance free
| language.
|
| If you learned idiomatic go, you can maintain and patch other
| libraries in the ecosystem very quickly.
|
| Unified codestyle, unified paradigms, unified toolchain.
|
| It's a language with harsh opinions on everything. If you
| manage to get over your own opinions, you'll realize that any
| opinion upstream is better than no opinion downstream.
|
| That's why go's toolchain isn't as messed up as npm, yarn,
| grunt, gulp, webpack, parcel, babel and other parts of the
| ecosystem that have no conventions and are therefore as a
| result very expensive to maintain.
| serial_dev wrote:
| This!
|
| In Go, a feature needs to have an extremely good reason to
| be added, and even then it's only added with care and
| caution.
|
| In other languages, pointless features are added because
| maintainers are afraid, or not empowered to say... "yeah,
| we get it, but no, we will not add cruft to the language
| because you can't write your own 2 line function to achieve
| the same, no matter how hard you dunk on us on Twitter,
| it's take it or leave it, but you won't tell us how to run
| this project"
| pansa2 wrote:
| > _pointless features are added because maintainers are
| afraid_
|
| I wouldn't have described language designers' feelings
| that way, but you're absolutely right. For example,
| witness the recent features added to Python with little
| more justification than "other languages have it". It's
| pure FOMO - _fear_ of missing out.
| Cthulhu_ wrote:
| "Other languages have it" is a disease that's struck many
| languages in the past decade+, notably Javascript which
| added partial OOP support (classes but initially no
| access modifiers), or Java which added functional
| programming constructs via Streams.
|
| I mean granted, Java needed some tweaks for developer
| ergonomics, and I'm glad they finally introduced value
| types for example, but I now find that adding entire
| paradigms to a language is a bad idea.
|
| In the case of Go, yes it needed generics, but in
| practice people don't use generics that often, so
| thankfully it won't affect most people's codebases that
| much. But there's people advocating for adding more
| functional programming paradigms and syntax like a
| function shorthand, which is really frowned upon by
| others, because new syntax and paradigms adding to the
| things you need to know and understand when reading Go.
|
| Plus at the moment / the way the language is designed, FP
| constructs do not have mechanical sympathy and are far
| slower than their iterative counterparts.
| vbsd wrote:
| Would you expand on the Python issue? I find recent
| Python additions either useful or non-intrusive, I wonder
| which ones you think are born out of FOMO.
| diggan wrote:
| Another example from another language: `class` added to
| JavaScript. Addition that was made to the language for
| something that already was possible, didn't add anything
| fundamentally new and added just because developers from
| other languages were more used to that particular syntax.
| klabb3 wrote:
| Yes about the language but also Google understands that
| both tooling and standard library is more important than
| the language. All of that makes Google internal
| maintenance much much better. Another artifact of google3
| was the absolute shitshow of GOPATH and abysmal
| dependency management - because Google didn't really need
| it, while people outside suffered. When they added go mod
| support Go became 10x more productive _outside_ of
| Google.
|
| Go is almost an anti-language in that sense, reluctantly
| accepting shiny lang features only after they've been
| proven to address major pain points. It's almost more an
| "infrastructure deployment toolkit" than a language.
| Which strangely makes it extremely pleasurable to work
| with, at least for network-centric applications.
| KronisLV wrote:
| With it being so consistent and predictable, I wonder why
| it hasn't displaced .NET and Java in the enterprise for
| back end development.
|
| Maybe because a framework like ASP.NET or Spring that
| covers like 80+% of the enterprise needs hasn't quite
| emerged? Or perhaps we just need to give it a decade or so.
|
| There are still very few Go jobs in my country, most are
| either .NET, Java or PHP.
| cookiengineer wrote:
| > ASP.NET or Spring
|
| (Disclaimer: I don't agree with HTMX rendering HTML
| chunks on the backend side, and I think that APIs should
| be HTTP-cacheable and use REST/JSON)
|
| Currently I am trying to get better at using Go with
| WebAssembly for the frontend. I love to use the
| webview/webview bindings to build local GUIs, but the
| need for redundant code in JavaScript for client data
| transfers and input data validation are annoying me a bit
| much.
|
| I am trying to find out a paradigm that could benefit
| from the strength of JSON marshalling, with the idea that
| you can map routes to structs, for example, and where a
| unified "Validate() (bool, error)" method as an interface
| is enough to use the same structs on both the frontend
| and backend, for both serialization and
| validation/sanitization.
|
| Having said that, I think that what's missing the most in
| go right now is a good UI framework for the web, but it's
| hard to find a paradigm that fits nicely into the
| language while also being able to handle dynamic
| data/refreshes/render loops without getting too bloated
| too quickly.
| wordofx wrote:
| > and I think that APIs should be HTTP-cacheable
|
| Rendering html on the server does not make it not
| cacheable.
|
| The vast majority of people do not need graphql or shift
| their compute to the client with a junk react app with
| adhoc json endpoints everywhere.
| KronisLV wrote:
| I think server side rendering can often be pretty
| comfortable to use!
|
| That said, I've also worked with JSF and PrimeFaces
| project and the ones I've seen have been more burdensome
| from a maintenance perspective and also more buggy than
| most SPAs that I've worked with.
|
| I've also seen large monoliths where the tight coupling
| slows updates down a whole bunch, as opposed to the
| presentation being in a SPA that's separate from an API
| that can be more limited in its scope (nothing wrong with
| using ASP.NET and Spring for just an API).
|
| Heck, I've migrated a SPA from the now defunct AngularJS
| to Vue and it felt better than having a legacy project
| that's stuck on an old version of Spring and PrimeFaces
| because there's so many moving parts that when you try to
| update anything, everything breaks.
|
| Plus, turning a SPA into a PWA is a fairly pleasant
| experience. I don't think most folks need GraphQL though,
| especially when we can barely do RESTful API correctly
| and not even all places use OpenAPI specs and tooling,
| making client code impossible to generate (even SOAP did
| a better job in that particular regard with how
| widespread WSDL was).
| trustno2 wrote:
| Go doesn't really lend itself that much into code with a
| lot of abstraction layers. If you try to do that, you
| will start to run against the language.
|
| The more enterprisey software usually have lots of layers
| for organizational reasons, and go doesn't really fit
| there. So I don't think it will really be a hit in the
| enterprise.
|
| yes there are orm solutions and DI frameworks and all
| that, but they always feel like they don't belong in the
| language.
|
| (Also, java and .net and php are much older and have much
| bigger enterprisey ecosystem.)
|
| I have seen go replacing the php stack though, and in
| some way the "original" python stack - but python now has
| ML.
| jen20 wrote:
| > usually have lots of layers for organizational reasons
|
| The ridiculous number of layers in Java or C# are more of
| a skill and guidance issue than anything else. Older
| languages don't always mean over-attempted-abstraction
| (think C, for example).
| pjmlp wrote:
| Never seen CORBA and COM written in C, I guess.
|
| Enterprise Architects will do their beloved architectures
| with whatever languages are the tool of the day.
| trustno2 wrote:
| I have worked in enterprises and the layers are usually
| an organizational issue that just acts as code issue.
|
| Structure of code often reflects structure of your
| company.
|
| The code is often maze of layers because the company is a
| maze of sub-committees. Java/C# fits more neatly in
| there.
|
| Although with Go, what can happen is that there is a maze
| of microservices. Maybe that's not that much better.
| Philip-J-Fry wrote:
| Go is displacing .NET where I work for backend
| development. We still use .NET for Windows GUIs but any
| sort of server code is mostly Go going forward.
| Cthulhu_ wrote:
| It's not yet an enterprise language; along the
| languages/frameworks, there's a huge ecosystem of QA,
| monitoring, security, etc solutions in the Java/.NET
| space that just isn't there in Go.
|
| I mean there's a slow shift, I keep hearing of "rewriting
| a Java codebase to Go", but it'll be a slow process. And
| especially the bigger projects that represent 30 years of
| Java development will and should be reluctant to start
| rewriting things.
| lifty wrote:
| In my enterprise neck of the woods Go is steadily taking
| over backend development.
| pjmlp wrote:
| Thankfully, it is enough that it is a must in DevOps
| space.
| _the_inflator wrote:
| Clutter death that creeps in any language, as I see it. To
| this day, only a small subset of JS syntax is used; I
| cannot recall anyone besides me ever using method chaining
| like .map .filter, etc.
|
| There is a reason why almost every good language is
| somewhat akin to C to this day, and maybe people started
| over to get rid of the noise.
| jessekv wrote:
| Haha interesting. I actually like .map/.filter/.find/etc.
| in JS and comprehensions in Python. I find they
| communicate the intent of the programmer really clearly
| as compared to a for-loop.
| matwood wrote:
| > I cannot recall anyone besides me ever using method
| chaining like .map .filter, etc.
|
| Interesting. That's all anyone on my team ever used once
| it became available.
|
| But, it highlights the point with Go. Working with Go for
| just a little while means I can easily read and work with
| nearly any Go project with a very short ramp up.
| lopkeny12ko wrote:
| > Unified codestyle
|
| The moment I got my first compile error due to an unused
| variable and an unused import, made me realize Go is not a
| serious programming language.
| tommica wrote:
| Why not? Pretty sure it's used in a lot of places, so it
| does seem quite serious if a language.
| Cthulhu_ wrote:
| I wonder who hurt them, that is, how much did unused
| variables/imports hurt at Google for them to make those a
| compiler error?
|
| Insofar I know it, I can imagine C/C++ caused some issues
| like that because it's hard to figure out whether an
| import is used, but an unused import does have a cost.
| foldr wrote:
| I think the fundamental reason behind this behavior is
| just Go's rejection of the concept of compiler warnings.
| Unused variables must either be A-ok or trigger an error.
| They chose the second option for unused variables. Some
| other code smells are considered A-ok by the compiler and
| need to be caught by linters.
| jen20 wrote:
| The problem with such rejection is that every serious
| project written in Go has invented compiler warnings
| outside the compiler, with linters.
| foldr wrote:
| Is this a problem? Linters are also used with lots of
| languages that do have compiler warnings. Go just removes
| the no man's land between honest-to-goodness compiler
| errors and linter warnings about code smells. I see no
| issue with having the latter handled entirely by tools
| designed for the job.
| kjksf wrote:
| Why is it a problem?
|
| `go vet` is part of Go toolchain so the designers very
| much understand and acknowledge that code can have issues
| that are not always errors.
|
| The distinction they made is very simple: an error is
| something that is always wrong and a vet warnings is
| something that is possibly wrong but not always.
|
| They made a judgement call to split the responsibility:
| compiler only reports errors, other tools, including `go
| vet`, can tell you about other issues.
|
| For example: passing a large struct by value to a
| function is potentially a performance problem but it's
| also correct code.
|
| If you ever tried to compile C++ code with different
| compilers you would know why it's a wise decision.
|
| The set of warnings is vast and not standardized so you
| take C++ source from project. It compiles for them but
| doesn't compile for you because you use different
| compiler or enabled different set of warnings. At which
| point you either try to get the other project to "fix"
| something that isn't an issue for them or you do stupid,
| pointless, time consuming work adjusting your build
| system.
|
| The same would happen in Go and it would be a reusability
| killer. You use some library in your program but it
| doesn't compile because you decided to use more strict
| set of flags.
|
| Lack of warnings switches also simplifies the toolchain.
| In go it's just `go build` and it works.
|
| In C++ you have to write some kind of makefile because
| everyone executes `cc` with different set of flags.
| rsc wrote:
| https://research.swtch.com/deps#watch_your_dependencies
|
| > Creeping dependencies can also affect the size of your
| project. During the development of Google's Sawzall--a
| JIT'ed logs processing language--the authors discovered
| at various times that the main interpreter binary
| contained not just Sawzall's JIT but also (unused)
| PostScript, Python, and JavaScript interpreters. Each
| time, the culprit turned out to be unused dependencies
| declared by some library Sawzall did depend on, combined
| with the fact that Google's build system eliminated any
| manual effort needed to start using a new dependency..
| This kind of error is the reason that the Go language
| makes importing an unused package a compile-time error.
| lioeters wrote:
| The moment you see that you had misspelled a variable
| name by a single character when the compiler warned you
| about an unused variable, you'll realize Go is a serious
| programming language.
| biomcgary wrote:
| This has saved me minutes of confusion so many times.
| classified wrote:
| Well, if you compare against the absolute bottom of the
| barrel, it's not too hard to look good.
| daghamm wrote:
| "That's why go's toolchain isn't as messed up as npm, yarn,
| grunt, ..."
|
| And let's be honest, Rust toolchain is pretty messed up
| too.
|
| Want to cross-compile with go? Set the GOOS variable and
| you are done. On Rust you need to curl-sh rustup, switch to
| nightly, add new targets, add target to your cargo and
| cross fingers it works this week.
| quectophoton wrote:
| To be fair, with Go it's still painful to work with
| private repositories. And I'm invoking Cunningham's Law
| here when I say there's no convenient way to do so.
|
| If you want to use a private repository (let's say it's a
| private GitHub repository), then you either have to do it
| the bad way (setting up your own GOPROXY and setting it
| up securely, which implies also ensuring it's not leaking
| your source code elsewhere for "analytics purposes"), or
| the worse way (doing brittle text replacement using weird
| git config stuff).
|
| Or the annoying way of using a vanity import, and host
| that package in your domain with HTTPS using a wildcard
| certificate. But that would require either (1) only
| allowing access through WireGuard and hoping whatever
| reverse proxy you use has a plugin for your DNS registry;
| or (2) letting your VPS provider terminate DNS (e.g.
| Hetzner load balancer), but filter by IP address in your
| VPS firewall settings ensuring your public address (IPV4
| /32 or IPV6 /64) is always up-to-date in the firewall.
|
| Or using `replace` in `go.mod`, but these don't work
| transitively so these only work on "root" projects (i.e.
| they are ignored in dependencies), so I don't think this
| really counts as a solution.
|
| I would have liked some way to force SSH access for a
| specific package, instead of HTTPS. Like for example
| `go.mod` supporting a `require-private` to use instead of
| `require` (or whatever similarly convenient directive for
| `go.mod` that implies authenticated SSH access is
| required).
|
| Or in other words, say I have a package
| `github.com/_company/project`, and it depends on
| `github.com/_company/dependency`. I want to be able to
| do: git clone
| 'git@github.com:_company/project.git' 'project'
| cd 'project' go mod tidy # Should just work.
|
| `go mod tidy` should just work without complaining about
| `github.com/_company/dependency` not existing (because
| it's a private repository only accessible through SSH).
|
| (EDIT: Still, I'm agreeing with the point that Go's
| tooling is better than most other things I've tried. My
| only complains are this one about being inconvenient to
| use private repositories, and also that by default it
| leaks package names to Google whenever you do `go mod
| tidy`.)
| hop_n_bop wrote:
| 1) git config --global
| url.ssh://git@github.com/.insteadOf https://github.com/
|
| 2) export GOPRIVATE='github.com/_company/*'
| quectophoton wrote:
| >> or the worse way (doing brittle text replacement using
| weird git config stuff).
| sapiogram wrote:
| Rust cross-compilation isn't great, but this seems a bit
| hyperbolic:
|
| > On Rust you need to curl-sh rustup
|
| Yes, but you do that once per computer, probably when you
| installed the compiler
|
| > switch to nightly,
|
| No
|
| > add new targets,
|
| Fair. But this is also one-time setup.
|
| >add target to your cargo
|
| Not sure what you're talking about here tbh
|
| > and cross fingers it works this week.
|
| Don't use the nightly compiler and you're good
| tentacleuno wrote:
| > The reluctancy to introduce new syntax too quickly
| (looking at you, TC39 and Babel) makes go an almost
| maintenance free language.
|
| Could you provide some examples of this? From knowledge of
| the pipeline operator proposal[0], moving fast and breaking
| things isn't always a priority.
|
| It goes without saying that Babel is an external collection
| of modules that don't fall under the TC39 umbrella, so
| they're able to iterate at a much greater cadence than the
| official specification (and you obviously need to
| explicitly opt-into using it.)
|
| [0]: https://github.com/tc39/proposal-pipeline-
| operator/commit/da... (first commit; Nov 9, 2015, which is
| 8 years, 8 months, 24 days ago)
| dzonga wrote:
| I think this is a side effect of golang having failed at the
| mission to replace C++ or even Java, becoming a replacement for
| ruby / python etc for API's. makes the project's goals align
| with users not about conquering the world anymore. as that
| battle is lost to Rust, Zig etc.
| bborud wrote:
| I thought the mission was to replace C++ for a _many_ things
| _at Google_. You can 't really lose to someone you are not
| competing with. The choice of managed memory is a pretty
| obvious hint that Go isn't a general direct competitor to
| C/C++.
|
| And neither Zig nor Rust have replaced C++ to any meaningful
| degree. Nearly everywhere it would count I still will have to
| deal with C++ for years, if not decades, to come.
| dgb23 wrote:
| Go is definitely used for stuff that rivals their Rust/C++
| etc. counterparts in terms of performance and general
| quality.
|
| Caddy and docker pop right into my mind. I've also seen
| databases, image processing and other nitty gritty systems
| programming related projects in Go.
|
| People also love to write CLI apps in Go that do a lot of
| heavy lifting like esbuild or k6 etc.
|
| The sweet spot for Go seems to be IO heavy programs. It
| allows for just enough control to get good performance for a
| lot of use cases that bleed into systems programming.
| jgowdy wrote:
| Yeah, only supporting glibc behaviors and ignoring the ELF
| standard at will really qualifies as best managed. /s
| rsc wrote:
| I replied to the other copy of this comment:
| https://news.ycombinator.com/item?id=41136122.
| nottorp wrote:
| I did mean to ask: who "owns" Go for all practical purposes?
|
| I suppose in theory it's some independent
| entity/commitee/whatever, but who pays the majority of the
| people working on it? Google?
| diggan wrote:
| > but who pays the majority of the people working on it?
| Google?
|
| Checking the 20 top contributors from
| https://github.com/golang/go/graphs/contributors
| Google: 10 Unclear: 7 Tailscale: 1
| Canopy Climate: 1 Isovalent: 1
|
| Just checking the GitHub profile and not doing any deeper
| digging, so take it with a grain of salt.
| purpleidea wrote:
| Huge news! I hope the new leadership remembers that keeping
| golang small and simple was its greatest strength. Adding
| generics was too much, and while I think there are some important
| small cases when it's valuable, in practice people are using it
| when they shouldn't. I'd also like to see less google control of
| the project.
|
| I'm certainly thankful for golang as it made my
| https://github.com/purpleidea/mgmt/ project possible!
|
| Thanks Russ!
| simonz05 wrote:
| > I'd also like to see less google control of the project.
|
| That doesn't look like is going to happen -- the leadership
| change announced here seems to me to continue on the Google
| path. Both Austin and Cherry are relatively unknown outside
| Google and are to my knowledge not active in the community
| outside Google.
| rsc wrote:
| > Both Austin and Cherry are relatively unknown outside
| Google and are to my knowledge not active in the community
| outside Google.
|
| I don't believe this is true at all. They are both highly
| active in external Go development, far more active than I
| have been these past few years. (It's true that neither gives
| talks or blogs as much as I do.)
| simonz05 wrote:
| I understand and respect your perspective on Austin and
| Cherry's involvement in the Go community. Their
| contributions may indeed be less visible but still
| impactful. However, the community's perception of
| leadership is crucial, and visibility plays a big part in
| that. For instance your long form blog adds context to
| decisions you've taken in the past. I hope their active
| roles will become more apparent, fostering a stronger
| connection with the broader Go community.
| arp242 wrote:
| > I'd also like to see less google control of the project.
|
| What does this even mean? Google basically just finances the
| project, but doesn't really "control" anything, never mind that
| "Google" isn't a monolithic entity in the first place.
| purpleidea wrote:
| They could be a non-google employee. They could let the
| community vote on who new leaders are, etc...
| arp242 wrote:
| > They could let the community vote on who new leaders are,
| etc...
|
| Who is "they"? Who is "the community"? Who qualifies for a
| vote and who doesn't? I never contributed any code to the
| Go compiler or stdlib, but have contributed to some aspects
| of the "wider ecosystem", including some things that see
| fairly broad usage, and am (coincidentally) wearing a 2018
| GopherCon t-shirt as I write this. Do I qualify? Does
| someone who has been writing Go for a year qualify? A week?
| Someone who never even wrote Go code? Someone who sent in a
| single patch to stdlib? And how do you verify all this?
|
| Saying "let the community vote" is easy, but if you think
| about it for more than a second you will realize there's
| tons of difficulties and that it doesn't really work. I
| also don't really know of any project that works like this:
| it's pretty always a fairly small group of "core
| contributors" that get to decide.
| tempest_ wrote:
| What do you mean it doesnt really work? There are a large
| number of programming languages and open source projects
| and a large number of approaches to this problem.
|
| Python, Postgres, Rust..
|
| A small amount of core contributors doesn't mean they all
| have to come from a single corporate entity either.
|
| The notion that only Google could shepherd a programming
| language is hilarious.
| arp242 wrote:
| > The notion that only Google could shepherd a
| programming language is hilarious.
|
| I never said anything of the sort. I said that "let the
| community vote on who new leaders are" doesn't work.
| Python, PostgreSQL, and Rust don't work like that either;
| it's just members of a fairly small "core team" that can
| vote, or some variant thereof. I have no inside knowledge
| here, but I'll stake a good amount of money that the Go
| core team had a lot of discussions about this, and de-
| facto, it's more or less the same as having a vote -
| except maybe a bit less formal.
|
| And Go would obviously be fine without Google, just as
| Rust was fine without Mozilla. But why bother? It's
| working fine as it is and Google wants to spend the money
| on developer salaries, so why not let them? People get
| far too hung up on "Google bad". I say this as someone
| who doesn't even have a Google account or Chrome
| installed.
| tempest_ wrote:
| I think Googles good will in recent years is the problem.
|
| I think Rust is better divorced from Mozilla, and Go
| would be better if it was divorced a bit from Google for
| a lot of the same reasons.
| arp242 wrote:
| > I think Googles good will in recent years is the
| problem.
|
| I don't really follow what you mean with that.
|
| People keep going on that Big Tech needs to invest more
| in open source projects and maintainership. "But no, not
| like that!" Hmkay...
|
| In the end, the people doing the work get to decide.
| That's how it works everywhere. Go originated at Google
| and many (though far from all) of the core people working
| on it are still paid by Google. The people doing the work
| seem to have no problem with this relationship, so
| standing on the sidelines shouting "no no, do the work
| differently!" is not really brilliant IMO.
|
| And as I said, I don't see Google "controlling" anything.
| What does that even mean? Larry Page deciding what
| happens in the next Go release or something?
| bborud wrote:
| It is tempting to look at the election in the US and ask
| what will determine the outcome - who has the policies that
| will make peoples lives better or who can come up with the
| most effecive derogatory nickname for the opponent and
| stoke the most fear.
|
| I've worked at Google, I've used Go for about 8 years at
| this point and I've met a few of the key Go figures at some
| point. I have to say that I have _no_ idea who would be
| best to run the project. And neither do you.
|
| This isn't politics where the winner gets to vanquish their
| enemies and make themselves and their friends and family
| rich. It's developing and maintaining a programming
| language. The only real reward you'll get is admiration IFF
| you do a good job. Do a crap job and you ruin the project
| and/or become a pariah.
|
| I would rather have those people who make up the core
| leadership tell me who should run the project since they
| not only know the technology, but they know the people and
| they know how to provide continuity. Continuity and
| discipline is all-important.
|
| I'd prefer it if whoever runs the project works for Google
| since that is where Go was born. In part for continuity
| reasons and that Google has proven to be a very good home
| for Go, but also because it is good to have direct access
| to an organization that has resources to support you.
| dblohm7 wrote:
| > Adding generics was too much
|
| I strongly disagree. Sure, like anything in programming,
| generics can be misused. But even comments can be misused!
|
| OTOH I am able to build things in Go with generics that I would
| not be very happy building without them.
| nasretdinov wrote:
| Yeah I agree. Due to Go's slow moving approach we'll see the
| biggest impact of generics much later, when they become more
| prominent in the standard library. A lot of those APIs are
| necessarily not type safe now and generics would close that
| gap quite nicely
| gary_0 wrote:
| The thing people dislike, I think, is that actually
| implementing generics and handling all the syntactical and
| compilation edge cases is complicated and ugly.
|
| But generics as a high-level concept are wonderfully simple
| and useful ("let me use different types with certain code
| constructs without having to manually duplicate them, and
| stop me from doing anything that doesn't make sense"). It
| would be a far easier call for languages to add them if they
| were just a bit of syntactic sugar instead of a whole new
| section in the manual. (I do think adding generics was a good
| call; practicality trumps a fussily clean design, in my
| book.)
| jen20 wrote:
| > But even comments can be misused!
|
| And arguably are in Go, where they are used for all kinds of
| things that are not inline documentation!
| fuzztester wrote:
| examples of that? code generation? been away from go for a
| while, after using it some earlier, so not up to date
| p1necone wrote:
| > Adding generics was too much, and while I think there are
| some important small cases when it's valuable, in practice
| people are using it when they shouldn't.
|
| Strongly disagree. Beyond very simple codebases lack of
| generics means either duplicating a bunch of code or eschewing
| type safety - neither of those things are particularly
| attractive to me. I can't imagine writing code in a strongly
| typed language that doesn't have support for generics.
|
| Even if _you_ don 't use them directly it's almost certain
| you're using libraries that would be forced to be less
| ergonomic or type safe because of a lack of generics.
| akira2501 wrote:
| > or eschewing type safety
|
| Type casts are checked.
|
| > that doesn't have support for generics.
|
| We get first class functions and compiled closures with zero
| syntax overhead. It's entirely manageable.
|
| > or type safe because of a lack of generics.
|
| Case in point: sort.Slice(). It lacks ergonomics, otherwise,
| entirely usable.
|
| That being said, the generic version is faster and easier to
| use, so they are not without purpose, but they're not
| fundamental to large scale design either. Used without
| caution they can become a burden in and of themselves.
|
| I like them just fine, but I could completely live without
| them.
| zarzavat wrote:
| BTW this kind of thing is why I don't use Go.
|
| Generics are a basic language feature for a statically
| typed language. Go needs a lot more features to be usable,
| like better error handling, but the ultra-conservative
| community that opposes any changes is a drag on the
| language and makes developing in it a miserable experience.
| akira2501 wrote:
| > needs a lot more features to be usable
|
| I guess what I'm caught up on is the idea of "usable" is
| entirely subjective. To my eyes and fingers, Go has been
| fine without generics, and since their addition I've only
| used them once to clean up an odd bit of code around
| instantiating "module" like initializers.
|
| > and makes developing in it a miserable experience.
|
| Subjective or not I find this a bit harsh. I spent years
| in an environment where C was the only option that could
| be used and Go is a complete dream compared to this. You
| may dislike the environments, you may find fault with
| them, but there are many examples of both of them being
| used to build large and complex systems that aren't
| completely "miserable" to work on.
|
| I wonder if the split is something like "batteries must
| be included." I don't feel this way. I'm content to mine
| up Zinc and Copper and forge my own batteries if needed.
| I'm not at all put out by this.
| lenkite wrote:
| Please search/replace all `map[x][y]` in your Go projects
| with `map[sting]interface{}` in order to be honest and
| consistent with your opinion. And explain to all your
| stakeholders that you have done so because generics is
| bad.
|
| You have been using a generic data-structure since Go 1.0
| but did not realize this.
| akira2501 wrote:
| > in order to be honest and consistent with your opinion
|
| Did you mean replace `map[string]string` with
| `map[string]interface{}`? You should take a look at Go's
| runtime map code. This is not a "generic" data structure.
| It's an unsafe data structure with some thin compiler
| sugar on top of it which is also something worth taking a
| look at.
|
| For example see how it handles something like `m["x"]`
| versus `m[12]` or a map using structs as keys. Put it in
| Godbolt then chase down the various runtime
| implementations you encounter. Unless I'm
| misunderstanding you, then I apologize, but what else did
| you mean?
|
| > explain to all your stakeholders that you have done so
| because generics is bad.
|
| I also write code based upon engineering principles and
| not on the difficulty of explaining it to my peers or
| customers. I'm more concerned with the results they
| experience when they use the software.
|
| > generic data-structure
|
| What we call "go generics" has nothing to do with "typed
| go maps." To the extent that I've needed something
| "generic" up until they were formally introduced into the
| language careful interface design was enough to cover 90%
| of use cases. For the ones that weren't a map holding a
| function which wrapped a type-checked cast operation did
| the rest.
|
| So all we're left with is the ability for the current go
| generics to automatically populate functions into your
| compiled image based upon instantiated and optionally
| constrained type usage rather than some explicit and
| planned mechanism implemented through interface.
| lenkite wrote:
| Apologies for the stupid typo. Anyways, I think we will
| need to simply agree to disagree because of this
| statement:
|
| > I also write code based upon engineering principles and
| not on the difficulty of explaining it to my peers or
| customers.
|
| I believe that difficulty of explaining code to "my peers
| or customers" is a _basic_ engineering principle.
|
| Also, I consider what the compiler does behind the scenes
| as irrelevant as long as you have reasonable performance
| and usability qualities. That's one of the fundamental
| principles of abstraction after all.
|
| Btw, the inventor of the C programming language also said
| this. Dennis Ritchie -> "Code should be written for
| humans first, machines second"
| rob74 wrote:
| Interesting that they write "I don't use Go" but are
| still convinced that "developing in it [is] a miserable
| experience". So, which one is it now? I think many people
| would be positively surprised if they tried Go
| approaching it with an open mind, but all the FUD spread
| on HN and similar forums prevents that...
| trustno2 wrote:
| error handling is what I like about go.
|
| ok errors.As is a little stupid, I'll give you that. But
| that's all.
| illusive4080 wrote:
| This is why I prefer Rust over Go. Go is far too simple.
| skywhopper wrote:
| Russ has done a great job of shepherding Go through over a decade
| of growth and maturity and has led a ton of fantastic additions
| to the language and built a strong pattern of excellence in how
| language changes are considered and made that should serve as a
| shining example for the future of Go as well as any other
| language out there.
|
| And now he's continuing the stretch of outstanding leadership by
| passing the torch. I can wait to see what the next 12 years of Go
| brings. Thanks for your service, Russ!
| shoggouth wrote:
| Thanks for working to create such a great language!
| rollulus wrote:
| Since rsc frequents HN: I'd like to thank you for all the work
| you've put into this great language. Peak HN hype cycle I decided
| to pick up Go and never regretted it. Thank you.
| simonz05 wrote:
| https://www.youtube.com/watch?v=wwoWei-GAPo -- Project has come a
| long way since this. Happy that it's still around and thriving. I
| don't think we expected that in 2009. I don't believe Go would
| have been where it is without Russ. His contribution to the
| project has been tremendous.
|
| Thanks Russ.
| meling wrote:
| Thanks Russ for your great leadership and contributions to the Go
| community. I've always enjoy your talks, blogs, and your many
| contributions to the language. Looking forward to your future
| contributions to the language and ecosystem.
| Thaxll wrote:
| RSC has a really good blog: https://research.swtch.com/
| jjice wrote:
| Incredible blog. I've said it on this site before, but his
| series on regular expressions is insanely high quality and the
| fact he just posted it there for all of us is a huge privilege.
| mikhailfranco wrote:
| Yes, I certainly benefitted very much from the series.
|
| Here is the first episode - devastating, convincing, easy to
| understand and very well written:
|
| https://swtch.com/~rsc/regexp/regexp1.html
| furyofantares wrote:
| This is the first time I'm noticing that rsc would be an
| initialism for the blog.
| rsc wrote:
| Me too!
| furyofantares wrote:
| :)
|
| While you're still reading these, I want to say that while
| I've never ended up using Go for any shipping projects,
| I've been a fan since day 1. And it hasn't been lost on me
| that in the languages and ecosystems I do use in my
| professional life, good decisions from Go have propagated
| through the software world.
|
| One thing that really sticks in my brain is gofmt; it makes
| it clear that there's still relatively low-hanging fruit
| where you can make a really good decision that spreads to
| the rest of the world on merits alone. It's an inspiration.
| dondraper36 wrote:
| rsc, thank you very much for all the hard work on the language
| that brought me into software engineering.
|
| Despite playing around with several programming languages, Go
| still feels like home.
|
| The development experience is terrific and I really appreciate
| how unapologetically simple and responsible the language and its
| creators have been.
|
| Good luck and all the best in all your endeavours!
| rsc wrote:
| > rsc, thank you very much for all the hard work on the
| language that brought me into software engineering.
|
| You're quite welcome, and thank you for this comment. I never
| expected when we started that Go would have such a positive
| impact on people's lives, bringing new people into programming
| and software engineering. That's definitely the impact I'm most
| proud of.
| geoka9 wrote:
| Thank you guys from another fan! Go literally saved my career
| as a software dev: got burned out around 2014, tried Go as
| therapy and have been a happy gopher ever since :)
| captainkrtek wrote:
| Same sentiment as the above poster. I've been working with Go
| since 2014, after using many languages before, and none match
| the ease and efficiency of development for my work. Thank you
| so much!
| apitman wrote:
| I've been programming for 20 years and Go has proven to have
| more gravity than any other language I've used. When I just
| need to get something done, it's what I reach for. Thank you
| for your part in building such a useful tool.
| slekker wrote:
| Thank you very much rsc! Golang not only helps me feed my
| family but also I created many friendships from using it :)
| xh-dude wrote:
| Thanks for helping the OEIS site stay alive. I was absolutely
| delighted by it the first time I visited it, decades ago.
| Equally delighted when I visited recently and saw some "Russ
| Cox" contributed.
| igmor wrote:
| Go team has built a remarkable tool under your leadership. A tool
| that moved a niddle to the better side of things for the
| industry. Thank you and God speed!
| septune wrote:
| Thanks Russ and infinite kudos to you
| mseepgood wrote:
| Please make more Ivy videos
| remus wrote:
| I think you might be thinking of Rob Pike's project, unless
| Russ has been involved?
|
| https://github.com/robpike/ivy
| bear8642 wrote:
| Russ has indeed been involved, he's done various videos
| solving advent of code using Ivy.
|
| Russ has also got a pull request to add an operator, see
| https://github.com/robpike/ivy/pull/83
| rsc wrote:
| https://www.youtube.com/watch?v=ek1yjc9sSag&list=PLrwpzH1_9u.
| ..
|
| I don't intend to make more of those, but that was a lot of
| fun.
| xyst wrote:
| I think the only reason I used go at some point was because of
| Russ Cox. Have joined the dark side and switched to rust ;).
|
| Wonder what he's going to do next? Maybe just moving around
| within G? or another OSS project within G?
| dochtman wrote:
| The post actually contains some references to what he's working
| on next, some kind of LLM agent to facilitate software
| development processes?
| nasretdinov wrote:
| Russ gave us proper vendoring and generics: two things I thought
| I'd never see in Go... Thanks a lot for the effort!
| bruckie wrote:
| Ian Lance Taylor did a lot of the work on generics, too. Thanks
| to both, and the rest of the team!
| valyala wrote:
| While vendoring is great, generics is bad addition to Go, since
| they complicated Go type system too much [1]. This makes
| typical Go code with generics hard to read and hard to
| maintain.
|
| [1] https://go.dev/blog/type-inference
| hgyjnbdet wrote:
| Out of interest, why are people so confident in Google when it
| comes to Go, yet every other day there's articles about how
| Google can't be trusted in related to Dart/Flutter which are soon
| to be abandoned?
| bufo wrote:
| Because Go has massive traction both inside and outside of
| Google, whereas Dart/Flutter never got big traction.
| surajrmal wrote:
| Dart only found a real good use case fairly recently. Given
| its explosion in usage since then, I think it may very well
| be more popular that go in several years.
| smithcoin wrote:
| Curious- what is the use case?
| hgyjnbdet wrote:
| I think they mean Flutter, and Darts truly cross platform
| abilities.
| nu11ptr wrote:
| > Google can't be trusted in related to Dart/Flutter which are
| soon to be abandoned
|
| source?
| hgyjnbdet wrote:
| I'm not agreeing with that assessment but recently:
|
| https://news.ycombinator.com/item?id=40997745
|
| https://news.ycombinator.com/item?id=40184763
|
| Among others. Again I'm not saying I agree, I'm just saying
| you don't see the same with Go.
| patmorgan23 wrote:
| Off the top of your head, name 3 projects/apps that use
| Dart/Flutter, now do the same for go.
| bitpush wrote:
| If you cant name 3 projects/app that use Dart/Flutter that
| just shows your bias.
|
| Can you name 3 apps/projects that use COBOL?
|
| -- This is akin to asking, "Quick, name 3 books written in
| Persian. Huh, you cant name them? Must be a dead language"
| randomdata wrote:
| _> Can you name 3 apps /projects that use COBOL?_
|
| Does this imply that you see COBOL as having a
| trustworthy future, making it a great choice for a new
| greenfield application?
| fuzztester wrote:
| the part of your sentence before the comma is not fully
| related to the part after it.
|
| iow, the first part does not imply the second part.
|
| a lang could have a trustworthy future for maintenance of
| existing apps, like in terms of support from vendors,
| while not being a very good choice for greenfield
| applications, due to not having modern language features
| and libraries.
|
| but there is so much cobol in critical infrastructure in
| the world that I don't think it is going away anytime
| soon. Google for some relevant threads on hn about it.
|
| there is a good chance that some services critically
| important to you and your family rely on software written
| in COBOL running on mainframes. just like for everyone
| else in the developed world and some of the developing
| world.
| LVB wrote:
| There are probably more Flutter apps about than you'd
| think, and at least on Android you can look for yourself:
| https://x.com/kevmoo/status/1819112503722627286
| arp242 wrote:
| I don't really know anything about Dart or Flutter, but they're
| entirely separate teams within a huge organisation. It's
| entirely possible that one team does an excellent job, whereas
| the other doesn't. I keep repeating this: but "Google" is not a
| monolithic entity. People aren't "confident in Google", they're
| "confident in the people working on Go" (or not: you can decide
| that for yourself).
| tedunangst wrote:
| At any point in recent history, I would have been pretty happy
| sticking with the last release of go for quite some time.
| Flutter always feels like it's the next release that's going to
| be the good one.
| euroderf wrote:
| I get an early-UNIX / Bell-Labs vibe from the entire Go
| project. New Jersey all the way. The ecosystem is too sleek and
| practical to abandon. My 0.02EUR, ymmv.
| fuzztester wrote:
| >New Jersey all the way
|
| New Jersey vs. what? I read about that phrase sometime
| earlier but forgot the rest of it. Is it vs. MIT / Stanford /
| West Coast / other? implying worse is better vs. other?
|
| is it also related to neat vs. scruffy approaches in AI?
|
| too much in tech to keep track of it all.
|
| but asking out of interest.
| quectophoton wrote:
| I don't trust Google.
|
| I trust specs[1], multiple implementations[2], and how easy it
| is to bootstrap a compiler[3].
|
| [1]: https://go.dev/ref/spec
|
| [2]: https://gcc.gnu.org/onlinedocs/gccgo/ (even if feature
| parity isn't quite there yet)
|
| [3]: Instead of requiring double-digits compilation steps that
| each take too long to be reasonable.
| declan_roberts wrote:
| There are features of the Go toolchain that I consider to be a
| _requirement_ in all future languages.
|
| For example, if a language doesn't come with a built-in formatter
| that's a huge red flag. Go broke the tyranny of style
| discussions.
|
| Easy static binaries is right up there for all new languages.
|
| Kudos to rsc and team for all the work that went into making a
| great language. Good luck on your next projects.
| alphazard wrote:
| > I don't believe that the "BDFL" (benevolent dictator for life)
| model is healthy for a person or a project
|
| It's interesting that the best projects have BDFLs, and that the
| best BDFLs are skeptical of their own power.
| groby_b wrote:
| The only people worth having in power are the ones that don't
| want the power.
|
| This extends well beyond OSS projects.
| darby_nine wrote:
| I don't think this is true. Python had a BDFL and it didn't
| seem to benefit much from it. I'm not sure what other projects
| this attitude draws from. Off-hand I'd guess it causes less
| drama but no appreciable increase of quality, just like other
| forms of bureaucracy.
|
| Meanwhile there's entire landfills of failed projects with
| single owners who couldn't bend enough. We just don't find this
| worth discussing.
|
| Of course this won't happen, but a man can dream.
| anamexis wrote:
| Linux/Linus Torvalds stands out as another notable BDFL.
| gunapologist99 wrote:
| And Daniel Robbins at Gentoo, who recently (and sadly)
| stepped down from Funtoo as well.
| darby_nine wrote:
| I'm not intimate with Linux as a project, but this is an
| attractive argument for it. Unfortunately my main
| experiences with Torvalds are motivated by his chewing out
| people on mailing lists for something stupid they said
| rather than fending off varied interests, which makes him
| look far more petty than competent.
| arp242 wrote:
| Only those instances make the news. And then get repeated
| time and time again. It's a super-biased view not at all
| representative of his day-to-day behaviour.
|
| Also I've never seen Torvalds "chewing out people on
| mailing lists for something stupid they said", it's
| always been someone breaking something or something along
| those lines. That is: _doing_ stupid. And it 's also
| experienced maintainers Torvalds feels should have know
| better.
|
| You can like or dislike Torvalds' style, but this little
| student from Finland created the world's most successful
| open source project, so I think he's probably doing one
| or two things right.
|
| He may not be perfect, but being hung up over a few
| incidents over a 30-year time period is perhaps not too
| brilliant, and insinuating incompetence over this is
| quite the take. Imagine every outburst you have is public
| and pointed to for years to come.
| rectang wrote:
| Torvalds also listened, learned and improved. If we want
| people to respond to constructive criticism
| constructively, it's uncharitable and counterproductive
| to pigeonhole them as they were at a point in time.
| Capricorn2481 wrote:
| > it's always been someone breaking something or
| something along those lines
|
| Not only is this a complete lie, but God forbid there's a
| process in place to catch these things instead of
| verbally abusing your coworkers for making mistakes,
| which Linus has done himself.
|
| > Imagine every outburst you have is public and pointed
| to for years to come
|
| You may be surprised to learn that the rest of us don't
| talk to anyone like this.
|
| > but being hung up over a few incidents over a 30-year
| time period
|
| That's a great way to make it sound old but he actually
| gets angrier as time goes on. https://lkml.iu.edu/hyperma
| il/linux/kernel/1510.3/02866.html
| lakdna wrote:
| > You may be surprised to learn that the rest of us don't
| talk to anyone like this.
|
| The moral superiority is misplaced:
|
| https://news.ycombinator.com/item?id=41017195
|
| But I am not surprised. CoC proponents universally do the
| same as the people they criticize. Only the application
| of rules is selective.
| arp242 wrote:
| > You may be surprised to learn that the rest of us don't
| talk to anyone like this.
|
| You do. By outright claiming that I'm lying when I share
| what I've seen. Of course with no substance to back it
| up. Let me tell you: I've seen what I've seen. Have I
| seen an incomplete picture? Almost certainly. Am I wrong?
| Perhaps. Am I lying? No. Your post is extremely
| aggressive, pretty darn toxic, and explicitly the sort of
| stuff that's not appropriate here.
|
| Do better next time. Doubly so if you want to get all
| high and mighty.
| kfgahs wrote:
| Linux started on Usenet, and that was the normal
| communication style. People simply did not take it
| seriously back then, it was understood to be partly
| humorous.
|
| Linus doesn't even rant frequently either. People point
| to the same 10 messages over and over again.
|
| He also tolerates when someone snaps back at him, unlike
| in projects with double standards like CPython where the
| old boys can do whatever they like but you are not
| allowed to criticize back or point out their numerous
| mistakes, segfaults, threading bugs and generally low
| code quality.
| SatvikBeri wrote:
| Here are some other projects that benefited from BDFLs in my
| opinion:
|
| * Keras
|
| * Ruby
|
| * Clojure
|
| * Zig
|
| * OCaml
|
| * Vim
|
| * Elixir
|
| I think all of these have ended up being unusually coherent.
| I may not agree with their design philosophy, but there
| clearly is one.
| dash2 wrote:
| Conversely, projects without clear leadership include rust
| (recently) and R, and I think they suffer for it.
|
| A very widespread system for organising people is to have a
| single responsible decision-maker, supported, monitored and
| advised by a committee. We see that through politics and
| business, and a lot of the best open source projects seem
| to do the same thing.
| gpderetta wrote:
| IMO C++ would have benefitted from having a BDFL for a
| bit longer as well.
| kovac wrote:
| Linux, OpenBSD? Perhaps to an extent Mutt too.
| giraffe_lady wrote:
| But php, one of the most notoriously chaotic mainstream
| languages, has a bdfl. And lua, arguably more disciplined
| than all of the ones you listed, has not.
| hermanradtke wrote:
| Rasmus is not the BFDL for PHP.
| chuckadams wrote:
| PHP is governed by an RFC process requiring a 2/3
| majority vote of a couple dozen core devs. This has been
| the case for nearly 20 years now. Rasmus rarely even
| votes these days.
| dgb23 wrote:
| A perhaps important clarification:
|
| Many of those, including Linux as far as I know, simply
| started as projects that were driven by single authors with
| a strong vision and remarkable diligence.
|
| Then people flocked to those projects, but with the
| understanding and appreciation of that vision.
|
| I don't think any of them wanted to be BDFLs for the sake
| of power. They were the original authors and _made_
| something useful. I don't think any of them took over an
| existing project and declared themselves dictators.
| Ironically they all would be way too opinionated to do so.
| vbezhenar wrote:
| Python became #1 language in the world. Which factors lead to
| this success is debatable, but leadership role can't be
| dismissed.
| carapace wrote:
| The whole idea is a joke, it's right there in the name. It was
| a recognition of the "facts on the ground" of GvR's role as the
| creator of Python, it was never seriously meant as a principle
| of project management. It's descriptive not prescriptive, eh?
| The idea got reified all out of hand.
| rsc wrote:
| The wording may be a joke but the concept is real and widely
| used.
| saghm wrote:
| Without taking a stand on the first half of that, I don't think
| it's particularly surprising that the best BDFLs are skeptical
| of their power. I'd argue the main benefit of having a single
| person with the power to make a unilateral decision is that it
| provides a way around the gridlock that tends to occur whenever
| there are a wide variety of stakeholders involved;. a project
| whose leader feels warranted to overrule decisions that have a
| strong consensus is a lot less likely to build up a community
| to the point that anyone is aware of the project.
| knighthack wrote:
| I've noticed: competent people who _aren 't_ interested in
| leadership tend to make the best leaders.
|
| As compared to people who _want_ to be leaders, for the sake of
| being known as a 'leader', but have neither the competency nor
| accountability to be leaders.
| singron wrote:
| As long as they aren't so disinterested that they become
| absentee leaders. It's rare for huge successful projects
| you've heard of, but I think the typical project is more
| likely to have this problem, although maybe it's just
| incompetence too.
| zanellato19 wrote:
| I've seen this sentiment repeated here and I completely
| disagree.
|
| The best leaders are interested in being leaders for the
| betterment of their team/community, not for the clout. But
| people who are pushed to be leaders without being interested
| in that, they tend to suck and make life miserable for
| everyone else. Leadership is a skill, if you treat it
| differently, you will suck at it.
| riwsky wrote:
| Remember when they tried to king George Washington?
| zmj wrote:
| Thanks Russ! Putting tooling on a first-class basis was
| revolutionary, and it's still Go's standout feature.
| klartd wrote:
| Thanks for all the Go contributions!
|
| I disagree on one point that has nothing to do with Go. Python
| has not benefitted from GvR stepping down. The new "leadership"
| is non-technical, tyrannical and has driven almost all true open
| source contributors away.
|
| Development has stalled except for the few corporate
| contributions of doubtful quality. The atmosphere is repressive
| and all that matters is whether you have a position of power at
| Microsoft/Instagram/Bloomberg.
|
| It is not necessarily the fault of these companies. They may not
| know that their generosity is being abused.
| the_duke wrote:
| > Development has stalled except for the few corporate
| contributions of doubtful quality.
|
| Do you have some data to back that up?
|
| The stats on Github seem to show healthy activity. 700+ merged
| PRs from 120+ contributors in the last month [1].
|
| There seems to have been a big influx of new contributors in
| the last few years. [2]
|
| [1] https://github.com/python/cpython/pulse/monthly
|
| [2] https://github.com/python/cpython/graphs/contributors
| DLA wrote:
| Russ thank you so very much for your outstanding leadership,
| dedication, design wisdom, and technical contributions to Go.
| This language, its libraries and tools, and especially the Go
| community are incredible. You are a class act sir!
| 999900000999 wrote:
| Thank you.
|
| Golang is easily one of my favorite new languages. It's fast and
| clean without the difficulty of Rust. I was able to create a
| small mobile app with Chat GPT without any real experience in
| Golang.
|
| I would like better mobile and gaming frameworks though. Although
| I really like Flutter, I think Google missed a major opportunity
| to use Golang instead of Dart.
|
| What's next? Any good for native Chrome support?
| 38 wrote:
| > I was able to create a small mobile app with Chat GPT without
| any real experience in Golang.
|
| so you didn't really create it then did you? ChatGpt created it
| for you.
| 999900000999 wrote:
| I'm shameless when using Chat GPT to assist with personal
| projects.
|
| It's just another tool.
| 38 wrote:
| right but at this point you're not even using your brain
| anymore, so you really dont have any place in a discussion
| about programming languages.
| 999900000999 wrote:
| I'll put it this way, the same doesn't apply with Rust.
|
| I don't feel ashamed that I didn't manually come up with
| sorting algorithms. I was able to make a small Golang
| project and I had fun.
| fuzztester wrote:
| >I was able to create a small mobile app with Chat GPT without
| any real experience in Golang.
|
| >I would like better mobile and gaming frameworks though
|
| er, try asking chatgpt to create them for you.
| wejick wrote:
| Thanks RSC, since the past 8 years I really enjoyed working with
| Go. It's my first experience following a programming language
| development, all the proposals, debates and how all of them were
| handled.
| amiga386 wrote:
| thanksStr := "thank you rsc" ret, err :=
| sayThanks(thanksStr) if err != nil { return
| nil, err } return ret, nil
| cocok wrote:
| Can anyone familiar with Go explain why not
| return sayThanks(thanksStr)
|
| I've seen this "if err != nil" pattern before, but I can't help
| thinking that it's not necessary.
|
| "return ret, nil" ignores err's value, which is nil anyway.
|
| "return nil, err" ignores ret's value, but why? If the caller
| checks for err before doing anything with ret, it doesn't hurt
| having ret always passed up.
|
| 4 extra lines only to lose the value of ret in case of error.
| tptacek wrote:
| You can golf it down to return
| sayThanks("thank you rsc")
|
| without losing anything, but then it could just as easily be
| JS.
| denysvitali wrote:
| In this case, the if err != nil is completely useless.
|
| Usually the pattern is used to perform better error handling
| (wrapping errors) or in case you call multiple functions that
| might return an error.
|
| In this case, your suggestion is actually what I would expect
| to see
| randomdata wrote:
| It's a joke about how every contrived Go example posted to
| the internet is in that vein. You wouldn't blindly pass
| something up the stack like that in a real application. Well,
| maybe if you hate other developers for some reason.
| amiga386 wrote:
| It's not needed if it's just on its own, but Go's error
| handling makes it necessary when chaining functions, which is
| why you see it so often.
|
| Imagine in Java or Python or C# or ... many languages that
| use exceptions to handle errors: return
| a(b(c(arg)));
|
| ...where a(), b(), and c() can throw some kind of exception,
| so you don't have to handle them then and there. In Go there
| aren't exceptions, all error handling is explicit and handled
| conventionally by returning an error as the last (sometimes
| only) return value, which isn't composable, so you get:
| cVal, err := c(arg) if err != nil {
| return nil, err } bVal, err := b(cVal)
| if err != nil { return nil, err }
| return a(bVal) // the final call can be simpler
|
| That's the minimum verbosity required. Since Go 1.13 (2019),
| they officially added the concept of "wrapped" errors (aka
| "cause" in languages with exceptions) so instead of returning
| err you can return errors.Wrap("error in the a-b-c function
| calling c", err). But nonetheless, _every_ level of the call
| chain has to wrap or pass on all errors with explicit code.
| Go does have panic() and recover() which allow for exception-
| like error handling but it's not idiomatic to use them for
| normal error handling, go wants that to be explicit.
|
| As for why "return nil, err" rather than "return ret, err"?
| Because while the caller _should_ check for errors, sometimes
| they just don't. ret, _ := abc(arg) // just
| ignore the error ret.DoSomethingFun()
|
| You as callee don't want to get the blame if you've
| _partially_ filled an struct because you returned early with
| an error, and it's then usable but causes a crash because it
| was partially initalised, because someone ignored the error
| they got when creating it. That hides where the problem
| really was. Better to return an empty value, default value or
| nil.
| glii wrote:
| Don't forget the context string so you can "unwind the stack"
| from the error message: return nil,
| fmt.Errorf("expressing gratitude: %w", err)
| j2kun wrote:
| TIL about the project he's going to focus on:
| https://go.googlesource.com/oscar/+/refs/heads/master/README...
|
| An LLM-based architecture for helping maintain OSS projects.
| Seems cool.
| hu3 wrote:
| Go changed the way I think about concurrency.
|
| Being able to use channels in a modern programming language is
| such a gift.
|
| rsc thank you for all your contribution to our field. You blog
| posts also taught me a lot.
| iJohnDoe wrote:
| Want to say thanks to anyone and everyone that made Go happen.
| It's been my language for a while now and I appreciate what it
| has made available to me.
| rtpg wrote:
| gofmt probably has alone saved so much time across the world (and
| is upstream from every other language ecosystem basically saying
| "ok let's just autoformat").
|
| I hate what autoformatters do to my code, but I love not having
| to talk about spacing anymore.
| rob74 wrote:
| Interestingly enough, I hate autoformatters (and use spaces
| instead of tabs) _in every other language_ , but in Go you just
| get used to the way gofmt formats your code from the beginning,
| and then start to appreciate that you don't spend as much time
| on it anymore, so it's not a problem (at least for most
| people).
| arp242 wrote:
| I've seen a number of autoformats for other languages be way
| too obsessive about formatting every little detail and edge
| case, to the point where it just becomes silly. 100%
| consistency is a fool's errand, and also contributes very
| very little Once you deal with some major issues (braces,
| spacing) you very quickly get diminishing returns.
| rtpg wrote:
| One thing that I've found works kinda well: if you use a
| linter with "autofix" options, then the policy can be:
| complaint about formatting? Add the lint that can be
| autofixed. Then your formatter is just "run the lint
| autofixes"
| lagniappe wrote:
| F
| MaiVa wrote:
| The Go community is incredibly lucky having had a person as lead
| with such outstanding technical skills and at the same time a
| great sense of strategic long term view. As this was not enough,
| I remember reading some discussions where I thought "Damn, this
| rsc guy has a lot of patience."
|
| Go evolves slowly but steadily. No drama, no politics (external,
| I don't know about the internal), not social justice wars, just
| great technical and community work focussing on the thing at
| hand: A programming language and ecosystem.
| jgowdy wrote:
| Is the new tech lead more likely to get rid of the glibc-isms
| that Golang won't let go of, like crashing if non-ELF standard
| parameters like env aren't passed in ELF library initialization,
| or maybe supporting global-dynamic thread local storage so we can
| dlopen() shared objects made in Go on platforms that don't hack
| like glibc?
|
| Go's obsession with glibc-isms is really unfortunate, and it's
| been many years. If you're using Go with containers on
| Alpine/musl, keep your code very vanilla, because they won't
| support you.
| liveoneggs wrote:
| golang's priority is "works inside of google" and everything
| else tends to be a bit of a fight
| rsc wrote:
| This is definitely not true. "Inside of Google" would have
| been just linux/amd64 for a very long time. Now it includes
| linux/arm64 too, but that port happened before Google needed
| it. And all the other ports are not used inside of Google,
| except maybe the Mac port if you count developers laptops.
| liveoneggs wrote:
| https://github.com/golang/go/issues/12914
| jgowdy wrote:
| Here are some citations since people seem to be just downvoting
| because they don't like the message:
|
| Go requiring non-ELF standard parameters for initialization of
| supposedly "C ABI" libraries, open since 2015.
|
| https://github.com/golang/go/issues/13492
|
| The Go project specifically acknowledging the glibc-isms here:
|
| "All Linux first class ports are for systems using glibc only.
| Linux systems using other C libraries are not fully supported
| and are not treated as first class."
|
| https://go.dev/wiki/PortingPolicy
|
| Go only supporting static-init thread local storage, and thus
| their "C ABI" libraries can only be dlopen()'ed if the libc
| pre-allocates memory to hack in libraries later.
|
| https://github.com/golang/go/issues/54805
| rsc wrote:
| If you just want to run Go programs on Alpine, it works fine.
| (I put some effort in back in Go 1.21 to make sure that the
| downloaded binary toolchains for Linux even work fine on
| Alpine.)
|
| If you want to use c-shared mode and dlopen, then yes _that_
| only works with glibc, but that mode barely works at all
| anyway. It 's not actively supported at all.
| hankman86 wrote:
| Does Google actually consider Go to be a success? I get the
| impression that it failed in what it set out to be: a successor
| to C/C++. Or put differently, Rust has eaten Go's lunch.
| jeffrallen wrote:
| A goal of Go was to put working on complex distributed systems
| within the reach of the junior people Google had access to in
| the quantity they were hiring. To whit, the kind of people who
| would have been able to work on a big Python system with 3
| months ramp up or on a big C++ system with a year of ramp up.
|
| It is pretty clear that with respect to that goal, Go is a
| success. It has attracted Python programmers who need type
| safety and performance. Someone with no Go experience could
| land a useful new feature in a big Go program in 3 months.
|
| Introducing a junior person to a large Rust system would still
| take a year, because it is so much more difficult than Go.
| Which means to me that if Rust had been aiming at this same
| adoption goal (it wasn't) it would not have succeeded where Go
| did.
| zozbot234 wrote:
| > Introducing a junior person to a large Rust system would
| still take a year, because it is so much more difficult than
| Go.
|
| Do you really think large Golang codebases are so easy to
| survey? I could see the argument wrt. C++, but Rust actually
| has a great featureset for programming "in the large". Take a
| look at the k8s codebase for an example of a large project
| that's written in Golang - doesn't seem all that easy to get
| started with.
| weinzierl wrote:
| > _" Introducing a junior person to a large Rust system would
| still take a year, because it is so much more difficult than
| Go."_
|
| A recent study done at Google disagrees with this assessment.
|
| _" "it takes about the same sized team about the same time
| to build it, so that's no loss of productivity"_,
|
| said Google's Director of Engineering Lars Bergstrom about
| porting Go to Rust in the talk
| https://youtu.be/6mZRWFQRvmw?t=27012
| tm-guimaraes wrote:
| Time to build a new system and time to onboard a new team
| member without professional experience in a given language
| are 2 very difficult things.
|
| Go is much more optimised for quick onboarding, fast
| feedback, more "code look" consistency across projects then
| rust.
|
| Now a team that knows both rust and go well might have the
| same proditivity in rust and go (maybe even more in rust),
| but with lots of changes in personell, specifically in
| quick growing departments, go can make a huge difference.
|
| This is obviously just an anecdote, but i've seen more
| companies or departments running mostly a go backend stack,
| having job postings saying "no go experience required",
| than the equivalent other companies (or departments )
| focused on any other lang.
| hu3 wrote:
| His direct quote contradicts your assertion:
|
| "When we have rewritten from Go into Rust, we found that it
| takes the same size of team and same time to build it."
|
| Important part here being: rewrite. I would expect a
| rewrite to take less time, not the same time, than writing
| from scratch. Yet a Rust rewrite took as long as Go from-
| scratch project.
|
| So to me, this implies the opposite, that Rust takes longer
| to write.
| weinzierl wrote:
| This is an interesting question, but I doubt you will get a
| satisfactory answer here and probably anywhere. There is
| probably not even a uniform opinion about this within Google.
|
| What I am more curious about is how much actual use Go has
| within companies and especially Google. What is the percentage
| of Go within their monorepo? How much of Google search is
| powered by Go?
| randomdata wrote:
| Go was never intended to be a C/C++ successor, it was intended
| to solve a class of problems that Pike and gang experienced in
| the software they worked on. Which is to say network servers.
| What you are probably remembering is that they assumed from
| their unique Google lens that it was C++ developers who had
| those same problems and would see it as an alternative to C++
| when faced with those problems, but it turned out that in the
| "real" world people were writing network servers in Python and
| Ruby, not C++.
|
| Which isn't surprising to the rest of us. If you remember the
| days before Go, every second thread on HN was about how
| "company X", including the company now known as X, saw their
| Ruby network servers completely falling down under load,
| forcing a rewrite in whatever the language du-jour was that
| day. But Googlers tend to live in a completely different bubble
| with respect to the way software is written.
| rob74 wrote:
| If I remember the legend correctly, the idea for Go was
| initially conceived while waiting for a C++ program to
| compile. Not sure about any of the other stuff, but they
| definitely got the compile times right...
| mike_hearn wrote:
| Well, a lot of servers are Google are (or were) written in
| Java not C++. As a GCd language, arguably Go competed with
| Java internally moreso than C++. One of Go's flagship
| projects (Kubernetes) started out being written in Java for
| example.
| trustno2 wrote:
| One guy that did ML in Google told me that Google indeed tried
| to use Go for ML problems, then realized it's too slow and went
| back to C++ there.
| remus wrote:
| I guess it depends on how you define success, but given there's
| a lot of people writing a lot of go code inside and outside of
| google over the last 15 years it seems likely it's doing a
| decent job at solving problems for those people. I'd call that
| a success.
| barsonme wrote:
| [delayed]
| denysvitali wrote:
| Thank you for all your work Russ!
| philosopher1234 wrote:
| Boy, this makes me sad. He's really changed my life, I've learned
| so much about software and programming from his writing and
| thinking. I wish it didn't have to happen, but I guess it's only
| ever a matter of time.
| rsc wrote:
| Happy to hear that. Still going to write and think. :-)
| calini wrote:
| Thank you for making my career more enjoyable and productive,
| rsc! Go is a lovely ecosystem and I'm looking forward to see
| where it will Go :).
| chmike wrote:
| humor: I wonder if the upvotes are cheerings that he finally
| stepped down or a respectful salute. I give my respectful salute.
|
| Go is awesome and I hope it will continue to progress in that
| direction. Thank you Russ Cox
| zakki wrote:
| Any reference for a website or book that introduce Go for a
| beginner in depth?
| jeremyloy_wt wrote:
| https://go.dev/tour/welcome/1
___________________________________________________________________
(page generated 2024-08-02 23:01 UTC)