[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.




File: 1659703663390.png (21 KB, 500x500)
21 KB
21 KB PNG
What (preferably simple) programs should I make in Go? Give me some ideas.
>>
>>88018171
A program that periodically tells you to learn something that isnt a meme
>>
a cut-like utility but for csv files. It should support custom separators, unicode, quotes, and header skipping
>>
use tcell/tview and make a TUI app to do something
>>
any unix coreutils
file manager with ncurses
terminal emulator with xgb
simple games like tetris, snake, tic tac toe...
>>
>tcell/tview
>ncurses
ignore these boomers
https://github.com/charmbracelet/bubbletea
>>
File: 1639585340032.jpg (85 KB, 500x508)
85 KB
85 KB JPG
>>88018171
You could use Rust considering Go has been made irrelevant by it :)
>>
>>88018405
ywnbaw
>>
>>88018405
come back to me when your language has anything as slick as goroutines
also, macros considered harmful
>>
File: computer newspeak.jpg (82 KB, 850x400)
82 KB
82 KB JPG
>Go
>Rust
>>
>>88018450
>valuing the opinion of a guy whose language didn’t even survive 20 years
>>
>>88018171
I'm making my own "file explorer" and implementing small features into it, for browsing my random stuff on disk. For example, I use ffmpeg to generate previews of videos (like on PH); and in some cases pull information/image previews from search engines (eg. movie covers, for my "Movies" folder). Slowly practicing my vanilla CSS/JS too.
>>
>>88018171
A graphical calculator.
>>
>>88018190
alright, I did it
https://github.com/jonkerl/miller
>>
>>88018171
ethereum clients are made in go, you could so something with that
>>
>>88018171
make a Twitch app for Linux, it must have a built in chat.
>>
>>88018171
Try making a frontend for ii or hii or another file-based IRC client
>>
>>88018171
>in: some api
>out: some other api

Example:
>in: weather data
>out: what cloathign should i wear?

>in: football scores
>out: best team right now

etc, you get the point. Go is good for stateless api management
>>
>>88018384
not op but thanks
>>
>>88018450
>getting rid of memory leaks kills creativity
>>
>>88018450
That's the creator of perl isn't it?
Yeah perl was the equivalent of finger painting as programming goes, I don't mean that in the bad sense I mean in that anything goes more than one of solving a problem etc... Anyways perl is kill.
>>
>>88018171
a game that asks you for a number and the program wins by printing the number + 1
>>
>>88018171
I am starting a static website generator in go would you like to contribute and work together on it? I have next 4 days off, if it works out we would continue working on it.
>>
>>88018171
play a fart sound from a wav file whenever a button is pushed
>>
>>88020835
i can work with you, give me contact
>>
>>88018439
Wow Go is only the millionth language to have green threads
Want a cookie?
>>
>>88018171
>>88018191
this. I like to use Go to make TUIs for interesting APIs. I use channels and goroutines to prevent the TUI from temporarily freezing up while a request is being fetched.
>>
>>88018171
a program that broadcast to every possible source that go failed and that it's bloat and that everyone shall stop using it immediatly in order to avoid having to rewrite the codebase in 15 years because it's getting deprecated (the way of ruby)
>>
>>88018189
What would you suggest then?
>>
>>88019603
Box::leak
>>
>>88020835
>I am starting a static website generator in go
you mean html templates?
>>
>>88022838
>literally the least bloat yet functional language
>bloat
I bet you like C++
>>
>>88023677
GC is bloat
It's not even a matter of debate. Discord dropped Go for Rust because of the GC, and the Fuschia team has outright banned Go because (in their own words) it's too bloated for actual systems programming.
>>
>>88023735
and?
don't use non-system programming languages for system programming?

only c++ tried to be a language for system and application programming.
didn't work out.
>>
>>88023735
>GC is bloat
That's why java is so widespread
>>88023735
>Discord dropped Go
Twitch uses go, then what?

Also you can disable gc in go, and free with unsafe
>>
>>88018171
rust compiler
>>
>>88023677
java, c# and go are all the same, they're heading to the garbage dump where they belong
>>
>>88023770
>c++ tried to be a language for system and application programming.
>didn't work out.
>didn't work out.
lol moron
>>
Go is a bad language, but it could have been a great one. For a language explicitly meant to be simple for beginners to pick up it has a lot of footguns and pitfalls you need an intimate knowledge of to avoid. None of them are hard to avoid once you know about them, but beginners, by definition, won't know about them.

>Channel axioms are invented, not obvious
Nil channels hang? closed channels panic?
>Channels, the major feature of Go, make leaks exceedingly easy
The most naive way of getting the result from a goroutine will leak if you don't use the result. For a GCed language this is unexpected, and beginners are constantly leaking goroutines. And then they have the gall to claim that Go doesn't have coloured functions.
>Time formatting
Stupid bullshit
>Entire time package conflates wall time and monotonic time
They used monotonic time internally in the stdlib, but then realized it was useful for other people. Rather than anything sane, they crammed monotonic time into the existing time struct. This was an unannounced breaking change that broke their compatibility guarantee, and they didn't give a shit.
>Slices act as both vectors and spans at the same time
Even C++ isn't stupid enough to do this. All because they didn't want to have "list" like python. For beginners it's easy to unintentionally copy and overwrite values.
>Defers are function scoped
More minor of an issue, but a common footgun for beginners that can often pass local testing only to choke and die in prod.
>Two "nils"
Of all the stupid things to copy from Javascript...

