Is it here to stay or will we see it on killedbygoogle.com eventually?

Home Forums Science & tech Is it here to stay or will we see it on killedbygoogle.com eventually?

Viewing 15 reply threads
  • Author
    Posts
    • #129188
      Anonymous
      Guest

      Is it here to stay or will we see it on killedbygoogle.com eventually?

    • #129189
      Anonymous
      Guest

      It’s only getting bigger, and it’s already fairly removed from Google already. They probably couldn’t if they wanted to by now

      Flutter is going on the list any day now though

      • #129191
        Anonymous
        Guest

        they’ve double downed on flutter as its fuschiaOS’s applications are built with it

        if fuschia becomes successful so will flutter.
        Otherwise its got a lot of competition with xamarin, react native etc.

        • #129192
          Anonymous
          Guest

          >if fuschia becomes successful
          big if

        • #129215
          Anonymous
          Guest

          Different use cases.

          >if fuschia becomes successful
          big if

          It will, all Google needs is full compatibility with current Android Linux and done. Nobody except developers will even notice.

          […]

          Depends will Google do angular again with the impending Go2 which very likely will not be compatible with Go1. That will kill the Go.

          • #129233
            Anonymous
            Guest

            >all Google needs is full compatibility with current Android Linux and done.
            yeah, good luck with that.

        • #129271
          Anonymous
          Guest

          Xamarin and react are shit compared to flutter. Tell me one single real competitor to flutter, I will wait. Don’t forget the amount of work google is spending with flutter, it’s only gonna get bigger.

      • #129241
        Anonymous
        Guest

        https://i.imgur.com/3GXtbgW.gif

        they’ve double downed on flutter as its fuschiaOS’s applications are built with it

        if fuschia becomes successful so will flutter.
        Otherwise its got a lot of competition with xamarin, react native etc.

        Flutter is already big, it’s just not talked about because there is nothing to add or complain about. Solid tech is solid.
        Companies using Flutter
        Alibaba, Amazon, Google, Samsung, Tencent, Toyota, BMW, Square, Ebay, Etsy, Groupon, Baida and more

        • #129274
          Anonymous
          Guest

          Flutter is great. Hope Apple accepts it one day and becomes better for ios.

    • #129190
      Anonymous
      Guest

      it was dead on arrival

    • #129193
      Anonymous
      Guest

      Rust will be seen there eventually

    • #129194
      Anonymous
      Guest

      What I don’t understand is why people choose go over c#

      • #129195
        Anonymous
        Guest

        OOP hate I guess

      • #129196
        Anonymous
        Guest

        because they’re not scrotebrained. what kind of question is this?
        >i dont understand why people chose a good language over one of the absolute worst languages

        • #129198
          Anonymous
          Guest

          >Oversimplified = good
          Ok now write your 10th for loop for shit that every reasonable language has higher order functions for

          • #129199
            Anonymous
            Guest

            it’ll use exactly like one line more at the end and be ten times easier to read.

            • #129200
              Anonymous
              Guest

              >Easier to read
              If you are scrotebrained maybe

              • #129201
                Anonymous
                Guest

                and also if you have any experience programming at all and aren’t afraid of a scary loop. higher order functions don’t give you really any more expressiveness over a one line loop doing the same thing and are simply a more contrived way to write an equivalent block of code. go ahead and bury your c# code in functional spaghetti, but don’t ask why anyone would want to use a language where you can be certain any project you find will actually have good programing style.

                • #129202
                  Anonymous
                  Guest

                  I dont use c#. I use typescript and golang at work and switching from typescript to golang makes me puke

                  • #129203
                    Anonymous
                    Guest

                    oh, ok, your opinion is fully invalid gotcha

                    • #129204
                      Anonymous
                      Guest

                      interface{} says otherwise

                      • #129205
                        Anonymous
                        Guest

                        not an argument

                      • #129206
                        Anonymous
                        Guest

                        >Abandoning type safety due to shortcomings of a dumbed down language
                        >Not an argument
                        Then what is? The logo? I dont care for that scrotebrained mascot as im not a woman or chud

                      • #129208
                        Anonymous
                        Guest

                        >cant even figure out how to reply to posts on LULZ properly
                        ok newfriend. and i don’t think you know what type safety is. type assertions exist and it is in fact possible to check if they succeed. in any case nobody will use the empty interface for really any reason in a couple months. they already have no real reason to. it usually is an indicator someone is doing something very wrong unless it’s on a really low api level

                      • #129209
                        Anonymous
                        Guest

                        Yea well guess what in typescript i dont need to check anything because i KNOW. Do you know how it feels to KNOW what datastructure you actually got infront of you without even running it? Maybe you should spent less time making dumb gopher memes and try out some other languages that actually do have a good typesystem.

                        Dont get your hopes up for the upcoming generics either again this language is made for scrotebrains so the implementation of these will be as anything in that language massively dumbed down so even the female diversity hire can be somewhat productive. Maybe a great language if your company was all diversity hires to produce shit tier fast food software but to someone who actually knows what he is doing it doesnt feel fulfilling in the slightest

                      • #129210
                        Anonymous
                        Guest

                        >I KNOW THE TYPES
                        >wants generics

                        lmao what’s type erasure

                      • #129213
                        Anonymous
                        Guest

                        Yes i KNOW. And if i ever dont i have the option to use type guards which i barely ever needed despite having written plenty of generic functions.

                        the generics are already done, we already know what they’re like and they’re well implemented. but you will still almost never need them.

                        Yeah alright if you never need generics in what you do you are exactly the target audience for golang anyway since you are a mcdonalds type code monkey except underpaid and overworked. Why not flip burgers for real at this point?

                      • #129216
                        Anonymous
                        Guest

                        >talks about compile time type checking
                        >talk about generics and having to add runtime type checking

                        tiresome

                      • #129217
                        Anonymous
                        Guest

                        Its not just in runtime. There are plenty things that can already be catched before running it if you dont use any or in golangs case interface{}. Difference is in typescript you can entirely avoid any while in golang you cant

                        Please dont tell me what is tiresome if you are part of a community that puts a cringy mascot in everything they have including tshirts

                      • #129214
                        Anonymous
                        Guest

                        this isn’t Java.
                        there’s no type erasure in Go.

                      • #129211
                        Anonymous
                        Guest

                        the generics are already done, we already know what they’re like and they’re well implemented. but you will still almost never need them.

                      • #129212
                        Anonymous
                        Guest

                        every library you will use, will switch to generics.
                        you should be able to debug the libraries you use.
                        you will need generics for that.

                      • #129220
                        Anonymous
                        Guest

                        Yes i KNOW. And if i ever dont i have the option to use type guards which i barely ever needed despite having written plenty of generic functions.

                        […]
                        Yeah alright if you never need generics in what you do you are exactly the target audience for golang anyway since you are a mcdonalds type code monkey except underpaid and overworked. Why not flip burgers for real at this point?

                        you can debug libraries in go without generics. i dont think either debugging or generics mean what you think they mean. idiomatic go shouldn’t ever really need generics. they’re just useful for DRY code and it’ll definitely be good when they’re fully rolled out. but you dont understand how go’s libraries work. if you find yourself using interface{} everywhere and runtime reflection to emulate genetics then you’re structuring your go project wrong. you just don’t understand go, and in the context of the rob pike quote y’all cope and seethe about constantly that’s pretty embarrassing, isnt it lol

                      • #129221
                        Anonymous
                        Guest

                        you know how many Go libraries use codegen?
                        you think codegen is more idiomatic than generics?

                      • #129222
                        Anonymous
                        Guest

                        no, that’s where generics will be useful. generics that can be replaced by codegen are the usecase where generics will actually be idiomatic. anywhere where use of generics cannot be replaced by codegen and instead has to be replaced with runtime polymorphic interface{} and type coercion stuff will never be idiomatic. that’s the stuff where you have a design problem in your project.

                      • #129223
                        Anonymous
                        Guest

                        you know how many Go libraries use codegen?
                        you think codegen is more idiomatic than generics?

                        it’s also worth mentioning that generics are essentially literally just codegen but built directly into the compilation step lmao. generics are LITERALLY just a code generation macro that copy pastes shit and replaces a token with a concrete type, but with a little bit more compile time checking. you act as though codegen and generics are substantially different things when they’re not.

                      • #129224
                        Anonymous
                        Guest

                        are you saying you want hygienic macros in Go?

                      • #129226
                        Anonymous
                        Guest

                        generics are a subset of hygienic macros and the only macros that are actually required or could ever be useful in go. it would instantaneously ruin the entire go ecosystem if a full fledged macro system as scrotebrained as rust’s were added to the language. generics are a sane compromise.

                  • #129240
                    Anonymous
                    Guest

                    sounds like you have an inferiority complex and feel insecure whenever you have to write procedural code.
                    not to worry: generics are in the next version and map, filter, et al. will be there of course. then you can find something else to whine about.

                • #129228
                  Anonymous
                  Guest

                  dumb scrote shut the fuck up

                  • #129234
                    Anonymous
                    Guest

                    no

          • #129229
            Anonymous
            Guest

            Yes, absolutely. A for loop is both easier to understand and faster to execute in most cases than using a higher order function.
            Filter, map, reduce chains are the midwit of programming.

            • #129230
              Anonymous
              Guest

              >Filter, map, reduce chains are the midwit of programming.
              Filtered by filter. Absolute disgrace.

              • #129232
                Anonymous
                Guest

                I was probably using mappend in lisp before you were born. One day you will get it.

        • #129218
          Anonymous
          Guest

          C# is what most languages should strive for
          >scrotes who use the language don’t endlessly complain about the syntax/features of the language on brazillian basket weaving boards
          >openly set out to copy another language but just became better
          >isn’t trying to become the new <insert popular language here> just wants people to get shit done

          • #129219
            Anonymous
            Guest

            C# is like a magnitude more complex than Go and breaks backwards-compatibility all the time.

            C# is mostly used by blub programmers since everyone else avoided proprietary MS.
            Blub programmers do not talk about their boring job in public.

            C#’s concurrency primitives are still universally hated:
            https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md

            • #129235
              Anonymous
              Guest

              >C# is like a magnitude more complex than Go
              No.
              And go is a dishonest language. Just because there is few features doesn’t mean it’s simple for humans to write. By that logic c is simpler than go and assembler simpler than c

              We actually need complexity in the language because it hepls write more safe and simple code

              • #129236
                Anonymous
                Guest

                Exactly, Go isn’t "simpler", it’s more primitive, which makes it actually harder to create something with it. It’s the same way hand tools are simpler than power tools, yet you would use the latter for anything but hobby projects.

                • #129242
                  Anonymous
                  Guest

                  >Go isn’t simpler
                  C is not simple but is primitive because you don’t even have strings unless included. Go is THE definition of simple but not primitive. The way it handles slices, concurrency, Unicode, memory(GC), is simple in use, yet far from primitive.

                  • #129243
                    Anonymous
                    Guest

                    Go is less primitive than C, sure, but it’s quite a low bar and Go is way more primitive than modern languages like C#, Kotlin, Rust or even C++20. The most memed issue – the lack of generics in a post-2000 compiled language – is a fine example of the designers confusing simplicity with primitiveness. Languages with generics are actually simpler to use, despite being less primitive. Same goes for the Go’s error handling, which is very primitive per se yet far more complex to use properly than exceptions or Haskell/Rust-like monadic error handling.

                    • #129244
                      Anonymous
                      Guest

                      you’re in the dunning kruger trough

                      • #129251
                        Anonymous
                        Guest

                        Why would you say that? I’m not criticizing the Go designers from my personal perspective, I’m referring to the rest of the academia and the industry, gradually developing and adopting best practices. The Go designers practically ignored everything that happened outside the Bell Labs since the 80s.

                        Anon, you sound like someone who hasn’t worked with go

                        I haven’t used it professionally, but I spent some time trying to learn and use it back when it was all the hype. Too bad I already knew Haskell, C++11 and C# 4.0 by that time, so Go surprised me by being so badly designed. Nowdays we have Rust, Kotlin and C# 9.0, and Go is only getting generics.

                        >the lack of generics in a post-2000 compiled language
                        What does being compiled have to do with it?

                        >error handling
                        Should be called "result handling", because most non-nil error values don’t indicate erroneous states, just results. You do check results, don’t you? You do work with varying situations that can arise? You don’t just catch everything in a big handler and report a fatal error if a freaking config file doesn’t exist, do you?

                        I don’t understand why you’re whingeing that Go isn’t C#, Kotlin or Haskell.

                        > What does being compiled have to do with it?
                        I should have said "statically-typed language", right. I can excuse a new dynamically typed language not having generics, not a statically-typed one.
                        > You do check results, don’t you?
                        Do you tho? Because in Go it’s all to easy to ignore erroneous results and keep going, something you just can’t do in a language with exceptions or in Haskell/Rust. In other words, using return values to return EITHER result OR error is fine, but only if the language have sum types to enforce the "EITHER .. OR .." part. In Go you have both at the same time, and it’s broken conceptually and asking for bugs.

                      • #129253
                        Anonymous
                        Guest

                        >best practices
                        shut up pajeet
                        >The Go designers practically ignored everything that happened outside the Bell Labs since the 80s
                        repeating this sort of meme (and it is a meme, you’re probably regurgitating someone else’s opinions) is why i say you’re in the dunning-kruger trough
                        perhaps – perhaps – go and haskell are, in fact, focused on different use-cases and different research
                        also, there has been very little development in computer science since 1968
                        god i just can’t be bothered anymore fuck this

                        c# is super easy and straightforward to read. one of the most simple languages to undesrtand actually. You can open any C# repo and be able to follow the code immediately.

                        You can’t say that about go. The lack of expressiveness and spaghetti-like code make it look almost like high level assembler.

                        lol c# doesn’t even treat concurrency as a first-class citizen. zero expressiveness on that front.

                      • #129255
                        Anonymous
                        Guest

                        > perhaps – perhaps – go and haskell are, in fact, focused on different use-cases and different research
                        But Go and Kotlin, C# 9.0, C++20 and Rust are not.
                        > there has been very little development in computer science since 1968
                        And you’re the one accusing others of dunnign-kruger, the irony.
                        > c# doesn’t even treat concurrency as a first-class citizen. zero expressiveness on that front.
                        C# have async now.

                      • #129258
                        Anonymous
                        Guest

                        >And you’re the one accusing others of dunnign-kruger, the irony.
                        list 20 significant developments in computer science since 1968
                        should be easy
                        >But Go and Kotlin, C# 9.0, C++20 and Rust are not.
                        lol what
                        >C# have async now.
                        a shitty subset of channel patterns. you can’t get more expressive than channel syntax, baby
                        >C# have
                        yeah you’re indian

                        why aren’t you complaining that forth isn’t a clone of C#? why aren’t you complaining that python isn’t a clone of haskell?

                      • #129260
                        Anonymous
                        Guest

                        >you can’t get more expressive than channel syntax, baby
                        goroutines are a subset of erlang processes

                      • #129261
                        Anonymous
                        Guest

                        goroutines don’t need names/pids so i’d hazard that it’s the other way around

                      • #129280
                        Anonymous
                        Guest

                        this.
                        CSP is more expressive than actor models and you can describe actor model in CSP terms.
                        https://www.quora.com/How-are-Akka-actors-different-from-Go-channels-How-are-two-related-to-each-other

                        CSP gives you plenty of footguns, see:
                        https://gist.github.com/kachayev/21e7fe149bc5ae0bd878
                        actors just work.

                      • #129262
                        Anonymous
                        Guest

                        > list 20 significant developments in computer science since 1968
                        Hindley–Milner type system was developed in the 70s, that alone is like 10 developments in one. Linear types, developed in the 2000s and implemented in Rust is another revolution.
                        > a shitty subset of channel patterns. you can’t get more expressive than channel syntax, baby
                        Wait, isn’t having no features means being "simple"? Why do you consider goroutines essential (even tho C#, Rust and Haskell have their equivalents), but generics and sum types – "unnecessary complexities"?
                        > why aren’t you complaining that forth isn’t a clone of C#? why aren’t you complaining that python isn’t a clone of haskell?
                        Because Go is explicitly presented as a statically-typed compiled "system" language geared for "backend". Thus I compare it with the likes and find extremely lacking.

                      • #129263
                        Anonymous
                        Guest

                        list 20, don’t cop out

                        >Wait, isn’t having no features means being "simple"? Why do you consider goroutines essential (even tho C#, Rust and Haskell have their equivalents), but generics and sum types – "unnecessary complexities"?
                        i’m not an academic wanker who wanks over sum types
                        concurrency should be a first-class citizen that is deeply integrated into the grammar and runtime for maximum expressiveness – like in occam, etc. evidently, go is a white working man’s language

                      • #129273
                        Anonymous
                        Guest

                        > list 20
                        I actually value my time not to waste it on your cheap rhetorical tricks. But the very fact you would ask such it is a great illustration of how illiterate a typical gopher is.

                        >I’m referring to the rest of the academia and the industry, gradually developing and adopting best practices. The Go designers practically ignored everything that happened outside the Bell Labs since the 80s.
                        For twenty years the idea that throughput is the most important metric for a GC was settled science, all major industry GC maximized throughput and heaps and heaps of academic papers relied on this assumption.
                        When go went with a low latency concurrent mark-and-sweep approach they were called ignorant, destined to fail, using obsolete approach from the 70s. They were ignoring 30 years of research! It turns out they were right and now every major GC has low latency as an option.
                        Back before Go was a thing everyone believed that to have easily portable systems you needed bytecode running in a VM, both c# and java did this and academia supported the approach. Turns out you can do it better with a good cross-compiler and no VM.
                        You are going to see something similar with package managers, everyone thinks the right approach is to reduce dependencies to a SAT problem, it’s well studied in academia and part of many important industry package managers, but if you look closely it rests on very shaky assumptions.

                        > They were ignoring 30 years of research! It turns out they were right and now every major GC has low latency as an option.
                        They actually were ignoring 30 years of research, JVM and CLR had low-latecy as an option long before Go showed up. And Go didn’t solve the basic tradeoff – low latency vs throughput – they just put the focus on the other thing for some cheap marketing "low-latency GC", resulting in shitty throughput. See https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.62yek82xg for context.
                        > everyone believed that to have easily portable systems
                        Since when Go does produce "easily portable systems"? How is it different than C++ or D? Hell, even Haskell could produce standalone binaries back in the 90s, and the libraries are mostly cross-platform.

                        All this got me thinking: if anyone have dunning kruger, it’s the Go designers, who are barely competent in all the aspects of modern language design and implementation, yet overconfident and dismissive about rest of the industry and the academia.

                      • #129275
                        Anonymous
                        Guest

                        >They actually were ignoring 30 years of research, JVM and CLR had low-latecy as an option long before Go showed up. And Go didn’t solve the basic tradeoff – low latency vs throughput – they just put the focus on the other thing for some cheap marketing "low-latency GC", resulting in shitty throughput. See https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e#.62yek82xg for context.
                        Also read the followup post https://blog.plan99.net/modern-garbage-collection-part-2-1c88847abcfd about newer low latency garbage collectors getting added to java after go approach proved superior.

                      • #129284
                        Anonymous
                        Guest

                        >go approach proved superior
                        must be superior spent all your cpu on allocations and low latency GC rather than performing user’s work

                      • #129286
                        Anonymous
                        Guest

                        >write a benchmark that utterly hammers heap allocations on one, but doesn’t on the other
                        >"BTFO!!!!!"

                      • #129295
                        Anonymous
                        Guest

                        Both do extensive heap allocations. That benchmark shows real go GC performance (protip: it’s shit).

                        >B-but muh latency
                        Literally doesn’t matter. It’s not that you write a game in go or something

                      • #129296
                        Anonymous
                        Guest

                        >Both do extensive heap allocations.
                        protip: simply doing allocations at some point is not the same as exerting GC pressure
                        the code isn’t equivalent. it doesn’t allocate in the same places. the author needs to read the escape analyzer’s annotations and stop writing deliberately stupid code

                        >It’s not that you write a game in go or something
                        yes i do
                        why’s your english so poor?

                      • #129298
                        Anonymous
                        Guest

                        binary-trees is a bad benchmark because it doesn’t normalize heap sizes. Notice how the go program uses less than a quarter of the memory.

                      • #129276
                        Anonymous
                        Guest

                        >I actually value my time
                        >this is why i’ve spent well over an hour getting mad at a language i don’t use

                        >here’ read this blogpost so i don’t have to formulate my own opinions through experience
                        >Since when Go does produce "easily portable systems"? How is it different than C++ or D?
                        lol confirmed for never using it
                        why do you babble on about shit you know nothing about?

                      • #129277
                        Anonymous
                        Guest

                        >Since when Go does produce "easily portable systems"? How is it different than C++ or D?
                        You must be joking. C++? Have you ever tried to cross-compile a C++ program?

                      • #129290
                        Anonymous
                        Guest

                        >I actually value my time not to waste it on your cheap rhetorical tricks.
                        I haven’t laughed out loud over text in so long. This caught me off gaurd.

                      • #129282
                        Anonymous
                        Guest

                        >>C# have async now.
                        >a shitty subset of channel patterns
                        typical gotard. don’t understand either

                      • #129285
                        Anonymous
                        Guest

                        func async() <-chan struct{} {
                        c := make(chan struct{})
                        go func() {
                        defer close(c)
                        c <- struct{}
                        }()
                        return c
                        }

                        func await() { <-async() }

                        func promiseAll() {
                        x, y := async(), async()
                        <-x; <-y
                        }

                        func promiseRace() {
                        select {
                        case <-async():
                        }

                        you’re done
                        you can’t get more expressive than this

                      • #129266
                        Anonymous
                        Guest

                        >I’m referring to the rest of the academia and the industry, gradually developing and adopting best practices. The Go designers practically ignored everything that happened outside the Bell Labs since the 80s.
                        For twenty years the idea that throughput is the most important metric for a GC was settled science, all major industry GC maximized throughput and heaps and heaps of academic papers relied on this assumption.
                        When go went with a low latency concurrent mark-and-sweep approach they were called ignorant, destined to fail, using obsolete approach from the 70s. They were ignoring 30 years of research! It turns out they were right and now every major GC has low latency as an option.
                        Back before Go was a thing everyone believed that to have easily portable systems you needed bytecode running in a VM, both c# and java did this and academia supported the approach. Turns out you can do it better with a good cross-compiler and no VM.
                        You are going to see something similar with package managers, everyone thinks the right approach is to reduce dependencies to a SAT problem, it’s well studied in academia and part of many important industry package managers, but if you look closely it rests on very shaky assumptions.

                      • #129267
                        Anonymous
                        Guest

                        cont: the root of the problem is that academia works through peer-review and doesn’t like reexamining fundamental assumptions because it oftens entails calling everyone of your peer reviewers scrotebrained. A lot of things that have been done in the past 30 years happened because they were in the path of least resistence, not because they were sound science.

                      • #129269
                        Anonymous
                        Guest

                        >Back before Go was a thing everyone believed that to have easily portable systems you needed bytecode running in a VM, both c# and java did this and academia supported the approach.
                        hah, true, they were ignorant of plan 9

                      • #129278
                        Anonymous
                        Guest

                        go was right again
                        woke af

                      • #129281
                        Anonymous
                        Guest

                        >For twenty years the idea that throughput is the most important metric for a GC was settled science, all major industry GC maximized throughput and heaps and heaps of academic papers relied on this assumption.
                        are we ignoring Erlang much?
                        who do you think ran your telecommunication systems?

                    • #129245
                      Anonymous
                      Guest

                      Anon, you sound like someone who hasn’t worked with go

                    • #129246
                      Anonymous
                      Guest

                      >the lack of generics in a post-2000 compiled language
                      What does being compiled have to do with it?

                      >error handling
                      Should be called "result handling", because most non-nil error values don’t indicate erroneous states, just results. You do check results, don’t you? You do work with varying situations that can arise? You don’t just catch everything in a big handler and report a fatal error if a freaking config file doesn’t exist, do you?

                      I don’t understand why you’re whingeing that Go isn’t C#, Kotlin or Haskell.

                    • #129252
                      Anonymous
                      Guest

                      c# is super easy and straightforward to read. one of the most simple languages to undesrtand actually. You can open any C# repo and be able to follow the code immediately.

                      You can’t say that about go. The lack of expressiveness and spaghetti-like code make it look almost like high level assembler.

                      • #129254
                        Anonymous
                        Guest

                        Way to out yourself

                  • #129248
                    Anonymous
                    Guest

                    >The way it handles slices
                    >array = append(array, item)
                    ah, yes, the scrotebrained and error prone way

                    • #129249
                      Anonymous
                      Guest

                      what?

                      • #129257
                        Anonymous
                        Guest

                        Would you enlighten us?

                        you *can* mutate slice’s underlying array in another function, *but* you cant change the length, capacity of slice, because slice stored on the stack. this is bad design, very confusing and easy to make mistake

                      • #129259
                        Anonymous
                        Guest

                        >*but* you cant change the length, capacity of slice, because slice stored on the stack.
                        slices are stored wherever the compiler puts them following escape analysis, ESL. also, what you said doesn’t even make sense
                        >easy to make mistake
                        jesus wept, ESL

                      • #129265
                        Anonymous
                        Guest

                        I really dont understand what you meant, but I’ve yet to see anyone make this "easy" mistake.

                    • #129250
                      Anonymous
                      Guest

                      Would you enlighten us?

              • #129237
                Anonymous
                Guest

                >We actually need complexity in the language because it hepls write more safe and simple code
                C++ scrotebrains use the same argument.
                It’s only true in the hand of experts.
                Everyone else will shoot themselves in the foot.

                .NET tries to counter that with over-engineered enterprise abstractions which actually make C# less expressive than Go: do what your framework tells you or else.

      • #129239
        Anonymous
        Guest

        it’s over a decade old and it’s not going away

        because when i use C# i never think "this is neat", "this is handy", "this is nice to use", "this is useful", "this is an enjoyable experience". all i think is "this freaking reeks of shit and curry"

    • #129197
      Anonymous
      Guest

      Hope so. I use it at work and i feel dumb everytime because it was made for the lowest common denominator(non whites)

    • #129225
      Anonymous
      Guest

      Pests never stood a chance.

    • #129227
      Anonymous
      Guest

      It’s here to stay just like COBOL, Java and PHP are here to stay, they’re too big to fall.

      Yet with Google endorsing actually good languages like Kotlin and Rust the mystique of "the Google’s language" will wear away and people will see Go as it is: a shitty outdated language, badly designed by senile unix """philosophy""" fanatics for millions of uneducated pajeets to use.

      Even today it’s already more of an embarrassment for Google, they try to fix it with generics, but it will only create a monstrosity worse than C++.

    • #129231
      Anonymous
      Guest

      Another Flutter shill thread. Flutter freaking sucks and performs bad.

      • #129238
        Anonymous
        Guest

        >Another Flutter shill thread.
        What did they/then mean by this?

    • #129247
      Anonymous
      Guest

      Never start a goroutine unless you know how it will stop, bros.

    • #129256
      Anonymous
      Guest

      well I just got a job writing Go so I hope not

      • #129289
        Anonymous
        Guest

        What do you do? REST-API stuff?

    • #129264
      Anonymous
      Guest

      I’ve noticed that everyone who gets obsessively angry about Go is a blithering idiot. What gives?

      • #129297
        Anonymous
        Guest

        I’ve noticed that everyone who gets obsessively angry is a blithering idiot.

    • #129268
      Anonymous
      Guest

      It’s a programming language that has no point of existing.

      • #129270
        Anonymous
        Guest

        then why reply?

        • #129272
          Anonymous
          Guest

          Question asked:
          >Is it here to stay or will we see it on killedbygoogle.com eventually?

    • #129287
      Anonymous
      Guest

      I’ve written Go professionally for >5 years, some basic thoughts:
      – Go is by far the easiest language to read. I can jump into a large Go codebase, and easily understand both the high level design and low level implementations. Contrast this to C++ or Java, where everyone has their own pet ways of doing things that you need to figure out.
      – Beginner friendly, shallow learning curve. I can delegate things to junior devs without needing to hold their hand.
      – Std lib is high quality. The vast majority of software projects can be completed by just glueing together parts of the std lib.
      – Ergonomic concurrency primitives. Channels, select statements, and goroutines are both simple and powerful, and I consider them best in class.
      – Fast compile times and performance GC. For non-perf critical code, it’s nice not to have to think about memory management.

      There are definitely gotchas and some warts (although surprisingly few for a 10+ year old language). Lack of generics, no enums, and ‘verbose’ error handling is annoying, but writing is Go is generally pretty comfy. For the most part, the code gets out of the way so I can focus on high-level API design, which is far more important to the success of a big/complex software project.

      • #129288
        Anonymous
        Guest

        enum -> const

      • #129292
        Anonymous
        Guest

        +1 on the standard library. It’s really really good. Would you recommend Go for someone who has never had a dev job but would like to enter the field?

        • #129294
          Anonymous
          Guest

          Absolutely. Go is a really easy language to pick up; even for complete beginners, I recommend it over Python/Java/Javascript/etc. But it’s also really performant and powerful, so you won’t grow out of it anytime soon. There’s also loads of Go jobs available now, many companies are rewriting a bunch of legacy software in Go.

          • #129299
            Anonymous
            Guest

            I’m a C# dev and Go looks sexy af. Very straightforward.
            I love to automate stuff and use cli and it looks like a performant Python.

    • #129291
      Anonymous
      Guest

      as long as cloud and web development exists, so does golang

    • #129293
      Anonymous
      Guest

      >Youtube VR EASILY
      stopped reading there

Viewing 15 reply threads
  • You must be logged in to reply to this topic.