GO Programming Language

What frameworks do people use? I hear Gin thrown around a lot.

looking like C doesn't make it perform like C. It doesn't even beat C++.
benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html

if err != nil {
log.Fatal(err)
}

Error-handling is abysmal tho

another failed c++ replacement that failed into webdev

you are right, it's not nearly as fast, but still, it's FAST.
also, some of the Go code uses C code, which use different calling conventions, and so it's much slower.

mate, have you seen the amount of non-web-related projects that use Go?
here, have some examples: github.com/topics/go

this.

you can, with high accuracy, know what the person pulling this up does not program in C

this

Go is supposed to be an improvement over C, why wouldn't you go with arguably better styles of error-handling like Python does for example? No trying to hate on Go, I actually like the language. Typing if err != nil all the time is exhausting however

what's the point of golang

1) front end web shit: typescript
2) back end web shit: java
3) back end wang blowing web shit: c#

anything else is just hobby programming.

where is it supposed to go in that stack?

>2) back end web shit: java
>3) back end wang blowing web shit: c#
less performant, not multi-threaded, concurrency-by-default langs.

also see github.com/topics/go

As a dude that only ever programed in Python I find this very nice, specially the final binary, so fucking clean, no need to install a bunch of legacy pip shit just to run, etc.

You don't really need frameworks for most thing. They're at most sugar, and pretty much any feature you'd want out of them is already in the standard library.
Where Go's language is very simple and bare for simplicity's sake, its standard library is very comprehensive.

>less performant,
it's considerably slower than c++
benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html

so there's no point in using it for drivers

it's only marginally faster than java
benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html

so there's no point in adopting it for services

>not multi-threaded, concurrency-by-default langs.
that doesn't really mean anything. java has a really powerful threading API if you know what you're doing. if you don't, you can always just make a parallel stream.

if you take "concurrency-by-default" lang to mean "we have concurrency keywords," then that's just stupid.

(I used this as a reference for my opinion: golang-book.com/books/intro/10)

that's what a hobbyist would say

further evidence that it's a pleb language.

Go was a pretty disappointing experience and left me conflicted.

