It just works: the language

>the fuck is that supposed to mean. PHP is like the biggest web dev language in existence ever.
>How is Go "huge" if it is smaller than just about every other mainstream language out there?
Can you read? Can you comprehend what you are reading?

I think the point is that it's huge for a new lang, it has massive momentum behind it. Ruby or Java or C# had nothing like this.

>Rust
>great
No it's pure autism

It's impossible to use anywhere, but it is a great language.

deprecated ass PHP 5.6 is destroying actually supported versions of PHP. Growth is what you measure, not legacy.

C# was huge it just was designed for a dying market.

I didn't mean it was successful. I just meant that it had some success in terms of adoption.

It certainly isn't huge compared to languages like C, Python, or Java. But it has been used in a lot of major projects such as Docker, Kubernetes, InfluxDB, just about anything from Hashicorp, etc... I don't think it will ever get as big as say Java or Python, but I could see it having somewhat widespread adoption. I think people will realize it doesn't really offer much to warent using it over much more mature languages.

It's good. It cherry picks many of the most utilitarian aspects of other languages and pairs it with an excellent standard library, the easiest cross-compilation I've ever encountered outside of Plan 9, the easiest package retrieval I've used, and reasonable compile times.

It's a workhorse and I don't mind that it doesn't have generics and has repetitive error checking, because of the aforementioned shit.

I'm just disappointed it can't be used in realtime applications where the guaranteed 10ms maximum GC latency is still too much, like audio with a small buffer.

>impossible to use anywhere
works fine on any recent linux distro
it's fine, its fucking fast too.

C# was and still is bigger than Go.

>Let's take the worst aspects of C, the worst possible implementation of OOP, Garbage Collection, Type safety that ends at containers and a shitty thread pool with tasks with a fancy name (Goroutines) that's implemented into the language for some reason and BAM, Go

Gee, I sure wonder why it sucks.

Garbage collection means Go is only competing with Java.

Attached: 1539877333329.jpg (763x616, 83K)

Rust is fast but it doesn't use any known programming idioms, you can't go read a book on how to write idiomatic rust because they still haven't written them yet. Is it competing with C? no because C is a language for babies (of the 80s) and literally anyone could do it (badly). Is it competing with C++? Not yet, it can't optimize anything at a low enough level because of hard dependency on jemalloc. Is it competing on embedded? No it doesn't fit on embedded. Is it competing on servers? No, nobody uses it. Is it competing in user-friendliness? lol
Is safety important? Look at how popular Ada is.

You can tune/disable GC in go just fine, it's there to make sure babies can use the language. Go isn't C-like, it's python/lua like with C-style-syntax and a compiler. Practical C is like 70% preprocessor and that sort of thing is nowhere near go.

>there are no try-catch exceptions in Go, check errors explicitly
The reason why C++ is so damn unstoppable is because it's an unopinionated Swiss Army knife.

Okay.

Attached: autohue.jpg (640x480, 61K)