That's ignoring the more table-stakes features of languages from the last couple of decades it doesn't have, like non-nullable types, and the fact that generics are implemented poorly so they have significant performance penalties. Not that the performance should matter too much in practice, but it's clear the Go devs did the worst job they could get away with to spite the people who wanted generics.
>>
>>88023831
>Also you can disable gc in go, and free with unsafe
Technically you can, but in practice no. There's so much implicit and magical copying and no clear ownership in Go's runtime. It's not like C++ where you have a vector and you know that the array associate with the vector can die with the vector, you only have slices and you really don't know what the fuck happens when you call b = append(a, dicks) to know if you should free a or not.
>>
>>88025999
and?
just periodically restart.
>>
>>88026015
I don't actually think the GC is a point against Go - though it not being tunable at all is, and they're slowly admitting to that mistake with more options - but disabling the GC when it's such a core part of the runtime isn't really a solution. Unless you're doing PHP style short lived processes you'll run out of physical memory pretty quickly because the Go runtime is not designed to minimize memory usage in the short term.
>>
>>88019603
Yes, actually. Achieving memory safety ought to be a lengthy battle fraught with peril.
>>
>>88018450
Yeah, I agree. C killed the creativity of manually managing offsets from pointers for logical struct fields in B. Fuck C, ruined a generation of programmers.
>>
>>88018171
You want to lean any new programming language? Do a few of the Advent of Code problems in it. Then write something like a figlet clone, or cal. Maybe your own version of lolcat.
>>
Here's a really simple one I wrote recently. It takes 2 numbers & outputs a text file of unicode codes between the numbers. Each code starts with &#x, then there's the hexadecimal number, followed by a ;
>>
>>88025898
its easy to read and extend though even if you've been gone from the codebase for like 18mo. can't put a value on that.
>>
>>88028425
go is too low-level to be easy to read compared to python
>>
>>88029241
Eh I am starting to use it over Python and Rust for more complex things it's simple enough for me I can quickly write code and have it be reasonably fast and write stupidity fast code in Rust
>>
>>88029298
how's writing relevant to reading?
there are many write-once PLs that will be impossible to read later.
>>
>>88028425
Honestly I find the opposite to be the case. Large refactors on Go projects are painful. Things like non-exhaustive switches mean if I add a new state to an enum or somesuch, I'll be pushing errors that would be compile time in most other modern languages. If you have something you think is a channel, maybe a refactor elsewhere turned your code into a panic or a permanent hang. You get a value out of a channel, but you wrote that code without considering the channel being closed and you changed the code to close the channel, so now you've got a default value that seems to work but wasn't what you expected.

Go has a small syntax but that belies complicated semantics and subtle hidden details. I have used Go for hobby projects for over six years now and I can say first hand that coming back to a project after a year or two of not touching it is harder in Go than my older Haskell project, despite using Go a lot more. It's much harder for me to make a change that'll build but fail at runtime in Haskell or Rust.
>>
>>88018171
Simple programs are not worth making. Why? Because they have already been made.
Unix is a cult. Every year all these tools get rewritten. No innovation is being done. How many terminal emulators do we need? How many dmenu like launchers do we need? How many bars do we need? Meanwhile programming actually useful software is sadly too hard for unixshitters.
>>
>>88029440
>ul. Things like non-exhaustive switches mean if I add a new state to an enum or somesuch, I'll be pushing errors that would be compile time in most other modern languages. If you have something you think is a channel, maybe a refactor elsewhere turned your code into a panic or a permanent hang. You get a value out of a channel, but you wrote that code without considering the channel being closed and you changed the code to close the channel, so now you've got a default value that seems to work but wasn't what you expected.
why would you make this error more than once?
are you retarded?
>>
>>88029534
go is plan 9, not unix
>>
>>88029440
>harder in Go than my older Haskell
doesn't sound believable.
Haskell fags constantly change which language extensions they are using.
language extensions make Haskell a completely different languages each time.
>>
>>88029562
Across a few thousand lines per project, mistakes can happen. What's more is they weren't mistakes at the time they were written, because the conditions were entirely impossible. I didn't say those specific things were regular occurrences, just that they're issues I've seen coming back to a project after a long time. The closing channels thing was a one-off, I usually either have channels I never close or channels I only close to signal completion.

But they're concrete examples, and you should be able to reason about them even if you're too inexperienced with Go to have actually seen them. Also it's less hard data but I find the quality of libraries in Go to be lower compared to Haskell and Rust. I think it's a combination of the language making bad code easier and more idiomatic, all the hidden gotches in Go (see my first post), and the inability for people who only know Go to manage C memory (the C library wrappers are really shitty in Go, when you do need those). There's also the "stdlib or bust" approach the community takes, where the stdlib itself is pretty shaky, so the libraries don't get exercised as much.

