(untitled)

I got legit sad with Golang, this bitch ass lang doesnt even have fuarrrking exceptions, inheritance feels half assed, handling errors seem like half assing the application. But yet it's concurrency is what saves it and would be ideal for a scalable and performant imageboard engine. I am legit depressed because of how half assed it feels, was all this thing from rob pike and his team necessary? I should drop this bullshit. Am I just frustrated because I don't have 100 hours with the lang? Whats your experience with it? There is any alternative lang without the half assed concepts like even their "inheritance" but performant as go? I saw something about erlang...

>>30470 Go is not an OOP language. It doesn't have classes and inheritance. It does, however, have struct embedding and interface. That's probably what you are calling inheritance. Both these methods provide extensibility by composition unlike inheritance. https://eli.thegreenplace.net/2020/embedding-in-go-part-1-structs-in-structs/ https://golangbot.com/inheritance/ You probably need a bit more experience with the language to understand how to write idiomatic code in it. You shouldn't treat all languages the same. >doesnt even have fuarrrking exceptions Maybe you don't need it. There are better ways of handling errors. >inheritance feels half assed It doesn't have inheritance. No OOP. >handling errors seem like half assing the application Unfortunately, that's true. It's a shame how they designed it for a "modern" language. Rust does it better. >Whats your experience with it? I use it for small CLI programs and for quick APIs. >any alternative lang without the half assed concepts like even their "inheritance" but performant as go? You can look into Rust. It's performant, but doesn't have inheritance either and it has a steep learning curve. It has traits which are very similar to interfaces in Go.

I am on the same boat. Writing stuff in Go is not fun, but it does his job. So I use it when I have a clear picture of what I am going to do and try to not get stuck on a codebase in Go for long. Here is an discussion with one of the creators of Go about error handling https://youtu.be/on5DeUyWDqI?t=480

>>30470 Just take the Zig pill. >concurrency Built in event loop style N:M threading, just like Go. Just add one line of code and you're able to run millions of coroutines with ease. Solving the C10k (and C10M) problem was never easier. pub const io_mode = .evented; https://kristoff.it/blog/zig-colorblind-async-await/ >performant It's a compiled language with a backend that uses LLVM, so it has all of the optimizations that Clang will ever give you in C/C++. No slow or unpredictable GC, so you can be sure there won't be any GC lag spikes. No more worrying about the 95% percentile response times! Scared of memory management? Just use the 'defer' keyword Lain, EZ RAII style cleanup. Want to be be even lazier? Have a single arena allocator scoped per HTTP request and forget about memory management entirely! >exceptions/errors This is where Zig really shines. It has all the features of exceptions, but with the low cost/overhead benefits that error handling provides. There's no runtime overhead to errors, but you still get stack traces. To give you a taste: const str = "..."; // 'str' is some string. try parseNumber(str); // Try to parse a number, or return an error up the stack if it fails. parseNumber(str) catch 13; // Try to parse a number, but if it fails fallback to the value 13. parseNumber(str) catch return error.SomeOtherError; // Replace the error returned. parseNumber() catch |err| switch(err){ error.InvalidChar => {...}, // Arbitrary error handling code. error.TooLarge => { return maxInt(i64); }, // If we don't handle the all errors parseNumber() returns, the switch statement will give a compile error. }; // And more! https://ziglang.org/documentation/0.9.1/#Errors // See error handling in action at https://github.com/Luukdegram/apple_pie/blob/5399084b774a609b6058b700ee5777f5d4376733/src/server.zig#L184-L193 TL;DR If you're not handling the error immediately just stick a 'try' and the compiler will automatically work it out and will give you an error (and how to fix it) if you fuarrrked up. >inheritance To elaborate on what >>30472 said: It doesn't have inheritance, because it doesn't need inheritance. Composition and interfaces go a long way. I've had the misfortune of having to touch Java at a $DAY_JOB before, and despite the cornucopia of EnterpriseSpringFactoryBeanController objects we very rarely used inheritance. >Is there any alternative lang without the half assed concepts but performant as go? There is, and that lang is Zig. Embrace the future old man, and head on over to https://ziglearn.org/ to get started! Need help? IRC is #zig on libera.chat, and we have a thread at >>>/λ/13884 pub fn helloWorld(req: Request, res: Response) !void { try res.print("Hello {}!", req.queryParam("name") orelse "World"); }

>>30470 >legit sad >legit depressed >bitch ass OP please learn to write without sounding like a person with brain rot and I'll give you a worthy reply.

>>30470 >I saw something about erlang... How about Elixir? >>30364 >>10497

All of the reasons you listed as making you sad are why I like go. >>30470 >this bitch ass lang doesnt even have fuarrrking exceptions `panic` and `recover` handle the cases where you would need an exception. Aside from that, the idiomatic error checking is more than enough. Having worked on large code bases in other languages that were riddled with exceptions, especially concurrent systems, go's error handling is a blessing. Keeps the control flow of the program nice and clear, keeps people from abusing exceptions. >inheritance feels half assed As others have said, it isn't an OOP language. However in OOP languages, it's often considered good practice to depend on interfaces instead of implementations as that helps to avoid a lot of common anti-patterns, better supports tests, and makes for easier to use APIs. Go forces this to be the case and by doing so eliminates a lot of common anti-patterns and general annoyances seen in OOP languages.

>lists 90s brain damage like inheritance and exceptions as the reasons why Go is sh*t is this intentionally bait?

>>30521 so much this. Or crying over no generics. 90 percent of cases where generics in modern code are being used are cases of over complicated abstractions when they start implementing generics functions around the very final branches of their horrendous graphs of inheritance that most likely have no logical sense in their design to begin with. In a lot of other cases type of argument you are passing in such functions barely have any importance and you can just direct control flow to a function that must be aware of a certain type for stuff like comparing elements of list for sorting purposes for example. I yet have to see serious example proving generics to be a thing to care about because of serious accumulation of functions that would be too complicated to design in other fashion than using generics.

>>30528 >Or crying over no generics. Outdated complaint as of go 1.18 :)

>>30531 which changes nothing

>>30531 Java got generics in 1.5. In 1.8, they already had lambdas and a new advanced type system.

>>30528 Dynamic dispatch/generics are the only reasonable way to do the sort of abstraction OOP intends. CLOS>Smalltalk>everything else.

>>31005 And once Project Loom lands Java will have concurrency as cheap as Go does.

>>31015 And Java still would be a CL wannabee OOP brainded monstrosity

>>31043 Java has never been anything close to CL.

>>30474 Isn't the pill to take now https://harelang.org/ ?

>>30470 I tried it out today and made a simple HTTP server and I enjoyed it because of the ease of use. I do not like its syntax, though. `var a int = 5` is just stupid, and so is `func f() T`, where T is the return type. Disallowing unused variables and packages is also really, really stupid and inconvenient. I feel like Go just tries too hard to be different and exotic in its syntax when that's really just not necessary. Overall, its standard library is nice to use but the language itself, not really.

>>31708 >Disallowing unused variables and packages is also really, really stupid and inconvenient. You can disable that check should you choose.

>>30470 >lack of exception as bad thing >lack of inheritance as bad thing Where de fuarrrk are you coming from? C++? Java? .Net? >>30472 You don't need OOP for inheritance. Inheritance is not OOP exclusive. >Rust does X better nope.avi >>31044 It's a wannabe. Not it. Rarely any wannabe becomes what it wants to be. Java attempting to do CL stuff is not a conspiracy. It's well known fact aknowledged by people involved in it's design.