- This topic has 111 replies, 1 voice, and was last updated 7 months, 2 weeks ago by
.
-
Posts
-
-
Is it here to stay or will we see it on killedbygoogle.com eventually?
-
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
-
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.-
>if fuschia becomes successful
big if -
Different use cases.
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.
-
>all Google needs is full compatibility with current Android Linux and done.
yeah, good luck with that.
-
-
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.
-
-
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-
Flutter is great. Hope Apple accepts it one day and becomes better for ios.
-
why would Apple fix Flutter’s bugs on iOS?
https://github.com/flutter/flutter/issues/61450-
This has been solved and was never really a problem
-
-
-
-
-
it was dead on arrival
-
>27057
No it will not killed by google. Sorry.It won’t get killed by google. Stop freaking.
-
-
Rust will be seen there eventually
-
What I don’t understand is why people choose go over c#
-
OOP hate I guess
-
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-
>Oversimplified = good
Ok now write your 10th for loop for shit that every reasonable language has higher order functions for-
it’ll use exactly like one line more at the end and be ten times easier to read.
-
>Easier to read
If you are scrotebrained maybe-
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.
-
I dont use c#. I use typescript and golang at work and switching from typescript to golang makes me puke
-
oh, ok, your opinion is fully invalid gotcha
-
interface{} says otherwise
-
not an argument
-
>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 -
>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 -
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
-
>I KNOW THE TYPES
>wants genericslmao what’s type erasure
-
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?
-
>talks about compile time type checking
>talk about generics and having to add runtime type checkingtiresome
-
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
-
this isn’t Java.
there’s no type erasure in Go. -
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.
-
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. -
[…]
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
-
you know how many Go libraries use codegen?
you think codegen is more idiomatic than generics? -
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.
-
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.
-
are you saying you want hygienic macros in Go?
-
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.
-
-
-
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.
-
-
dumb scrote shut the fuck up
-
no
-
-
-
-
-
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.-
>Filter, map, reduce chains are the midwit of programming.
Filtered by filter. Absolute disgrace.-
I was probably using mappend in lisp before you were born. One day you will get it.
-
-
-
-
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-
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-
>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 cWe actually need complexity in the language because it hepls write more safe and simple code
-
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.
-
>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.-
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.
-
you’re in the dunning kruger trough
-
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.
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. -
>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 thisYou 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.
-
> 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. -
>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 indianwhy 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?
-
>you can’t get more expressive than channel syntax, baby
goroutines are a subset of erlang processes -
goroutines don’t need names/pids so i’d hazard that it’s the other way around
-
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-otherCSP gives you plenty of footguns, see:
https://gist.github.com/kachayev/21e7fe149bc5ae0bd878
actors just work. -
> 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. -
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 -
> 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.> 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.
-
>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. -
>go approach proved superior
must be superior spent all your cpu on allocations and low latency GC rather than performing user’s work -
>write a benchmark that utterly hammers heap allocations on one, but doesn’t on the other
>"BTFO!!!!!" -
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 -
>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? -
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.
-
>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? -
>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? -
>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. -
>>C# have async now.
>a shitty subset of channel patterns
typical gotard. don’t understand either -
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 -
>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. -
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.
-
>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 -
go was right again
woke af -
>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?
-
-
Anon, you sound like someone who hasn’t worked with go
-
>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.
-
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.
-
Way to out yourself
-
-
-
>The way it handles slices
>array = append(array, item)
ah, yes, the scrotebrained and error prone way-
what?
-
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
-
>*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 -
I really dont understand what you meant, but I’ve yet to see anyone make this "easy" mistake.
-
-
Would you enlighten us?
-
-
-
-
>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.
-
-
-
-
-
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"
-
-
Hope so. I use it at work and i feel dumb everytime because it was made for the lowest common denominator(non whites)
-
Pests never stood a chance.
-
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++.
-
Another Flutter shill thread. Flutter freaking sucks and performs bad.
-
>Another Flutter shill thread.
What did they/then mean by this?
-
-
Never start a goroutine unless you know how it will stop, bros.
-
well I just got a job writing Go so I hope not
-
What do you do? REST-API stuff?
-
-
I’ve noticed that everyone who gets obsessively angry about Go is a blithering idiot. What gives?
-
I’ve noticed that everyone who gets obsessively angry is a blithering idiot.
-
-
It’s a programming language that has no point of existing.
-
then why reply?
-
Question asked:
>Is it here to stay or will we see it on killedbygoogle.com eventually?
-
-
-
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.
-
enum -> const
-
+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?
-
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.
-
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.
-
-
-
-
as long as cloud and web development exists, so does golang
-
>Youtube VR EASILY
stopped reading there
-
- You must be logged in to reply to this topic.