>>88029601
To be fair I only have the one Haskell project and I'm less experienced with it. But when I go back to Haskell or Rust, it's much less likely I'll forget some subtle interaction because many of those are encoded into the type system. Add a new enum variant in Rust? A compile-time error unless I was carelessly using wildcards. In Go? Better hope I catch everywhere where I should be checking for the new enum, best I can do is have default panic branches to catch them at run time.
>>
>>88029562
>Series of traps and footguns baked into the language
>Language is targeted at beginners who won't know these things in advance until they run, face-first, into each one
And the response is always "just don't make mistakes, ever, and you won't have bugs in your code."
Wow, why didn't anyone think of that? It's so easy!

Go is better than python for catching things at compile time and not wasting time on simple mistakes, but that's an extraordinarily low bar. It could have done a lot better with some pretty simple changes to the language before 1.0.0, but now they can't change it. That's ignoring some of the shit, like the entire time package, that was just unforgivably stupid. They even broke their own backwards compatibility guarantees to bundle wall time and monotonic time, which was itself a monumentally stupid idea.
>>
>>88029691
sounds like a straw-men.
there's no language without warts.
go is one of the least bad options -- even you imply this but not giving alternatives.
>>
>>88029728
>>there's no language without warts.
>There's no perfect language so we can't judge languages at all! All languages are equally good! We're all winners!

There's a particular contemporary language that came to many of the same decision points as Go, but made different and usually better choices, but if you bring it up you're a shill for that language even when it's for something Go did objectively wrong, even if you don't use that language very much yourself. And I don't mean the big ones, GC is fine, green threads are fine, even punting on generics was fine (though the "for me but not for thee" stdlib cheats around it).

Go is a different language from Rust with different goals, but some of the decisions Go made were simply wrong. Default values were a mistake. Null pointers were a mistake. The time package an embarrassing mistake several times over. Slices pulling double duty as both vectors and spans (in C++ terms) was a mistake. Channels should have been split into sender/receiver pairs, so they can be more easily GCed (channels, as-is, fight against the GC and keep goroutines alive as zombies). Channels don't compose well with the rest of the language, and the edge cases of channel behaviour are unintuitive and have to be learned, usually painfully. Null pointers were a mistake. Having two levels of null like Javascript was a mistake.

All of these mistakes make Go a worse language at its explicit goal of being a simple language for beginners to pick up quickly and write productive code in. Fixing them would not turn Go into Rust, it would just make Go into a better Go.
>>
>>88029570
plan9 is just unix but more retarded.
>>
>>88029728
>go is one of the least bad options -- even you imply this but not giving alternatives.
I overlooked this, but no I did not. Work on your reading comprehension. It's better than Python, but Python is one of the worst languages for making errors hard to detect with static analysis, if it's even used at all. In general stronger, static type systems are better for catching things early. Go has a very, very shitty type system that is only a few steps better than C's, and even then it's worse in some places because of duck typing.

I only gave Rust a try for one project when I ran into severe issues with a Go library wrapping a C library. It wasn't the first time I found a Go dev who didn't understand Go well enough to manage C memory with it - PSA: do not free memory in your fucking finalizers, especially without explicit runtime.KeepAlive() calls everywhere - but this time around I couldn't even get the maintainers to understand the problem. I gave Rust a shot for that one project and found it to be a more pleasant experience on every front except compile times, but I still have well over an order of magnitude more lines of Go than Rust among my personal projects and I'm not planning on rewriting them (though a few that are Xorg only might get rewritten entirely for Wayland in 20 years when I switch over).
>>
>>88018171
Someone here once mentioned a language similar to go syntax, but isn't go.
I don't remember its name. It wasn't zig nor rust.
Help
>>
>>88018171
a dynamic linker for go
>>
>>88029887
Go syntax is just a bit stripped down standard C-like algoloid syntax.
>It wasn't zig nor rust.
D, Haxe, Hare.
Kotlin is pretty similar (func and fun, semicolons are generally not used).
You can skim through Rosetta Code.
https://www.rosettacode.org/wiki/Munchausen_numbers
>>
>>88030438
It was similar to how jakt is to rust. A language based on golang
>>
>>88018171
A dilator generator
>>
>>88018450
There's nothing creative about the web.It's all converting database to json. This is why go reigns supreme, it is very simple and you can use multi cores easier than any other language
>>
>>88030545
Uhh, V?
>>
>>88030662
Probably yeah. Is it good?
>>
Rewriting netcat.
>>
>>88018171
a CLI web browser for a decentralized web protocol.
>>
>>88030656
go is not good at working with databases.
go community hates orm and is stuck writing raw sql.
go is not good at working with json. there's no type-checking and still it only accepts fixed shapes.
go community hates frameworks, so you have to glue together random libraries to make your own framework. every go microservice will be completely different and most are pretty barebone that don't even implement features like introspection.
multi-cores are not relevant for backends which are io-bound, not cpu-bound. python is as fast as go here.
even if you care about multi-core, green threads are a low-level building block and not as comfy as actual actor models as in erlang/otp.
>>
>>88030722
meh, weird frankenstein language kept alive by fanbois
surprised it's still around
>>
>>88030722
Dunno, never used it, but
https://mawfig.github.io/2022/06/18/v-lang-in-2022.html
>>
>>88024310
>java, c# and go are all the same
widely used?
>>
>>88030617