One of it's goal as stated by creators is to development straightforward and simplify decisions around the codebase. Which is mostly true, probably a big aspect of its success.
There is tons of tooling shipped with the language such as code formatted (and I don't mind it being opinionated, maybe because they picked up the style I already used), code analysis tool, tracer and profiler, thread sanitizer, documentation tools, testing tools and actually good test runner (unlike python), benchmarking.
Where this didn't work out was the dependency management - which lead to bazillion 3rd party tools, which was what they stated to avoid.
Plus removing bunch of C's legacy parts is instant improvement. C++ did not do it and look how well it rots in it.
But the amount of retarded shit the language throws on you is enormous.Low hanging fruit is the errors on shits like unused variable and that tt enforces quite opinionated directory structure. Also there are some inconsistencies with visibility depending on how you try to compile the project which is annoying.
The standard library ships indeed much more than one was used to. But there several spots where the proposed API is unusable - image, sort, time packages, the Reader/Writer interfaces get very messy often.
Pike is unironically proud of the := operator, while it's poorly copied `name : (type) = expr` syntax.
Array gymnastics and fucky aliasing.
defer pitfalls and ending up being unusable feature
Contrary to what the devs try to sell, it compiles slowly and doesn't produce truly standalone executables.
It's slow. If you compare it to toys that somehow got popular like Python/Ruby then it's not that bad, but it doesn't stay a chance in high performance software.
Encoding and regex implementations are slow.
Compiler produces slow code.
Interface types forces many objects to be allocated on heap.
Data structures use dynamic dispatch and fuck up cache alignment.

Go is a mistake for anything beyond toy web severs. Everything about the language is designed around coddling poor programmers by limiting what they can do and how they can organize their projects.

It isn't even that remarkable at concurrency, it gives you co routines, channels and a built in scheduler; all things which are available in more sophisticated forms in any modern language. Detecting hard deadlock is an almost laughable non-feature, its easy to tell when everything stops working. A useful feature would be detecting race conditions, like in Rust, but that would make the language too complicated for the average gopher.

The performance of the C interface is, ironically, also abysmal compared to pretty much any other language
github.com/dyu/ffi-overhead

>how easy it is to do proper and safe multi threading
Go doesn't do this though. It doesn't even have proper threads afaik, just coroutines.

Go's concurrency model is shit because it still allows for shared memory and potential for race conditions. It's concurrency is also very limited because you have to use channels to communicate and you can't send messages to any arbitrary goroutine. Error checking and handling is also primitive and repetitive.

If you want a good concurrency language, you should use Erlang. Actual good actor based model for concurrency, has a much better error handling system, has supervisors which allows restarting failed processes, doesn't share memory at all with it's concurrency model, all data is immutable for better program correctness, has pattern matching, better tools to deal with side effects, and has hot-reloading which enables you to update code while it is still in production without having to kill any currently running processes.

Attached: squid-concurrency.png (566x619, 109K)

The way Go's threading works is M-N multithreading, which means it has M green threads mapped to N kernel threads.

>Python
Stopped reading right there.

Attached: pepe stop.png (446x435, 70K)

This a concurrency model, not a threading model. You have little to no control over how and where go routines are scheduled. Which is fine for web servers, but unhelpful when you want more control, like implementing your own scheduler on top of kernel threads.

>prolang
Stopped reading there

very comfy language, ignore dumb neets in this thread. Very readable, comes with pretty good tools, some good libraries. Doesn’t have generics tho, error handling is ass

just “Go" for it haha ;)

>if you take "concurrency-by-default" lang to mean "we have concurrency keywords," then that's just stupid.

Java has not CSP derived concurrency

>why not something 100x slower than both Go and C

Gee I wonder why.

but go was meant for web servers

>performant
that's not a fucking word brainlet
erlang vm is low latency and fault tolerant, not fast

is gin even up to date? i havent checked in 6+ months but gorilla libs or chi libs are good. buffalo is what you want if you want a 'framework' like rails, etc., but if you are going for apis i would go with something else

>coroutines
t. i know nothing about concurrency & parallelism

race conditions are kind of an issue if you write bad code but yeah it could be better. shitty error handling is so much better than shitty exception handling though

>it's considerably slower than c++
no fucking shit. that's still pretty fast as far as most languages are concerned
>it's only marginally faster than java
who tf wants to use java

Google is a shitty spying company.

I wish I could make do without Android, the last google product I use.

Windows Phone was my last hope.

>windows phone
>replacement for spyware

You are too stupid to have a phone

I write go full time for wagiebucks
It's pretty comfy desu ngl

>You have little to no control over how and where go routines are scheduled
Look at how sync.Cond is implemented and what the runtime package allows for.

Not to mention you can always fallback to Cgo for something like this if you really want to replace the built in scheduler but also use Go syntax/tools/libs.

>who to wants to use java
At least it has generics

>doesn't even

that's not how transitivity works. C++ beats C.

C doesn't have vulnerabilities. It's the person that implements stuff that creates them

go.googlesource.com/proposal/ /master/design/go2draft-error-handling-overview.md

I honestly don't mind the current model though. People complain that it requires more code, but what is the alternative? Not handling errors? catch-all-and-die exception patterns?

If you find yourself having a giant cascade of error checking, maybe you should break that out into a separate abstractions and reconsider your patterns. The person talking about lack of C experience nailed it.
C doesn't force this but all good (fault tolerant) C programs are designed in the exact same way. I'd rather see bad programmers struggle and complain about this as they might learn something about design.

The Go2 proposal may be lexically shorter but the concept is still there.
Define specific errors, abstract routines, and check the errors of those routines.
This is no different than utilizing errno or boolean success returns.

Meanwhile in other languages
try {
8,000 lines
}
catch {
print("something happened, maybe it was fatal"}
exit()
}

It has syntax as limited as C wiyh none of the benefit of C. A language for people who can't grasp any modern programming concepts but can't be trusted with C.

what exactly is Python's error handling? None and exceptions?

Found the rust fanboy
They have had a race detector for a while blog.golang.org/race-detector

Go's greatest strength is its standards imo. C relies on defacto standards because it came from a vendored OS that shipped with the tools you needed.

Go works exactly the same on every playform, and almost every project.
go get -u DVCS-URI
Regardless of how the source is hosted, you will fetch it, regardless of opinions it will go into a standard hierarchical layout, regardless of platform the build system and compiler is the same. This extends to the formatting of the source code too which should be the standard for all languages since this makes machine parsing easier. Don't like the default format? You're in luck, let your editor parse the standard and reflow it easily however you want it.
The built in documentation tool godoc combined with the lexical rules of the language that is a god send. Automatic documentation whether the dev wanted to provide it or not.

C obviously has been able to do all of this since the beginning but none of it is standard or guaranteed portable.
>Hey check out my cool project that requires SYSV's CC binary, this custom bastard of a make system that only functions on Plan9, a visual studio plugin for formatting, and my python scripts that will not work for you to generate documentation that you probably want
>oh also I hope you know what lib-dick-ass is called in your package manager because that's what it's called in mine, maybe you should use the exact same distro as me if you want to compile this

Learning the C language isn't even 50% of what you need to be an effective C programmer, and I find that stupid. With Go you need to learn the language and that's it. You now have the ability to program on any supported platform, and work with anyone else on any project instantly. This is extremely powerful imo and the way it should be.

Go lacks any capacity for polymorphism. It doesn't have generics, classes, algebraic types, nothing. Instead you get the empty interface{}, which is basically no better than void*.

unironically I think C's error handling is good enough
FILE *f1 = NULL;
FILE *f2 = NULL;
uint8_t *buf = NULL;

f1 = fopen(...);
if (f1 == NULL)
goto clean;
f2 = fopen(...);
if (f2 == NULL)
goto clean;

... many lines of code that goto clean on error

clean:
if (f1 != NULL)
fclose(f1);
if (f2 != NULL)
fclose(f2);
if (buf != NULL)
free(buf);
return;

Since goto exists in Go, this is still possible.
defer is sometimes useless as it acts like closure and is only scoped to whole function
I would love a compound block with finally {} block that executes whenever flow exists the main block, but without exceptions, but it's not much cleaner nor shorted than goto error chain.

What's really lacking is static analysis. Mark the fclose function to have to be called after successful fopen and let the analyzer check if every possible branch results in such call. Overall good static analysis tools are lacking in every language.

You can specify methods on interfaces. The empty interface is just a common one that accepts any type. Interfaces along with embedded structs/interfaces gets you some polymorphism.

>which is basically no better than void*
it has runtime information about the type
which is precisely how objects work in Java and many OOP languages, but OOP is bad and clunky workarounds are good

> it's considerably slower than c++
no shit. But I wonder who's not sane enough to expose a microservice written in C++ to the interwebs.

>this is your brain on suckless

Not an argument.

why would I want to argue with a boomer? your brain has already calcified

Understand that this is a public forum where there are more readers than writers. You shouldn't assume everyone who replies to you is the same person either. It benefits everyone if you can make a solid argument for or against something. Even if the person you're arguing with doesn't budge.

There's no point in arguing against something obviously retarded.
It just validates the idiotic perspective, as something worth arguing against.

What's obvious to you is not obvious to all, and if it is obvious should be trivial to argue against.

The only thing it validates is your own perspective if affirmed.

Ridicule and natural selection is the way progress is made.
You don't make arguments against idiotic notions, you mock them and wait for the proponents to drop dead.

benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html
Just compare the memory usage.

We're in disagreement. I am of the opinion that discourse like this is beneficial to the majority at the cost of meager time. For instance this likely could have been resolved by now, and at least I myself would gain insight as to 1 pattern and its alternative(s), giving me a personal advantage in building software which may in turn benefit even more given the nature of it.

I should say too that it benefits you in that more people adopt what you think is correct, and I posit that not sharing this insight does not result in progress, but stagnation. Progress is transfer of lessons learned, not the retention of them, imo.

>back end web shit: java
End yourself

>no generics
>github.com/golang/go/wiki/SliceTricks
dropped

has nothing to do with suckless

The only criticism I see about Go is the lack of generics, but I haven't seen a case where they're required yet. People just say "ugh, no generics" they don't give an example, or if they do, people point out how to do it with interfaces or go generate with equal effort. I don't understand this complaint. It might be valid but I haven't seen it yet.

>but I haven't seen a case where they're required yet
Well I don't know, how but any fucking data structure.

Making a function to insert an element into a slice at a certain point. I really like go but its still annoying sometimes.

Attached: ______.png (650x650, 31K)

I honestly don't see a single use case where Go would be a good choice.
Convince me if you believe otherwise.

Web applications that scale?

Java or Scala

> C copycat
> designed by Ken Thompson himself
Imagine having 10 braincells, 9 of which are dedicated to autonomic breathing and pulse

I hear Gin an Beego are recommended. Did some exercise with Beego, was a breeze.

yeahh.... no. some functions are insecure by default, which require you to check arguments very carefully. there is no point in arguing here

>goto fail;
>goto fail;

>defer is sometimes useless as it acts like closure and is only scoped to whole function
>I would love a compound block with finally {} block that executes whenever flow exists the main block, but without exceptions, but it's not much cleaner nor shorted than goto error chain.

Wrap the block in a function and use defer. Defer is good but I still see tons of times where people use it in an infinite or long running loop.

One major issue with go is package versioning. Not that it isn't fixable. However some libs have decided to have the version in their package name. Not sure how or if vgo addresses this though.

This is the current experiment.
github.com/golang/go/wiki/Modules

Only time it has been an issue is for working with a list or map of types that implement an interface. []int can't be passed as []interface{}

>runtime dependancies

Attached: you.jpg (474x324, 31K)

Wow it really is, so you need to refactor your imports each major change?

I mean if you're using version locking, that's kind of the idea.

you can't even start Go binary on Windows unless you have the toolchain installed because it does a lookup for otherwise non-existing timezone info file

Why does it need your timezone?

>try {
>8,000 lines
>}
>catch {
>print("something happened, maybe it was fatal"}
>exit()
>}
You're retarded if you program like this. You only "try" code that might be prone to an error, but that doesn't mean you should put things like int a = 3 in a fucking try clause. Holy shit.

//code
try {
//important code that might have an exception
} catch {
//what to do if it fails somehow
}

Also you're retarded if you exit a program over a minor error, so the exit() statement makes no sense unless whatever happened IS fatal and would fuck shit up more if it continued.

That's what I'm saying.

source? I don't use Windows, and I had never seen/read about this happenning to anyone

my bad, it's just functions working with it, not the runtime init as I falsely remembered
github.com/golang/go/issues/21881
and was fixed year later by what was stated as non-solution

>some functions are insecure by default
C doesnt provide any functions. Maybe your poorly chosen stdlib provides insecure functions, doesnt mean you're stuck with them.

>another failed c++ replacement that failed into webdev
Go is more of a Java replacement than a C++ replacement. Keep in mind that there is a lot of overlap between Java and C++, Java is used for large scale distributed systems like Hadoop despite the fact that it is slower because C++ is simply not a stable enough language to handle data on that scale. Go blurs the line between a scripting language and a systems language, so Go can be used to make utilities that would replace bash, Perl, Python scripts. When you use the run command instead of the build command, Go deletes the binary after running the program, so it is in affect working like a scripting language.

Is it hard to rewrite Go program into C program?

yes, Go is a userspace systems language, not a kernel/hardware level language. The reason that C is still the defacto bare metal language is that its basically a typeless language, were any kind of arrangement of bits can be cast to do anything. Go's type system would never allow any of that.

Go is the best language for devops
youtube.com/watch?v=COCUqAwAbD0

>requires an extra tool and additional testing and dev time
tell me when Go can detect race conditions at compile time