[HN Gopher] Go: What we got right, what we got wrong
___________________________________________________________________
Go: What we got right, what we got wrong
Author : veqq
Score : 140 points
Date : 2024-01-04 21:16 UTC (1 hours ago)
(HTM) web link (commandcenter.blogspot.com)
(TXT) w3m dump (commandcenter.blogspot.com)
| dekhn wrote:
| This is a retrospective written by Rob Pike, one of the creators
| of the Go language.
|
| I worked at Google at the time go was created and had coffee with
| Rob from time to time and got to understand the reasons Go was
| created. Rob hates Bjarne Stroustrup and everything C++ (this
| goes back decades). C++-as-used at Google (which used far more
| threads that he says) had definitely reached a point where it was
| extremely cumbersome to work with.
|
| I can think of some other things that they got wrong.
|
| For example, when I first started talking to Rob and his team
| about go, I pointed out that scientific computing in FORTRAN and
| C++ was a somewhat painful process and they had an opportunity to
| make a language that was great for high performance computing.
| Not concurrent/parallel servers, but the sorts of codes that HPC
| people run: heavily multi-threaded, heavily multi-machine,
| sophsticated algorithms, hairy numerical routines, and typically
| some sort of interface to a scripting language with a REPL.
|
| The answers I got were: Go is a systems programming language, not
| for scientific computing (I believe they have now relaxed this
| opinion but the damage was already done).
|
| And a REPL wasn't necessary because Go compiled so quickly you
| could just write a program and run it (no, that misses the point
| of a repl, which is that it builds up state and lets you call new
| functions with that built-up state).
|
| And scripting language integration was also not a desirable goal,
| because Go was intended for you to write all your code in Go,
| rather than invoking FFIs.
|
| A number of other folks who used Go in the early days inside
| Google complained: it was hard to call ioctl, which is often
| necessary for configuring system resources. They got a big "FU"
| from the go team for quite some time. IIUC ioctls are still
| fairly messy in Go (but I'm not an expert).
|
| I think Go spent a lot of time implying that goroutines were some
| sort of special language magic, but I think everybody knows now
| that they are basically a really good implementation of green
| threads that can take advantage of some internal knowledge to do
| optimal scheduling to avoid context switches. It took me a while
| to work this out, and I got a lot of pushback from the go team
| when I pointed this out internally.
|
| IN short, I think go could have become a first-class HPC language
| but the go team alienated that community early on and lost the
| opportunity to take a large market share at a time when Python
| was exploding in ML.
| leeoniya wrote:
| > And scripting language integration was also not a desirable
| goal, because Go was intended for you to write all your code in
| Go, rather than invoking FFIs.
|
| "just avoid cgo" is a something i've heard many times from all
| Go devs
| liampulles wrote:
| Interesting context. I use Go a lot for enterprise backend type
| work and I have to say I'm glad its not geared towards being an
| HPC language, but to each their own.
| randomdata wrote:
| _> I believe they have now relaxed this opinion_
|
| Or is it that scientific computing is starting to realize that
| it can benefit from a systems programming language?
|
| Scripting langages are great for exploratory work, but if you
| want to put to work into production, scripting starts to really
| show its limitations. There is a reason systems languages
| exist. There is good reason why they both exist. They are
| different tools for different jobs.
| coldtea wrote:
| > _Or is it that scientific computing is starting to realize
| that it can benefit from a systems programming language?_
|
| Can't be it, since a huge percentage of scientific computing
| is done with a scripting language.
|
| A systems programming language is still good for the backend
| libraries of scientific computing - but Go has zero share of
| that.
| randomdata wrote:
| A huge percentage of scientific computing is scripting in
| nature. It would be silly to use anything other than a
| scripting language.
|
| But not all. Whether or not it is Go that gets the job, a
| systems language of some kind would be beneficial in those
| circumstances.
| galaxyLogic wrote:
| There are 2 conflicting goals: 1) Having a language in
| which it is easy to express and try out ideas and 2)
| Producing fast and safe programs.
|
| A scripting language would seem to be good for the
| exploratory scientific research, because of that. Whereas
| when you need to create a performant library that can do
| heavy crunching with reproducible results on any platform
| you need the other. The questions is: Do you know what
| you want to implement, or is that still an open question?
| Guvante wrote:
| Except what does Go get for ditching the REPL?
|
| It already has a substantial runtime (the usual pain of an
| REPL)
| randomdata wrote:
| What would it gain? REPLs make perfect sense for scripting
| problems, but when you would you ever use it for systems
| problems?
| leetrout wrote:
| I dream of a world where we have Go or something similar with
| the same / similar UX of Jupyter Notebooks. I keep an eye on
| Julia but I never make the leap to use it and still pickup
| Python (or Go).
| zozbot234 wrote:
| https://github.com/evcxr/evcxr can run Rust in a Jupyter
| notebook. It's not Golang but close enough.
| google234123 wrote:
| There's engineers at Google trying to get things done, and ones
| trying to create new languages... they don't talk to each other
| too much
| mattbee wrote:
| I think Java's "green" threads only ran on a single core, a
| stop-gap for 90s machines that only had one.
|
| Goroutines use OS threads, but only create one OS thread per
| core. Go does the scheduling internally on top of those few
| "real" threads.
|
| Java itself now provides a goroutine-type model with Virtual
| Threads, but as the programmer you've got to ask for it.
|
| Well, I just felt like "green" is a confusing moniker in that
| context.
| zozbot234 wrote:
| Goroutines use thread-per-core but run stackful fibers on top
| of that. (A similar model is sometimes known as "Virtual
| Processors" or "Light-weight processes".) This is unlike the
| use of stackless async-await in other languages. This
| peculiar use of fibers in Go is also what gets in the way of
| conventional C FFI and leads to quirks like cgo.
| jtasdlfj234 wrote:
| Excellently described.
|
| I'd love to see a resource that highlights these all on a
| table across programming languages as well as the
| associated strengths and weaknesses of such threading &
| concurrency models.
|
| Perhaps a ByteByteGo graphic, if you will.
| pphysch wrote:
| This seems misdirected. Go clearly wasn't designed for
| scientific computing, and that's okay. I've successfully
| written some multi-node MPI codes in Go, but there's not much
| advantage over C, and likely some disadvantages relating to the
| Go runtime and linking behavior.
|
| Python (largely) is the present and future of scientific
| computing because people realized you can write the mathy
| kernels in something low-level and just orchestrate it with
| ergonomic Python and its bountiful ecosystem/mindshare. Python
| adequately checks all the boxes and I don't see how a newcomer
| like "Scientific Go" or R or Julia will ever unseat it. Not to
| mention curmudgeonly researchers have little desire to learn
| new tricks.
|
| But I do use Go when needed as a systems language, and it is
| fantastic for whipping out the occasional necessary
| microservice (due to network boundaries, etc).
| theLiminator wrote:
| I think the main issue with Python tends to not be
| performance (though it can be hard to speed up certain
| bottlenecks), but rather there's a point where maintaining it
| goes from very easy to very difficult due to lack of static
| typing. Where this occurs can be pushed further back with
| very careful programming discipline (or by adopting mypy et.
| al from the start). But I could see a world where something
| go-like with a little more expressivity could've become that
| glue language instead of python.
| pphysch wrote:
| This is a software engineering practices problem rather
| than a Python problem. Python has great tooling and
| language support for type annotations. I work on large
| Python codebases with ease because I leverage these things.
| My IDE is able to do static analysis and catch potential
| typing errors before runtime.
|
| The problem is we have researchers with no SWE expertise
| writing huge codebases in Jupyter notebooks inside a
| bespoke, possibly unreproducible Anaconda environment. That
| is going to be a maintenance disaster no matter which
| language is being used.
|
| And if you force your researchers, who are using to being
| productive prototyping in Python, R, etc. to use a
| statically-typed language, they are going to complain and
| be a lot less productive at their job.
| theLiminator wrote:
| I find mypy and the other type checkers I've used kinda
| painful due to false positives.
|
| I think with proper type inference, there would be a lot
| less pain around static typing.
|
| Ideally users should be forced to type their function
| signatures and everything else can be inferred.
|
| Definitely I do agree with you that the situation today
| is much superior to even just 4-5 years ago.
| lamontcg wrote:
| > I don't see how a newcomer like "Scientific Go" or R or
| Julia will ever unseat it.
|
| Julia's support for Autodiff
| npalli wrote:
| Good historical perspective thanks for it. Your comments on
| scientific computing/HPC are interesting. Golang could indeed
| have solved the two-language problem and taken off like a
| rocket in comparison to where it is (hovering in the top 15).
| However, I think it would have to tackle some very orthogonal
| concepts - to the systems language creators like Rob and others
| on the go team - like vectorization as first class concept,
| parallelism (not green threads) etc. which might have limited
| some of the initial implementation efficiencies, not sure.
| There is still room for such a language (Julia is getting
| there...) perhaps some disgruntled FORTRAN elder who is sick of
| C++ will create such a new language :-)
| tejohnso wrote:
| > Rob hates Bjarne Stroustrup
|
| That sounds extreme. What did Bjarne do to him?
| aragonite wrote:
| Don't know about Rob Pike in particular but Ken Thompson, who
| probably had the same reasons for "hating" Stroustrup, had
| this to say about him (from Coders at Work):
|
| Seibel: You were at AT&T with Bjarne Stroustrup. Were you
| involved at all in the development of C++?
|
| Thompson: I'm gonna get in trouble.
|
| Seibel: That's fine.
|
| Thompson: I would try out the language as it was being
| developed and make comments on it. It was part of the work
| atmosphere there. And you'd write something and then the next
| day it wouldn't work because the language changed. It was
| very unstable for a very long period of time. At some point I
| said, no, no more.
|
| In an interview I said exactly that, that I didn't use it
| just because it wouldn't stay still for two days in a row.
| When Stroustrup read the interview he came screaming into my
| room about how I was undermining him and what I said mattered
| and I said it was a bad language. I never said it was a bad
| language. On and on and on. Since then I kind of avoid that
| kind of stuff.
|
| Seibel: Can you say now whether you think it's a good or bad
| language?
|
| Thompson: It certainly has its good points. But by and large
| I think it's a bad language. It does a lot of things half
| well and it's just a garbage heap of ideas that are mutually
| exclusive. Everybody I know, whether it's personal or
| corporate, selects a subset and these subsets are different.
| So it's not a good language to transport an algorithm--to
| say, "I wrote it; here, take it." It's way too big, way too
| complex. And it's obviously built by a committee.
|
| Stroustrup campaigned for years and years and years, way
| beyond any sort of technical contributions he made to the
| language, to get it adopted and used. And he sort of ran all
| the standards committees with a whip and a chair. And he said
| "no" to no one. He put every feature in that language that
| ever existed. It wasn't cleanly designed--it was just the
| union of everything that came along. And I think it suffered
| drastically from that.
|
| Seibel: Do you think that was just because he likes all ideas
| or was it a way to get the language adopted, by giving
| everyone what they wanted?
|
| Thompson: I think it's more the latter than the former.
| el-dude-arino wrote:
| 99% of programmers, but especially the brilliant/well known
| ones, are insufferable egotists. Many cannot have a technical
| disagreement without despising the person they disagree with.
|
| Professionalism and the tech industry are just starting to
| get acquainted.
| 1attice wrote:
| Most professions, quietly, are currently like this.
| Architects and scientists and doctors and surgeons and
| lawyers all develop strong opinions about each other based
| on their positions.
|
| For instance: ask a lawyer what they think about the
| overturning of Roe v Wade. Now ask them what they think
| about their colleagues who disagree. Don't forget to duck.
|
| Which isn't to say that we wouldn't all be much better off
| with more distance between our opinions and our identities.
| But the thing you're looking for is a cultivated practice
| that is often not at odds with 'egotism' (what is that,
| precisely, anyway?) but _entailed by_ it: the not-wanting-
| to-be-the-kind-of-person-who-does-XYZ.
|
| Not all vanities are risible.
|
| What you're looking for is a long-cultivated, inward
| practice that can be supported or hindered by all the usual
| forces, local context (culture, practice, etc) chief among
| them.
|
| Put another way: your claim isn't that most programmers are
| unprofessional. It's that they're _uncollegial_. And you're
| right. So are a lot of other contemporary professionals.
| It's a shouty era.
| chaxor wrote:
| It's ok that Go didn't work out for scientific crowds, since
| Julia works better for the scientific community as a
| replacement for hacky Matlab/c++/Fortran conbled-together
| scripts.
| rdtsc wrote:
| > Go is a systems programming language,
|
| I remember that being a meme of sorts. Most people understood
| that as a C/C++ replacement with operating systems and drivers
| being written in Go. System programmers laughed, of course.
| Eventually when it didn't look like it wasn't going happen, the
| token reply from Go devs became "Well not those kind of
| systems, we always meant a different kind of systems
| programming language, not what you all thought".
| google234123 wrote:
| The value it's brought to Google has definitely not been worth
| the cost. It did not really replace other languages. If you join
| Google now as a new engineer, you will likely be writing C++,
| Java, or maybe a web language
| leetrout wrote:
| Can you say more about this?
|
| Was Go inspired / derived from the use of sawzall and it just
| performs its intended uses in other parts of the company?
| nadermx wrote:
| That really depends on how beneficial the things they use
| golang for are. Hard to quantify if it allowed for large
| benefit in say YouTube or such
| Thaxll wrote:
| How do you know about the cost? Do you have numbers? It's the
| root of many core and used services.
| paulddraper wrote:
| You won't be writing Go?
| rrdharan wrote:
| You might be, but as the parent said, it's not _likely_. I
| think that's a fair statement, out of 100K engineers or
| whatever it is, I'd estimate less than 10K of them are
| writing primarily golang code.
| dummyvariable wrote:
| This in incorrect, I have been at Google more then 5 years and
| the work has been in go. Most of the teams around me use go as
| well. But this is not to say that there is lesser java/cpp use.
| rrdharan wrote:
| Your experience doesn't invalidate the likeliness part of the
| parent comment.
|
| You just happen to be in the subset / cluster / areas that
| write in golang. Probabilistically speaking across the entire
| Google engineering population both you and the teams around
| you are outliers. That doesn't mean golang is insignificant.
|
| As to whether golang was _worth it_ I disagree with the
| parent, I think it was probably worth the resources invested,
| even if e.g. usage has leveled off internally, but at any
| rate this is a hard thing to measure so we're all just
| opining.
| scythe wrote:
| A friend of mine who works for Google noted that they hardly
| use Go internally, and quipped, "Google invented Go to sabotage
| its competitors."
| leetrout wrote:
| I picked up Go in 2012 as a Python dev in need to doing some bit
| twiddling over the wire for Modbus. I never shipped that code but
| it blew my mind how easy it was to just twiddle those bits and
| bytes and it just worked.
|
| A decade later and a couple almost full time Go jobs under my
| belt and it still surprises me how well most things Just
| Work(tm).
|
| I love the Go language and I love the Go community.
|
| I appreciate what Rob, Ian, Russ and the others do for Go and I
| appreciate that this talk / blog is honest about the "bumps in
| the road" working with the community. There's not much point in
| beating a dead horse around this but having lived through it I
| find it very hard to believe they didn't know exactly how they
| were behaving, especially in regards to the package management
| debacle. Never the less the blog is also correct that we have
| landed at a very good solution (Drew's legitimate complaints
| aside).
|
| Here's to another 10 years of Go and the inspired / similar
| languages (Zig, Deno, etc) and hoping we continue to grow as a
| healthy community.
| zozbot234 wrote:
| Zig and Deno are not very comparable to Golang I think. Elixir
| and ReasonML would be more like it. From Google themselves
| there's also Dart.
| biomcgary wrote:
| My favorite thing about the core Go team is their willingness
| to say "No" (to all sorts of stuff) and "Wait for the right
| implementation" (for generics).
|
| I'm a computational biologist rather than a programmer, so my
| use of Go waxes and wanes, but when I come back to Go, my code
| compiles and the language works the way I expect.
|
| That being said, I do appreciate Rob Pike's willingness to
| admit mistakes on the learning curve on community engagement
| without capitulating on adding all the shiny objects.
| zozbot234 wrote:
| Wrt. generics they followed in Java's footsteps: they asked
| the PLT community to come up with a reasonably elegant model
| that would mesh well with the rest of the language, and then
| largely stuck to that.
| jtasdlfj234 wrote:
| I would have more respect if they at least admitted to the flawed
| type system but instead say it is not a problem. It is
| disappointing to see past mistakes repeated in a new programming
| language. Even the Java language creator was humble enough to
| admit fault for the null pointer problem. The Go devs do not have
| such humility.
|
| https://github.com/uber-go/nilaway
| coolgoose wrote:
| The nil handling (or the lack of) in go is right now my biggest
| annoyance with the language :)
| grumpyprole wrote:
| It's interesting that they brought in Phil Wadler to help
| retrofit polymorphism, it literally is history repeating itself
| (Wadler did Generics retrofit for Java).
| knorker wrote:
| I think two big failures were:
|
| 1. Nil pointers (two types of them, even!). We knew better even
| then.
|
| 2. Insisting that the language doesn't have exceptions, when it
| does. User code must be exception safe, yet basically never use
| exceptions. The standard library swallows exceptions (fmt and
| http)
|
| Those are the biggest day to day concrete problems. There are
| many more that are more abstract, but also hurt.
| randomdata wrote:
| _> Insisting that the language doesn 't have exceptions_
|
| Insist in what way? The Go website insists that Go has actual
| exceptions, unlike the pretend exceptions that are actually
| errors passed around using goto like you find in Java and other
| languages inspired by it.
| lokar wrote:
| So many people confuse errors with exceptions
| monocasa wrote:
| Given how they being up how fmt and http swallow them, I
| believe the parent is referring to panics rather the errors
| returned via standard control flow.
| randomdata wrote:
| Yes, that's what we're talking about (exceptions, or panics
| if that's what you want to call them). That's what
| exceptions are.
| monocasa wrote:
| I guess I'm confused since panics are equally errors
| passed around by gotos as much as java exceptions are.
| Probably more so since at least with java it ends up
| being part of the the function type signature the vast
| majority of the time.
| everforward wrote:
| It creates 2 disparate types of error handling that don't
| neatly mesh together. You have to handle error return
| values, but you also have to handle exceptions (panics)
| because they still exist.
|
| My issue is mostly implementing both ways of bubbling up
| an error to somewhere it can be handled. I think having
| either error return values or exceptions is preferable to
| having both. I don't think exceptions are perfect, but if
| panic() absolutely has to exist then I'd rather have an
| entirely exception-based language than a language that
| uses both systems simultaneously.
|
| E.g. if I write a function that accesses an element of an
| array without bounds-checking, it could panic and I have
| to handle that exception. Bounds-checking basically just
| becomes finding things that would throw exceptions and
| converting them to errors so we can pretend that
| exceptions don't exist.
| stonemetal12 wrote:
| Other than the fact that they spelled "throw" "panic",
| "catch" "recover", and "finally" "defer" how are go
| exceptions different than what you find in java?
|
| I get that Go devs like to claim they are completely
| different because you are supposed to use them differently,
| but under the hood they are identical as far as I can tell.
| tptacek wrote:
| Go has been my daily driver for over a decade. I was in the
| past a C++ programmer. In what ways am I writing exception-safe
| code when I write ordinary Go code?
| monocasa wrote:
| I've run into issues where panics cause half of what should
| be a multistep but assumed to be atomic transaction to occur,
| putting the system into a goofy state that required fairly
| manual intervention. In my case a system daemon that required
| someone to manually fix up system state on the CLI and
| restart the system.
| tptacek wrote:
| That's like, strong-form exception safety, a problem in
| most mainstream languages. But when C++ people talk about
| "exception safety", they're talking about basic or weak-
| form exception safety: not leaving dangling pointers and
| resources as a result of unexpected control transfer. That
| style of defensiveness is not common in Go code.
| monocasa wrote:
| Well that's the thing, I am talking about resources left
| 'open' since they didn't complete their lifecycle due to
| the unexpected control flow. Yes, it's not common in go
| code, but I think that's more a combo of the GC making
| dangling memory not a problem, and the environment that
| most go code lives in (ie. kubernetes clusters or some
| equivalent) where the other resources leaked are
| eventually reclaimed by the autoscaler and other devops
| automation.
|
| The GC is ubiquitous, and definitely a point in favor for
| go for the vast majority of use cases, but I've found it
| more difficult than anticipated to write go code that
| manipulates resources other than memory that the
| environment you're running in won't clean up for you. And
| that's coming from C++ code originally including the
| exception safety issues.
| __turbobrew__ wrote:
| Panicing on nil pointers is definitely the thing which I have
| seen cause the most pain.
| silvestrov wrote:
| The ?. (optional chaining) operator in Javascript is really a
| godsend for this.
|
| https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| VirusNewbie wrote:
| I'm surprised they didn't mention the horrible error handling as
| something they regret...
| righthand wrote:
| Because it's neither horrible nor regrettable, it just doesn't
| cater to your perfect idea of what it should be. It's a smart
| way to encourage people to handle errors.
| Thaxll wrote:
| It's not horrible, it's ok and a bit repetitive. Really the
| whole thing about error handling in Go is overblown.
| righthand wrote:
| It's a bit repetitive but so is writing `for i, v := range n
| {}` everywhere. Code loops and repeats syntax all the time,
| so what? Argument doesn't hold water for me (not attacking).
| eweise wrote:
| Because its repetitive its leads to incorrect code. I've seen
| more swallowed errors in Go than other languages.
| 13415 wrote:
| Honestly, I've seen way more problems with global exception
| handlers, which often lead to incomprehensible end user
| messages.
| moomin wrote:
| He's claiming go popularised concurrency and invented interfaces?
| I'm sorry but that's laughable.
|
| I mean, congratulations, you created a new popular programming
| language, and that's not nothing, but let's not rewrite history
| here.
| tomp wrote:
| What other languages of comparable popularity do you know that
| had concurrency similar to Go's, and interfaces?
|
| Actually, name just one that has either, even today!
| ninepoints wrote:
| Erlang
| phinnaeus wrote:
| > of comparable popularity
| Thaxll wrote:
| Erlang is not a popular language.
| easton wrote:
| C#? It has channels and good concurrency stuff. I don't know
| if it was as mature in 2007 when they did this work.
|
| edit: Concurrency, not the language itself. That was mature.
| dwattttt wrote:
| Java has had interfaces for a _long_ time, and it definitely
| meets the popularity requirement.
|
| EDIT: Since its 1.0 release in 1996
| scythe wrote:
| Fibers were implemented by Microsoft in Win32 API in 1996:
|
| https://devblogs.microsoft.com/oldnewthing/20191011-00/?p=10.
| ..
|
| As the review Chen links discusses, it turns out that M:N
| threading (i.e. goroutines) and good C compatibility are
| mutually exclusive. Go went one way, every other language
| went the other way. The most common alternative is stackless
| coroutines, which are much more widely implemented than the
| Go model.
| liampulles wrote:
| I don't think you read the Interfaces section properly. Rob is
| not claiming go invented interfaces.
|
| If you want to level such a charge that he is rewriting
| history, you need to take special care yourself in representing
| his views accurately.
| dwattttt wrote:
| I came away with the impression they were saying they'd
| invented interfaces, so I reread it:
|
| > That idea was exciting for us, and the possibility that
| this could become a foundational programming construct was
| intoxicating.
|
| Talking about interfaces as an idea that could become a
| foundational programming construct definitely sounds like
| they're saying they invented it.
| w10-1 wrote:
| I really, really appreciate key people taking the time for
| retrospectives. It makes a huge difference to people now who want
| to make a real difference.
|
| But I'm not sure Rob Pike states clearly enough what they got
| right (IMO): they managed the forces on the project as well as
| the language, by:
|
| - Restricting the language to its target use: systems
| programming, not applications or data science or AI...
|
| - Defining the language and its principles clearly. This avoids
| eons of waste in implementing ambiguity and designing at cross-
| purposes.
|
| - Putting quality first: it's always cheaper for all concerned to
| fix problems before deploying, even if it's harder for the
| community or OS contributors or people waiting for new features.
|
| - Sharing the community. They maintained strict control over the
| language and release and core messaging, but they also allowed
| others to lead in many downstream aspects.
|
| Stated but under-appreciated is the degree to which Google itself
| didn't interfere. I suspect it's because Go actually served its
| objectives and is critical to Google. I wonder if that could be
| true today for a new project. It's interesting to compare Dart,
| which has zero uptake outside Flutter even though there are
| orders of magnitude more application code than systems code.
|
| Go was probably the key technology that migrated server-side
| software off Java bloatware to native containers. It dominates
| back-end infrastructure and underlies most of the web application
| infrastructure of the last 10 years. The benefit to Google and
| the community from that alternative has been huge. Somehow amidst
| all that growth, the team remained small and kept all its key
| players.
|
| Will that change?
| zozbot234 wrote:
| > Go was probably the key technology that migrated server-side
| software off Java bloatware to native containers
|
| Interesting point of view - Golang might be pithily described
| as "Java done right". That has little to do with "systems
| programming" per se but can be quite valuable in its own terms.
| grumpyprole wrote:
| Java has a culture of over-engineering, to the point where
| even a logging library contains a string interpolator capable
| of executing remote code. Go successfully jettisoned this
| culture, even if the language itself repeated many of the
| same old mistakes that Java originally did. Java done right
| is certainly not Go.
| 0cf8612b2e1e wrote:
| Not sure I would agree with the community leading aspect. It
| still feels like Google decides.
|
| My particular point would be versioning. At first Go refused to
| acknowledge the problem. Then, when there was finally growing
| community consensus, Go said forget everything else, now we are
| doing modules.
|
| I also recall the refusal to make montatomicly-increasing-time
| a public API until cloudflare had a daylight savings time
| outage.
| kevingadd wrote:
| Personally their handling of versioning, generics and
| ESPECIALLY monotonic time (in all 3 cases, seemingly treating
| everyone raising concerns about the lack of a good solution
| as if they were cranks and/or saying fix it yourself)
| definitely soured me on Go and I would never choose it for a
| project or choose to work for a company that uses it as
| language #1 or language #2.
|
| It just left a bad taste in my mouth to see the needs and
| expertise of actual customers ignored by the Go team that way
| since the people in charge happened to be deploying in
| environments (i.e. Google) where those problems weren't
| 'real' problems
|
| Undeniable that people have built and shipped incredible
| software with it, though.
| scythe wrote:
| >Restricting the language to its target use: systems
| programming, not applications or data science or AI...
|
| The only Go I ever touched in industry was the backend of a
| web-app at Salesforce. I'm not sure this counts as "systems
| programming".
|
| https://engineering.salesforce.com/einstein-analytics-and-go...
| WatchDog wrote:
| Rob describes go as a language for writing server
| applications, and I think that is a much more applicable term
| than systems programming.
| liampulles wrote:
| I was a Java dev and love using Go now, but I have to say I'm
| not sure if many of my Ex-Java-Colleagues would like Go. Go is
| kind of odd in that even when it was new, it was kind of
| boring.
|
| I think a lot of people in the Java world (not least myself)
| enjoy trying to refactor a codebase for new Java features (e.g.
| streams, which are amazing). In the Go world, the enjoyment
| comes from trying to find the simplest, plainest abstractions.
| liampulles wrote:
| Something that I really like about go is how easy it is to make a
| monorepo, and how quick and easy it is to build all of the
| contained apps (go build ./...).
|
| I also find it really easy to make CLI tools in Go that can form
| part of unix pipelines, since: you just need a single go file and
| app-named folder to get started, it gives you a self-contained
| binary as output, and the Reader/Writer interfaces make it easy
| to stream and handle data line-by-line. We have a couple of CLIs
| at work that analyze multi-gig logs in a couple of seconds for
| common error patterns - Go is very handy for such things.
| kitsune_ wrote:
| I know I sound salty here, but 10 years ago I got ridiculed on
| go-nuts, with dismissive comments from Rob Pike, because I dared
| to suggest that the way go get and module imports over the wire
| 1. worked, 2. were advertised in all their docs for beginners,
| and 3. how they were subsequently used throughout the community
| was ultimately harmful / shortsighted.
| treyd wrote:
| The way Go's package system works, especially before modules,
| really feels like it was a hack over an earlier and even more
| limited system that was designed to be used entirely inside the
| Google monorepo that was made to work outside. The weird global
| namespace tree makes sense there, and the emphasis on checked-
| in codegen also make sense there when you consider that Google
| also includes build artifacts in their monorepo.
| shp0ngle wrote:
| It's interesting that what they came up with is better than
| what's out there for other languages.
|
| Yeah, you have the "v2" / forever v0 problem. But it's still
| better than what I need to deal with when using npm or (doing
| sign of the cross) anything with python.
| bsaul wrote:
| I'm surprised the fact that they manage to keep the language
| small and minimal isn't mentionned as a huge success. To me that
| is the number one reason to use this language : it forces you to
| not be distracted by language constructs (there aren't enough for
| that), and focus on what is it exactly you're trying to build.
| Even as an educationnal tool, this is excellent. Maybe they don't
| realize it because they come from C, but when you come from more
| recent languages that include everything and the kitchen sin,
| this is a godsend.
|
| It's now to the point that whenever i develop a feature in a
| language, i ask myself << how would i do that in go >> to ensure
| i don't go fancy with the type system for no good reasons.
| tptacek wrote:
| Interesting bit here about the decision to use Ken Thompson's C
| compiler rather than LLVM --- something that people grumbled
| about, and that resulted in (especially earlier versions) less
| optimal generated code. The flip side of that decision is that
| they were able to do segmented stacks quickly; they might not
| have done them at all if they'd had to implement them in LLVM and
| fit the LLVM ABI.
|
| (He cites this as an example of the benefit of that decision, not
| the only benefit).
| pcwalton wrote:
| That part of the interview is incorrect. I implemented
| segmented stacks for Rust with LLVM. It's actually pretty easy,
| because there is support for them in X86FrameLowering already
| (and it was there at the time of Go's release too). If you
| enable stack segmentation, then LLVM emits checks in the
| function prolog to call into __morestack to allocate more stack
| as needed. (The Windows MSVC ABI needs most of this
| infrastructure in order to support __chkstk, which is a
| requirement on that platform, so extending it to support
| __morestack wasn't hard.)
|
| What I think the author might be confusing it with is
| _relocatable_ stacks. That _was_ hard to implement at the time,
| because it requires precise GC, though Azul has implemented it
| now in LLVM. Back then, the easiest way to implement precise GC
| would have been to spill all registers across function calls,
| which requires some more implementation effort, though not an
| inordinate amount. (Note that I think the Plan 9 compiler does
| this anyway, so that wouldn 't be a performance regression over
| 6g/8g.) In any case, Azul's GC support now has the proper
| implementation which allows roots to be stored in registers.
| einpoklum wrote:
| The structure of that post is weird, in that it's quite difficult
| to figure out where are the parts which were done right and where
| are those done wrong.
|
| Can someone tl;dr the done-wrong items?
| statquontrarian wrote:
| I was surprised at the poor quality of serviceability given its
| enterprise deployment with k8s. No thread dumps without killing
| the process (or writing a SIGUSR1 handler). No heapdump reader so
| you have to use the memory sampler and hope you catch the problem
| (and that requires adding code), and viewcore is broken in new
| versions (and it doesn't work with a stripped binary which is
| most production binaries).
| notpachet wrote:
| I enjoy Go as a language, but I have always hated the gopher
| mascot. It's so derpy.
___________________________________________________________________
(page generated 2024-01-04 23:00 UTC)