>A dilator generator

Already been done: https://www.youtube.com/watch?v=ZACOc-NwV0c
>>
Piece of shit language
>it's so simple not like bloated java hnnggggg

Yeah and we just spent 1.5 half months building a distributed authentication system from scratch because the Go ecosystem is pure garbage. In Spring it would've been an annotation that works out of the box
>>
>>88032391
They don't provide frameworks on purpose yet you expect to have them
>>
>>88032391
Enterprise application servers are dead, boomer. Get with the times.
Everybody uses service meshes now.
https://github.com/oauth2-proxy/oauth2-proxy
https://casbin.org/
>>
>>88032650
oh yeah? And how is an oauth service mesh going to implement access lists that dictate which user roles may access which data?
>>
>>88030826
Fuck orm
And yes there is..Literally built into the language
>>
>>88034625
struct tags are shit:
https://www.arp242.net/go-last-resort.html#struct-tags
>>
>>88034779
Tags are pretty much the only way to have metadata, what is your suggestion?
>>
>using Boilerplate: The Language
>>
>>88034855
Tags/annotations/attributes are fine, but Go's implementation is the worst. A single massive, unchecked string where if you make any kind of mistake you're not going to get a compilation error or a runtime error, you'll just get weird behaviour (usually the library will skip over the field instead). Go's struct fields don't interact with the language or type system and are, really, no better than comments. Comments are is also what Go uses for locking in place of Lock<Thing>, where Java has the @GuardedBy annotation which will warn or fail the compile if you forget it and clang has similar thread safety annotations.

Go implemented tagging in the worst way possible. Even fucking Python will error out eventually if you typo "@decoration_name" as "@decration_name."
>>
>>88035317
Go implemented many things in the worst way possible. After having worked professionally with the language I'm convinced that the only people who actually like it are
>C / C++ system developers
or
>students who use Go only for algorithms or hobbyist projects

There's a reason why even Google doesn't have any Go API client libraries for most of their products
>>
I'm looking forward to switching from php to go as a career path, and am still okay with using it, but I can agree with some points made here, since I've ran into a lot of them
Should I considering something else? Any suggestions?
>>
>>88035769
At the end of the day it's just a job. Just go with whatever pays the most. It's not like it will be impossible to learn another language after Go. In fact most actually interesting engineering positions don't even care which languages you're fluent in as long as you're a decent engineer
>>
>>88035769
I mean if you have a job lined up, not really. Go isn't a bad programming language by the standards of the early 1980s, you can still get work done in it if you're aware of the issues. There are worse choices than Go (namely Python, and, for that matter, PHP). I hate Go so much because I'm judging it by the standards of its time, not the 80s that Rob Pike thinks he's still living in, and because Go could have been great if it just accepted a few rounds of public feedback and were willing to make some moderate changes to the language before their backwards compatibility guarantees. "We" knew better ways to make Go before Go was made, but Pike and rsc and the rest of them did not.

But then again, if you're considering learning a language to be a major commitment, well, getting used to picking up new languages will be good for that. You should be able to pick up any of the mainstream languages (even Rust) and be writing useful code in a weekend, even if it's not the best or most efficient. Not to downplay the benefit of getting used to all the ins and outs of a language and tool ecosystem, but like, picking up a new language shouldn't be a big commitment. Worst case is you pick it for a personal project, come to deeply hate it, and rewrite it in a language you like more.
>>
>>88035983
Thank you, this is actually a good advice
>>
>>88029887
>>88030438
Haxe is amazing, but IMO does not look like Go at all. It's closer to typical OOP languages like Java and C#, but with more Haxe-specific features like abstracts.
>>
>>88018405
GO
>Docker
>Kubernetes
>Terraform
>ArgoCD
>DroneCI
>Cilium
>Rook
>Vault
and many more
meanwhile rust
>deno, more like dethroned already
>tauri
>grep but in rust
>>
Wails/fyne/qt/gtk?
qt is already stupid because binary ignores system style, but it can be fixed
>>
>>88036805
>grep but in rust
But its good
>>
>>88032375
Wtf lmfao
I hate trannies so much it's unreal
>>
>>88032452
>you expect to have boilerplate code already written for you
Yeah, why not? Lol
>>
>>88034779
Retard
>>
>>88035317
Lmao none of that is true.
>>
>scanln
>doesn't scan until EOL
wtf
>>
>>88018171
ls /usr/bin/