B-but muh generics :^(

It's barely faster than Java and is actually slower than Java in some cases. And to make matters worse, when it is faster than Java it is just barely faster. But in many if the cases where Java is faster, it is significantly faster.

See
benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html

go2 has try-catch in the vein of Rust's.

Waaah why me FFI not fast???

Generics when

Go has generics. They're awful.

When your benchmark shows like a 5000% difference in something your measurements are broken/useless. The rest are pretty reasonable. Java isn't slow, good enough performance is good enough to do a majority of shit before resorting to high-skill options like GC tuning or FFIs. Go really competes with python, not java, and BTFOs it.

Go 2 will be out in 2019 or 2020

Attached: 7t1p88ct13ez.jpg (640x996, 86K)

>Rust
Programming in Rust is like pair programming with somebody that has autism and OCD.

So all the Go being written now will be obsolete in a year or two?

my guess is for real world, long running programs java will destroy go since it has the worst GC in widespread use

I just read the source of the last test and it's written in a way that would obviously cause structures to escape to the heap in a tight loop. FUCKING retarded. I doubt the C it's translated from calls malloc in a tight loop.

it's just a different type of GC, optimized for their tiny ass goroutines. Golang is aiming to take the top concurrent programming language title early.

In a sense. That's the point where they're free from the compatibility guarantee. But this is Go, they'll probably include a tool to automatically update code like they did when Go 1 came out.

if anybody who is non brainlet and reading this, Rocket (written in Rust) is the most innovative and elegant web framework you will ever see, it is still very premature but the amount of innovation in it is already amazing

rocket.rs/

"different type" meaning state of the 1970s like all of go

This isn't a thread about Rust, you tranny faggot.

What's so innovative about it?

>write fast web applications without sacrificing flexibility or type safety
the nth web framework nobody asked for

blog.golang.org/go2draft

youtu.be/6wIP3rO6On8

It's tuned for a specific type of cheap throwaway allocation, it has the capabilities to adjust stack on the fly but that's expensive because it's not how you're supposed to do things. That one specific test made sure everything was expensive for that model.

I said non brainlets, brainlets

What's so innovative about it?

There's always tons of Rust threads, why don't you go post in them? I don't even know why this thread exists, probably just bait for shitposting.

if you are non brainlet you will understand, I won't waste time arguing with a retard

Nobody's really complaining about golang itt though, there's not a lot of complaints you can have except
>It's not C but it looks like C why am I confuse?

It's an absolutely O K A Y language, just like java was only in this century. Green threads are a great way to go for concurrency shit. Not much can compare with that natively.

Why is JUST always brought up in go threads?

See, the Rust community will always remain relatively tiny because you're all mentally ill faggots and abrasive.

I guess there's nothing innovative about the framework after all.

I haven't looked at the source of the last test so I will have to take your word on it until I look through the source myself. That said, Go is notoriously shit when it comes to Regex. I'm not sure how much I trust the site but it's findings seem to lune up with what a lot of other people have found.

Regex is notoriously shit everywhere though, it's not very idiomatic go code so why would it be performant? What you're supposed to do is for loops nested in if/else statements.

Fair enough. I think it really speaks more to how well optimized and fast the JVM / Java has gotten over the years than to how slow Go is for a compiled language.

My guess is the opposite because:
1. Go is the only language in its class that got value types right, in a way that encourages limiting allocations when coding in a natural style
2. Latency optimization actually makes a lot of sense in a world where CPUs don't get faster but you get more of them

I just find it weird that it is so slow compared to the rest of Go, especially when you consider how useful and widespread Regex is. It also can only do a limited set of Regex while still being very slow which just adds insult to injury.

k-nucleotide: this is a hashmap benchmark. Java is faster because, for some reason, they allowed in an implementation using custom hashmaps instead while go is only allowed to use the one in the standard library

regex-redux: go regex are slower but have better asymptotic performance

binary-trees: Java is faster but uses more than twice as much memory, Go programs tuning the GC have been rejected, the gap would be much smaller otherwise

The one thing it does better than Java is producing actual, native binaries.
You don't need to tell users to download some shitty runtime with at least 8 different versions that are often incompatible with programs that target a different version.

Then again, you get the Go runtime embedded in your binary and that's why even Hello world produces a massive binary in Go.

I dunno, go's strings are c-like enough that I never really attempt a regex. Of course unicode is still an awful mess that should never have happened, fighting runes happens sometimes.

The portability of the go compiler is a first class feature too. No need to adjust for various subsets of the language like java.

I like Rust a lot, especially the fact that the compiler helps steer you towards sustainable code. Lifetimes are weird because I don't think they're present in any other language. It would be cool if a language like C++ had a compiler that gave you hints and guarantees like Rust's, but that would probably require adding something like lifetimes to the underlying language.

Fair points. I didn't look through the source of all the tests so I didn't catch that. It kind of seems like that site has an agenda aginst Go from what you describe.

>As much as I want to like it, it just feels like a poor man's C and makes me want to just program in C instead
Well it's a good thing no one cares about your opinion.

I don't think it does. It's just what happens with microbenchmarks.

we'll see if it hangs around, doesn't seem like many golang rewrite blog posts like a few years ago

>I will have to take your word on it
It's like 50 lines. The biggest offender is this:

for i := 1; i Go is notoriously shit when it comes to Regex
As far as I know, the regexp package is just re2 implemented in a different language. So, as far as I know, it's a discrete finite automaton designed to work fine in certain pathological cases where PCRE et al suddenly take years to complete a search. But as you see, that approach is not the fastest in all cases.

>but it's findings seem to lune up with what a lot of other people have found
Bullshit. You'll see people with a grudge claiming Go in itself is slow as molasses. Such people never used it anyway. Go is plenty fast for me, and I'm utterly autistic about program speed, and garbage collection stutters frustrate me to no end.

Lifetimes are a truly innovative idea. You rarely see ideas as novel. That said I never ever want to use them. Hopefully someone will make a version of the borrow checker that gives you 70% of the benefits for 20% of the autism.

B T F O

That site has an agenda supporting retardation.

It's good that go's developers are personally distressed by 2MB binaries, at least. They're always going to be bigger than desirable, but there's always impetus to whittle them down.

The whole point of binary trees is to benchmark the garbage collector. That's why the code looks like that. If I ran that benchmark page I would exclude languages without GC from it (because it measures a fundamentally different thing for them) and I would use a CPU/memory_use as metric. As it stands it's encouraging implementors to gobble up as much memory as possible (the more memory you allocate, the fewer times the GC needs to run, the faster the program runs).

If the point is to exercise GC, then there should be statistics for throughput and latency.

The Java code also has a construct in the same place that would cause all the same escapes to heap, except perhaps escape analysis in Java is now so intelligent that it can eliminate the escape.

Actix is better

>not using actors for separating concerns and avoiding the problems of multithreading

Can't make games in Go (because of the terrible GC) which is all I care about outside of work

lrn2pool

golang is usless outside cloud and webdev

you have to give google some credit for developing a language for retards
i mean have you ever tried to think like a retard
shit's hard
it's a genuine accomplishment

Everything made by Hashicorp is written in Go. Their developer conference is happening in San Francisco this week.

What I love the most about deploying Go software to production is that it is not a voodoo dance. 99% of the time it's a single self contained binary that requires me to install zero dependencies (works on AMI and GCE images out of the box). Put that shit in a bin folder, set permissions, create the config, create the service, done.

They write everything in Go except Vagrant.

I get the convenience of Go's portability. It just seems like they went about it in a ham fisted way via static linking. Even compared to a C binary that was statically linked, Go's binaries are pretty huge. I think with tools like Docker, CI/CD, and better package managers, there are better tools to address portability than just static linking everything. Static linking just seems like trading one set of problems for another.

Attached: 1523477546241.jpg (337x367, 23K)

Does Go usually compile fat binaries for multiple platforms?

>99% of the time it's a single self contained binary
kek, isn't it ironic that the language that is championed by devops and container apps is being praised that it produces a self contained binary? if everything now is dockerized into a self contained image, this shouldn't be even considered as an advantage despite being so

What are you talking about? "Idioms..." You sound like an awful programmer to rely on "idioms."

The common argument is that if it's a single self contained binary with zero or minimal external dependencies then there is little reason to use a container...proceed like you have for the last 30 years.

But I live in a world where devs install the "isEven' npm package globally then complain when their Dockerized app magically doesn't work.

They aren't that fat when compared to C that was compiled with static linking. Its just that Go uses static linking and that is how it gets its tauted portability. What I don't get is how static linking has pretty much accepted as a bad idea and is rarely used compared to dynamic linking. But for some reason, Go get a free pass on this. Plus, now they are things like Docker that make this advantage of Go somewhat mute.

Attached: 1515338263156.jpg (720x960, 98K)

Sorry, wrong picture.

Attached: dlogo.png (1024x778, 76K)

GNU/Linux "tooling": Go or Python?

Common recurring patterns are inevitable, not some magic technique. There's a lot of Rust only rules that can't carry over from any other language.

literally who?

go tooling's medium-good everywhere, python's is bad everywhere, plus you have 2 copies for python2 and python3

The O'Reilly book is pretty damn good

If they really change things as drastically as they're discussing, it will end up like python 2/python 3.

lifetimes are new because rust is the first language that has neither a GC nor an expectation that the programmer manager their own memory.

Comprehensive list of things Rust can do but not C++:
*tumbleweed*

You actually can make games rather easily, all you need is to make sure you don't dynamically allocate anything during gameplay, which is what real game engines usually do anyways. Thus, even if memory collection triggers during gameplay it doesn't do any work. And even if it did it would be a nonfactor as game engines as large as UE4 still get away with using GC (although it's specifically tailored for their needs).

>literally who?
The secret best statically typed multiparadigm GC language, that's who. D is like Go, but with generics, Kotlin, but without the JVM shit, Crystal, but mature, Nim, but withBetter_syntax, Swift, but it actually gives a fuck about Linux, BSD and Windows.

How about Chapel?

>you can't go read a book
the books are still being written, in the meantime you have good old fashioned code review, articles, talks, compiler warnings and explanations, projects like clippy, etc
there's less emphasis being put on idiomatic rust while the language is still so young because idiomatic errors don't lead to severe security issues like they do in other languages
>it can't optimize anything at a low enough level because of hard dependency on jemalloc
it's not a hard dependency, rust is also one of the few mainstream languages that can match c/c++ in performance and yet here you are saying it's too slow, fuck everybody who isn't handwriting and optimising asm I guess
>Is safety important?
look at how popular books on writing safe idiomatic c/c++ are, look at newer c++ standards which are emphasising safety, look at the decades of research and development into safer languages
you can't seriously ask with a straight face whether security is important, even rhetorically

Attached: 1540250966990.png (948x539, 114K)

I don't think Chapel has a community.

>Rust is only 3 times as slow as C/C++
Great! It's a little faster than Python, good job, do you want a participation trophy?

It doesn't actually matter whether a language "has a community." What matters is having the lowest-friction way to write code that compiles fast and runs faster. Can Chapel do that?

What is your use case?

lol faggot

Uh, writing code. What were you imagining?

>python is as fast as c/c++
wtf I love python now

Attached: 1540253519934.png (973x545, 109K)

Go is going to be the new Java. Using OO for modularity is simply too much boilerplate to accomplish something simple. When you use a language like Java or C# you have to put all your code into classes. All those classes have to be instantiated to be used no matter how simple or insignificant the task. Too much time is wasted figuring out how to spread tasks out into classes. Interfaces in Go serve as a much better way to modularize code. Go forces all code into modules so you can't make global code to float around freely and fuck up scope. When you write code in Go you actually spend all your time on the task at hand and not trying to figure out which OO pattern you have to use, and if you guess wrong refactoring OO is a needless pain. Smart companies are going to switch to Go when Java kicks in their paid Java JDK, only the idiot code monkeys are going to keep clinging to Java.