A thread died for this.
>>
>>88037600
Ironically thread is more useful than your reply
>>
>>88037810
>He doesn't know that path's where all the simple, core utils are.
You're ngmi.
>>
>>88023735
fuschia's network stack is built using go. Cope and seethe more tranny
>>
>>88038019
Fuchsia must be shit...
>>
>>88037967
Op should be making mostly symlinks I guess
>>
>>88035983
>the only sensible post on /g/ in a year
>>
>>88037404
You should try some other languages some time. It'll be a real eye-opening experience for you.
>>
>>88036805
>go
>all cancer and mistakes
>>
>>88018171
a chat server. oh wait.. you cant because go doesn't actually have true multithreading.
>>
>>88039149
>true multithreading
explain
>>
>>88039149
thats like babbys first go project 101 and its among the things that are the easiest in go
>>
>>88023831
>Twitch uses go
for what?
>>
File: the_GOat.png (54 KB, 804x703)
54 KB
54 KB PNG
>>88038935
seethe and GOpe
>>
How are default values bad? I only find them sometime annoying because a manually entered zero value can also be considered empty, but for this i can also use pointers.
>>
>>88041069
https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang#all-or-nothing-so-let-s-do-nothing
>>
>>88041069
Default values make for error prone coding. Google was in a phase when Go was being developed where it also added default values to protobuf. It walked back the decision on protobuf default values in 3, but it's not possible to remove from Go.

Default values are either meaningful, in which case it's difficult to tell a present default value from a missing value, or they're meaningless, in which case you're worse off than if you had a proper Option/Maybe type or sum types (so much of Go would be made better with very basic sum types). In managed languages it's actually worse than "null" pointers, because Go's nil is not a real null and you'll (probably) eventually die when you try to dereference it. A default value can make its way very far through the code and cause surprising or wrong behaviour at runtime. A better api than "val, err := map[key]" is "val := map[key; default]" or map.get(key, default) or whatever when default values are acceptable in that context. Make it explicit and opt-in rather than implicit and opt-out.
>>
Why does go make rust people seethe? Aren't they for different things?
>>
>>88041197
Yeah it's nice that it's possible now, though I've not looked into the details and I haven't ported any of my projects (six years worth) to newer go features since modules and embedding.

>>88041209
It's more that Go makes people seethe because it's poorly designed and could have been better. There are a lot of objectively bad decisions in Go where they should have known better, and we have proof, because Rust was being developed at the same time and managed to not make those mistakes. I don't mean the big things like GC, green threads, etc, those are fine. But things like having nullable pointers, default values, channel API design, etc. Things where there definitely are choices that could have made Go into a better Go.

>Aren't they for different things?
Kinda. The people who designed Go initially intended them to be for the same things and ended up being surprised when they got Python, Ruby, Javascript, and PHP devs converting instead of the C/C++/Java devs they were targeting, who largely left it alone. They're for different things more now than they were 10 years ago.
>>
>>88041238
So it's a poorly designed language that managed to find a niche? Or more that it's good, but could have been better?
>>
>>88041347
It's a poorly designed language but it got pushed hard enough, to people who didn't know any better (Python devs) and managed to get a bit enough community that the quality of the language doesn't matter as much. I do think Python is a worse language to code in than Go, but Python and Javascript are old and their mistakes are more forgivable. Go was brand new and could have built on top of them, but instead it ignored multiple decades of common sense and regressed behind a lot of other languages.

I dislike Python for a lot of reasons, but I'll still code in it from time to time when I just need to glue a few libraries together for a simple script. In theory I'd do the same for Go, but I can't imagine a project at this point that would hit that very specific niche of being too big for Python but Rust's community being too small to have whatever critical library I'd need. My Go projects are pretty much just on maintenance mode.

>Or more that it's good, but could have been better?
Saying it's good would be a stretch. It's bad for a language developed in the 2000s. It'd be good for a language developed in the late 70s or early 80s.

What's more is it could have been truly great. I'd never have switched away from Go if not for Go's inadequacies. The changes needed would not have been massive before 1.0.0. Split channels, add very basic Option types, drop nullable pointers, remove default values, splice slices into lists and slices. None of this would have made Go into not-Go, just a much better Go.
>>
>>88041419
python 3 is only one year older than go.
if you break all of python 2 anyway, you could have fixed a lot more than strings.
>>
>>88018450
Absolutely true. Java generics set back inheritance by decades. Multiple inheritance CAN get you in trouble but sometimes it’s what the problem calls for.
>>
>>88041441
I don't think any language will make a similar break as Python 2 to 3 again. Not until memory has faded. Certainly not Go, and they've said as much; I think they said Go 2 would be doable by automated tools. But Python is a bad example since I can't even safely update from Python X.Y to X.Z without shit breaking. Go at least pays lip service to not breaking things - though the attitude in the time.Time + monotime merge really showed their true colours.
>>
>>88041450
i wouldn't call having to fall back to codegen in go to compensate for missing language features as creative.
that's just brute force.
>>
Go wants to be python but ends up being C
>>
File: 1617539788383.png (123 KB, 2500x781)
123 KB
123 KB PNG
>>88041238
>we have proof, because Rust was being developed at the same time and managed to not
produce a single piece of software worth anyone's time
>>
>>88042319
If literally no one in the world had written a single line of Rust, it still wouldn't make Go's design choices any good. Even with a multi-year headstart and being "so good for beginners" Go only has kubernetes and docker, one of which was directly pushed by Google. I actually end up running more Rust, personally, just by using Firefox than I do Go, and I've written tons of Go for myself.
>>
>>88042319
k8s was orignally java.
google's political decision to port it to go despite go's type system severely lacking and having to use codegen to compensate isn't a go success story.
>>
>>88042319

>thing is popular therefore it's good
>>
File: 1657918435683.png (37 KB, 400x490)
37 KB
37 KB PNG
>>
>>88032391
>In Spring it would've been an annotation that works out of the box
Until it stops working and you spend 5 sprints trying to fix what this piece of shit framework broke
>>
>>88042446
Well it's supposed to be good enough to be widely adopted
Good enough > good in general, actually
>>
>>88042485
Google themselves uses Borg and not k8s.
Borg is written in C++.
>>
>>88042361
k8s came from borg which is older than go, and go was designed to fix the shortcomings of java like huge memory consumption, slow start-up times and shit concurrency
>>
File: Docker.png (99 KB, 722x583)
99 KB
99 KB PNG
>>88042357
>multi-year headstart
wrong
>>88042357
>Go only has kubernetes and docker
wrong, and >>88036805 is not even exhaustive with much more missing like Jaeger, Packer, Vitess, Prometheus, OpenMetrics, Tekton etc pp
>I actually end up running more Rust, personally, just by using Firefox than I do Go
clueless neet, everything you browse goes through cloudflare, aws and azure
go is for backends in distributed systems and custom tooling

Rustards, or Bustards as I like to call them, would cream themselves to have a single piece of software as relevant as any of the ones listed here
>>
>>88030826
Do you realize that picking SQL over ORM, and frowning upon frameworks and JSON actually makes Go better?

It means it was designed by people with actually skills and taste.

If you want to write microservices using JSON and frameworks and retarded shit like that, literally just use NodeJS with the other IQ 95 people.
>>
>>88041209
The only reason Go makes Rust trannies seethe is that Go is stealing a lot of thunder from them.

Both languages were started around the same time, and it's pretty clear that Go has joined the league of languages like C++, PHP, Java or C# while Rust has joined the league of languages like Scala, Clojure, etc. (i.e. minor languages for language-obsessed faggots).
>>
>>88043019
The list does not stop there. There is also Hugo (static site generator), Gitea (alternative to Github) as popular Go projects.

The reason is obvious: Go is productive. While Rust trannies are scratching their heads figuring out while the compiler or the borrow motherfucker don't let them compile, Gophers can write simple code and it relies on GC and it's memory safe without spending hours trying to compile shit.

The evidence I have for that is, so far, we have not seen A FUCKING SINGLE major piece of software written in Rust. If it's so secure, where the fuck are the email server, DNS servers, SMB servers, etc.? Aren't you guys going to secure the Internet by rewriting everything in Rust? No, it turns out they are busy re-implementing trivial Unix command-line utilities, because their toy language does not scale beyond that.
>>
>>88043128
just because a bunch of shit you run into is written in "it might compile but will it work: the language", doesnt make it any good. have you actually looked under the hood at kubernetes code? or podman? or even hugo? it's a fucking disaster zone of them trying to cut in complexity where the language is actively fighting against it.
>>
>>88043081
node also hates frameworks and doesn't even bring a good standard library.

go is like node with express in the standard library and less npm insanity.
>>
>>88043745
Why did they use it in the first place then?
>>
>>88018439
Slick at making data races yes.
https://eng.uber.com/data-race-patterns-in-go/
>>
>>88043987

It was ported from Java only because Go was the hip new thing back then. K8s codebase is an absolute clusterfuck because Go isn't suited for these systems-level problems with it's anemic feature set and shitty garbage collectors.
>>
>>88044297
>It was ported from Java only because Go was the hip new thing back then
Who are you trying to convince with those brainlet takes?
>>
>>88018171
Make an Electricians Calculator
>>
>>88044297
I don't see a lot of rewrites in rust, but I'm pretty sure it's hip right now
>>
>>88044306
Are you saying k8s is idiomatic Golang?
>>
>>88044600
You actually have to have a brain to use languages like Rust compared to Go even tho i fucking hate rust
>>
>>88018439
Goroutines are not true multithreading.
>>
>>88029241
Python is the Hooked on Phonics of programming and calling Go too low level to easily read is idiotic.
>>
>>88029241
>go is too low-level
Literally what fucking braindead ameba you have to be to write this. Go is literally on the same level of Python or Js in terms of being easy, just statically typed. Thats fucking it
>>
>>88045107
let's remove an element from an array
>>
>>88020835
hey, lets just use discord
>>
>>88029887
do you think its nim?
https://nim-lang.org/
>>
>>88045240
append(slice[:deleteIndex], slice[deleteIndex+1:]...)
>>
>>88041209
Go is growing quickly, meanwhile Rust is barely growing even though it's always the "most loved" language in those SO surveys - as if that means anything for a job market.

This makes Rust users basically cultists, because they made the choice to learn an unadopted language early based on emotion rather than logic. So any language other than Rust triggers them because Rust should be the only choice for anything ever because they're emotionally obsessed with it "winning". Then they see some stupid blue Gopher is just chilling in the corner not event trying and is succeeding faster.
>>
>>88045405
>Go is growing quickly
Source
>>
>>88043128
>The evidence I have for that is, so far, we have not seen A FUCKING SINGLE major piece of software written in Rust
The new JetBrains IDE uses it
>>
>>88045541
Right, I remember reading something about a pronoun checker in the patch notes
>>
>>88045789
Kek
>>
>>88043019
>>multi-year headstart
>wrong
I mean, I can use the google and check for myself. Go 1.0 was early 2012 and Rust 1.0 was early-mid 2015. That was when people would actually start using them as they settled down. Three years sounds like multiple years to me. If anything Go had even more than three years head-start because the Go authors weren't willing to make necessary changes because it was impossible for them to admit they made any mistakes on their ego project. Go software written in 2009 would be much more likely to work with 1.0

Either way, even if literally no one had ever written a single line of Rust, Go's choices would still be bad. Go's choices were bad on their own even by the standards of the late 80s. The same logic that makes Go seem good - and Go usage isn't that high, it only seems high compared to Rust where Rust is about a third of Go's usage, both languages are small compared to JS/Python - can be used to prove that Javascript is the "best" language.
>>
>>88047474
https://youtu.be/bmZNaUcwBt4
>>
>>88018439
>as slick as goroutines
I can just use tokio, and when I do I'll have type-level guarantees against data races.

Goroutines could have been done a lot better, though it ties more into the problems with channels more than goroutines. The idiomatic way to get the result from a goroutine will leak. When I look at people's code as they're just getting into Go, these problems are all over their code. This is a language targeted explicitly at beginners by their own direct admission, so building in entirely unnecessary traps for beginners is

result := make(chan, int)

go func() {
result <- doWork()
}

// Do some stuff

select {
case r := <-result:
// do something with it
case <- time.After(30 * time.Second):
fmt.Println("doWork timed out")
return
// The result channel and the goroutine spawned can never be cleaned up. You have a memory leak in a GC'ed language
}


A better design would be to split channels into senders and receivers and if all the senders/receivers get GCed then fail all receives/sends so that devs don't need to work around it. There are workarounds, like using a buffered channel of size 1 but Go explicitly discourages buffered channels, so beginners won't reach for them, and spawning off a second goroutine just to wait for and discard the result is not obvious to beginners either.

>>88047601
Yeah I've seen that. I remember the graph laying out the languages over time. If go were 20 or 30 years earlier I'd be more accepting of its obvious shortcomings. It's a big ego project that happened to work out because they were working for Google at the time.
>>
What about error handling?
>>
>>88047949
Go error handling is very, well, error prone and extremely verbose, all due to a lack of sum types to distinguish between "value OR error" and "value AND error."

Sum types confuse and scare gophers. To the go developers, algebraic types were developed in the 70s which makes them too new, scary, and unproven: just useless ivory tower academia noise. Much better than sum types is using product types for everything. But structs are sometimes annoyingly verbose, so we'll use tuple-style sum types for function returns. But only there, because tuple/anonymous structs are useless, so we can't let developers use them, even though we're using them in the language because they're useful, because they're useless.
>>
>>88048024
>muh sum types
Basic exceptions would do, thank you
>>
>>88048230
I'm mixed on exceptions, but I think exceptions done well would be better than Go's product-as-sum types + boilerplate error handling.
>>
>>88018405
the syntax and build times of rust are pretty awful
>>
>>88049289
Elaborate on syntax
>>
>>88049317
It's not exactly like C - some things are new, some have been removed - so some people have a lot of trouble adapting.
>>
>>88047474
>Go 1.0 was early 2012 and Rust 1.0 was early-mid 2015
1.0 doesnt matter, only general release and availability to the public do.

>>88048024
>or
>and
errors are just values, dont panic
>>
>>88018171
The language was created to make servers, so write a web server serving some sort of JSON-based API calls.
>>
>>88050034
>1.0 doesnt matter, only general release and availability to the public do.
"I decide what matters, and what matters is whatever makes Go look less bad"

I even acknowledged that code written for Go in 2009 would be more likely to be like Go 1.0 code than Rust code written in 2010 for Rust 1.0, but that just makes the comparison more lopsided. Depending on how you slice it, Go had at least a 1 year headstart, bare minimum, but because Go changed so little you could say Go had as much as a 6 year head-start.

>errors are just values, dont panic
It's funny when Go devs are so ignorant they can't even understand the problem and they fall back to one of the Go mantras at random. 17 and "ABC" are just values too, but they're different types. Go has product types (int AND string) but not sum types (int OR string) which makes the language as a whole clumsy. If I have a function that returns an integer or a string, the return type is (int, string) in Go, and you better hope that 0 and "" aren't meaningful values, because you can't tell them apart.
>>
>>88050095
>Depending on how you slice it, Go had at least a 1 year headstart
public release: 9 months
Not that it matters, Bust will never reach the adoption Go had 5 years ago
>hope that 0 and "" aren't meaningful values
functions should be designed with a proper scope and signature
>>
>>88049317
Can't put my finger on it, but I think it's the combination of boilerplate required and double colons. It's a drag to read, but the thing that bugs me is the build times the most.
>>
>>88048024
Rust fag panic() ing over the superior, reliable error handling model of Go
>>
>>88051831
if err != nil {
return false, 0, "", nil, mystruct{}, err
}
>>
>>88040343
Majority of back end, did you not look at the leak? Dummy
>>
>>88018171
program that uninstalls Go from your computer
>>
File: 1642941377243.png (149 KB, 1576x890)
149 KB
149 KB PNG
>>
>>88051902
Now that I think about it, naked returns look like have been made just for this
>>
>>88053859
Oh those are even worse. They're really implicit and you're a lot more likely to accidentally return incomplete results. Like if you have a, b, and c, you might add a new branch and return early when a and b are set but not c. Like most things in Go, it wasn't really thought through and the state of other misfeatures in Go makes them worse; they'd be much better without default values. If the compiler enforced that you had to initialize every value before returning it'd at least be something.
>>
I really don't understand default values
If I have a struct, I have to make EVERY field a pointer, to check for empty values, and if it happens to be a struct describing a db model - I have to use sql.NullWhatever to scan for nullable values
Is there something to read that justifies them?
>>
An implementation of cxref:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cxref.html
If you prefer, you can make a goxref command instead.
>>
>>88036805
>deno
Wait deno is out? And it‘s worse than node?
>>
>>88053979
It was a phase google was going through. There's no good reason for them. Google made the same mistake in protobuf but walked it back by reintroducing presence tracking (in a slow, inefficient way, but it's back). I don't have hard data but I think it was a knee-jerk reaction from people who think Java's Optional and the like are "too academic" and wanted a "more elegant" and "simple" solution that pushes all the complexity onto users. Why have explicit knowledge of whether something is present, missing, or possibly present when you can just guess?
>>
>>88023735
>GC is bloat
This retard is definitely not a programmer
>It's not even a matter of debate. Discord dropped Go for Rust because of the GC, and the Fuschia team has outright banned Go because (in their own words) it's too bloated for actual systems programming.
Well no fucking shit sherlock, if you need fhat 10% performance so desperately of course you'll switch to C++/Rust. You're generalising by dismissing the whole language based on two examples of performance-critical scenarios which most people will never need fo work on
>>
gc cycles in go are not even that bad in terms of performance
>>
>>88054081
It is, it's beaten by bun. Another alternative.
>>
ehh, i just write in nim or crystal
>>
>>88055559
>https://bun.sh/
>WebKit's engine is actually faster than V8
Huh, intredasting.
>written in Zig
Whoa.
Cool.
>>
>>88055923
>doesn't say blazingly fast anywhere in the hero section
Into the trash it goes
>>
>>88056749
It's honest though
>>
>>88044297
>go isnt suited for these problems
>its literally the language of choice for top engineers that likely know/can pick up any language they want
>>
>>88058360
>>its literally the language of choice for purple-haired FANG freaks, brainlets, and trannies

FTFY
>>
>>88058516
Meds. Go look at kubernetes github contributors. its almost all white men
>>
>>88018450
>programming languages, human languages
>both have languages in them
>they are the same thing
>trust me bro
>I'm a linguist
>>
>>88019430
>Go is good for stateless api management
What is particular to Go that makes it suited for that?
>>
>>88018450
>people keeping walking off a cliff
>put up a waist-high guard rail that could still be easily jumped over
>"wtf this is literally tyranny"
>>
>>88058722
it's standard library
>>
>>88058516
you're confusing go with rust
>>
>>88059386

>>88032375
>>
>>88029241
>go is too low-level
You do realise people used to write code in FUCKING ASSEMBLY?
>>
>>88060785
Is it readable?
Anyhow, I could never understand why python got rid of all features that help readability and called it an improvement
>>
What are the best resources for learning Go?
>>
This garbage lang would perhaps be worth using if it had sum types at least.
>>
>>88061212

https://dev.java/learn/
>>
>>88061430
sir please to doing the thankful for posting the prahpor leenk for Goh
>>
File: 1659990131273.jpg (16 KB, 390x208)
16 KB
16 KB JPG
>>88061064
Hello world in assembly x86
I know its a bad comparison, but go readability isnt too bad
>>
>>88061430
>not durgasoft
wack
>>
>>88061212
https://go.dev/tour and https://gobyexample.com
>>
>>88018171
Find something that isn't 100% to your spec and build it in go.

I just finished building a stack to monitor and control beer, wine, and mead I have fermenting. Logs readings from temp and density sensors and then turns on chillers/heaters if it's temps go outside of certain bounds. Compares gravity to previous ferments to give an idea of when something is done.
>>
>>88049317
the most common character in most programs is ':'
This is not a good thing.
>>
File: .jpg (285 KB, 1000x1312)
285 KB
285 KB JPG
>>88061212
Learning Go by Jon Bodner.
Very recent and very idiomatic.
Even touches on generics.
>>
>>88064187
>>88062593
Thank you brudders
>>
Make an interface that uses a library
For instance find a go compression/decompression library for .zip files etc
Make a program that acts as a useful frontend to it



Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.