Java is the most boilerplate-heavy Lang

>Java is the most boilerplate-heavy Lang
Hold my beer.

Attached: 1_yh90bW8jL4f8pOTZTvbzqw.png (600x600, 63K)

Other urls found in this thread:

news.ycombinator.com/item?id=19870792
twitter.com/SFWRedditVideos

varFoo, err := GetFoo()
if err != nil {
return err
}
sliceBar, err := SliceTheBar(varFoo)
if err != nil {
return err
}
err := CheckBarSlice(sliceBar)
if err != nil {
return err
}

Gotards will defend this.

use C++
the true patrician zero-overhead chad language

Whats the difference between

if err != nil {
return err
}

and catch{
Console.WriteLine(err)
}

getFoo >>= sliceTheBar >>= checkBarSlice

You write it once and only when you need it. Also, free stack traces.

At best, you have to define a catch block... zero times!
For example, web frameworks like Java Spring (Boot) come with or can be configured to use a "global error handler" that turn the caught exception into a well defined error response. You only look at the happy path and the error paths are handled automatically. When you want behavior based on exceptions, you can still catch what you need.

Wait until they invent the "?" operator from Rust but make it awful somehow
>mfw go generics

Attached: 1456076126372.png (933x720, 587K)

Rust's ? operator is retarded anyway, monad functions would be enough but Rust is a bloated shitlang with no HKTs and noisy syntax.

The difference is that you only write exception handling code once.

The Go philosophy is based on the idea that you know what do with an error condition at each point, but actually you don't. Is an IO error a big deal or not? And more importantly, what should you do with it? Well, it all depends what you are trying to write and why, i.e. it depends on the application. Thus for a library the best thing to do is to propagate the exception back up to the application.

Which is in fact what Go does, but you have to do it manually all the way up, which is just redundant.
It's not a deadly flaw for Go, but it's just annoyting having to repeat this boilerplate.

With C++ we get the boilerplate in compiler error messages

it's even worse, the last CheckBarSlice() call would shadow the variable err, while previous calls shadow error AND declare new variable
thus the CheckBarSlice() call is a compilation error

>Also, free stack traces.
in Java at least. not in C++ because committees don't think such things are useful

runtime cost of exceptions as they are implemented in Java or C++ is very high
if exceptions were implemented by control flow graph and hidden return value, it would be significantly faster (as e.g. go's error handling is). but that would use stack and since exceptions are used for stack overflow exceptions, it's not possible to use stack to propagate the value for ALL exceptions.

It's a heuristic thing. Throwing exceptions is extremely expensive, sure, but if an exception isn't thrown then the code runs slightly faster than if you had to check & handle every error. The point where exceptions start to outperform return value error handling is when exceptions are about 100x less likely to be thrown than the normal execution path to be followed.
That sounds like a lot but if exceptions truly are exceptional (e.g. OoM or IO failures) then it easily performs better.
Also, certain languages like Swift have exception-like semantics which nonetheless are implemented just like return value checking.

That's what the panic() should be for in Go, but the panic recovery is really half-assed.

That's what Rust does with its panics. Ordinary errors are just handled as return values except Rust has sum types and generics so it's possible to manipulate them easily, unlike Go.

The only downside is the bloated syntax.

> interface{} says nothing
> Don't just check errors, handle them gracefully.
> func Println(a ...interface{}) (n int, err error)

when was the last time you see an error handling code for Println?

Attached: animegirlthinkingemojibrownhair.jpg (2560x1440, 249K)

it never fails and can handle all inputs

>it never fails
you got a single fact to back that up?

jee, haskell adepts are really annoying - learn some high-brow pseudointellectual things that consist of 99% basic cs theory, and then come everywhere with no clue about issue at hand and start spewing their language-specific garbage nobody gives a clue about.

How much do you get paid to be a >, my fellow haskell ninja?

*of renamed basic cs theory

> Doesn't format error returns
> Doesn't understand what the pattern is used for
> Pr9banly doesn't know about panic/recover
Why would I bother defending poorly written code?

Attached: 1514561629416s.jpg (250x227, 7K)

news.ycombinator.com/item?id=19870792

read the fucking source code
technically it can fail on OOM error, but that's supposed to be "handled" by runtime and allocator in background

>only haskell has monads
you could do this shit in sepples if you wanted. noisy syntax notwithstanding.

>it never fails
$ cat >test.go
package main
import "fmt"
func main() {
_, err := fmt.Println("test")
if err != nil {
panic(err)
}
}
$ go build test.go
$ ./test >&-

Yeah I mean look at how incredibly retarded and noisy this is compared to the Go version.
let foo = get_foo()?;
let bar = slice_the_bar(foo)?;
check_bar_slice(bar)?;

Attached: 5vMxQc6.jpg (770x945, 224K)

whoops, it can fail on write to stdout, which just propagates returns of this call
what I meant is that it doesn't fail because of any input as all inputs are valid inputs

That's still pretty noisy compared to a real functional lang. Not bad compared to go though.

Go is the epitome of Bell Labs degeneracy.
I seriously don't understand why there are entire communities who worship Rob Pike so much.

Just use Lisp and leave C-influenced faggotry behind. Trust me, it feels liberating.

That's because Rust is not functional! Although it does take many things from FP.

exceptions are horrible for this kind of stuff, sure go's method is simple and a bit boilerplatey, but it's far better that it forces you to think about exceptions by explicitly putting it in the type.

people shit on gotos, but exception handling is a like a goto that can goto outside the lexical scope of the function, go multiple times up the stack and also into foreign dlls.

nulls and exceptions are my most hated things about c#, since so many bugs are caused by forgetting to handle them (when this could be enforced by the compiler). This is so much more important than

>> muh i want to write less code

It could have taken a lot more. The Rust developers seem to have a hard on for making things more verbose for no less clarity.

That's why you use a language which encodes errors in the type system, and also is powerful enough to manipulate those errors in convenient ways.

Go has the least powerful type system of a language in common usage that isn't just C.

*no more clarity

i agree that that is better (every day i year for ADTs in c#...) but my point is go's approach whilst not perfect is better than c#'s

Funny thing is that Java has what you're asking for - exceptions encoded in the type system - but C# devs always complain about it.

exceptions being encoded into the type system is much better than in c# (i don't quite understand have java does it, but you have to catch all syntatically possible exceptions/explicitly throw them again?), but exceptions still have the confusing control flow problem (like gotos do).

>Go is the epitome of Bell Labs degeneracy.
>I seriously don't understand why there are entire communities who worship Rob Pike so much.
Bjarne Stroustrup has always hated Ken Thompson for not being a shill for his language at Bell Labs (read the Ken Thompson chapter in the book Coders at Work if you don't believe me, Bjarne went into Kens office and yelled at him for criticizing C++ in a magazine interview). Bjarne Stroustrup doesnt deserve to even mention the name Ken Thompson, he knows it, so he picks on Rob Pike as a straw man for his inferiority complex.

Attached: faces.KenThompson20449.web_.jpg (1619x2024, 1.36M)

Java has two kinds of exception: checked and unchecked.
Unchecked exceptions work like C# exceptions.
Checked exceptions must be annotated on all method signatures from which the exception may be thrown. If you try to call a method that may throw a checked exception, you must either handle it in a catch block or add it to your method signature as well - so you'll always be aware whether or not a checked exception may be thrown.
Unchecked exceptions are more for programmer errors like dereferencing null references while checked exceptions are for anticipated circumstances like being unable to open a file.

go desperately needs some if err!= nil syntax sugar for that 4 lines monstrosity, it was clearly a mistake being so opinionated about spacing and leaving error handling as an after thought

Who mentioned Bjarne Stroustrup? Why are you so obsessed with him?

Go 2.0 will fix all these issues

Attached: yammy.png (512x512, 292K)

This doesn't even make sense

A good programming language should auto-compete correct programs so I don't write errors.

If it ain't broken, don't fix it, lad. You do basically the same thing in C and no sane person (Java cucks can go let their wifes be fucked) ever complained.

golang is for literal retards

Attached: rmm19vt8vp911.png (2512x1018, 421K)

I am using it in my job right now, it's fucking disgusting, I envy those faggots working in typescript, rust and even c++ for the cleanliness and organization their languages offer

Go
>written by the guy who made unix
>created the language that would become C eventually
Rust
>created and maintained by tranny faggots, for tranny faggots
hmmph. wonder which one i'll pick

you don't know a shit, Go is a shitty language and the faggots who wrote it should feel embarrassed to say the least, it's abomination of a language, a fest of retardation

also you can't win a technical debate by bringing tranny words, low IQ NEET

>created the language that would become C eventually
Gotards have some strange revisionist history

Attached: portrait.jpg (500x335, 20K)

wtf I love go now

Rob Pike is also a faggot, and wouldn't be surprised if he go Bruce Jenner in near future

all richie did was add types to thompsons language

if i cant win a debate by using the word tranny you surely can't win it by calling me a NEET

I like Go and you Jow Forums niggers can't stop me.

surely only NEETs like you who bring a word like tranny to win a technical debate, because you actually haven't used this language or any other lang in a professional environment, also who actually cares whether a programming language was written by a tranny or whatever, it's just NEETs like you who think they are entitled to bash things they don't and can't understand

i like rust but haven't needed that much performance for anything recently, been dragging my feet on go after my last toy project, it's not as bad as php or anything just really unexpressive and unpleasant

are you being intentionally stupid or is it the tranny hormones? what technical debate? you posted a stupid meme and called people who use go retarded

try to apply for a job and then have an opinion in a programming language, NEET

Why would you write it like that?

>but if an exception isn't thrown then the code runs slightly faster than if you had to check & handle every error

But the code that does the throwing has to perform these checks.

I'd take trannies over Unix every day.

how so

Sure, but you need to branch when you yield an error whether it's done by throwing or by returning. The second branch, checking at the call site, doesn't need to be performed with exceptions.

"tranny" embodies the flaws of Rust and even the need of its conception. The special snowflake syntax all over, the obsession for a "safe" space where everything is perfect and no mistake can be made, and their dramatized, overzealous shilling of the language. They all smell of transexualism. Because they cannot accept what they are, they cannot accept how a language without training wheels can support most of the whole computer industry. They're a threat to programming as much as they're a threat to society and you can actually feel it in the language.

Dude, they call them "exceptions" for a reason. You're not supposed to be using them as cross-method GOTO's. You're supposed to be using them to scoping off your function into primary entry points (be they an endpoint, a ui function, or a message loop) and any type of EXCEPTIONAL errors/unintended behavior happening within them, (be they corrupted files, timed-out endpoints, data that makes no sense) they throw to a centralized place where they can be logged and not crash the entire system.

How does that feeling still having to glue your programs with plenty of system code in another language (won't name one particularly) in order to do anything remotely low-level?

cringe

I'd say people who uses a language that as fast C and ensures memory safety would propose least amount of threat in society. Now, anyone under the age of 30 using C is a massive thread due to their skilled ability to write shitty insecure software.

right. I'm fine if people use exceptions exceptionally. In the same manner, gotos can be used well. But my problem with them is that it's exceedingly easy to use exceptions not like that and completely abuse them such that they are being caught all the time (which makes them slow) and means that exception handling code propagates like a fucking virus throughout the code base.

The risk of this happening in my experience is too large that I would rather ban them.

And you are a programming language masturbator who'll never achieve anything more than fizzbuzz in your meme language.

Not an argument.

Banning them has a whole different set of issues, like how do you handle hardware errors like divide by zero dereferencing invalid memory? You can't do anything after the fact, so you need to prevent them altogether. Writing a safe program without exceptions requires checking every precondition to make sure these operations can't happens, which is costly. There is also the problem that only the caller knows how to appropriately handle these errors, but must defer the check to the caller. Exceptions provide a means for the callee to defer action to the caller without requiring a million enums for every possible error code a function may return.

It is an argument, if you think enough about it. If you wanna spawn a whole new environment for development, think about designing the system itself before the language it will strive on. The conception of the language will follow naturally if the system is elegant enough. As of now, any language that intends to replace C for systems programming is doomed to fail, because it feels like a chore transitioning (ahah) to the new language whereas the system you develop on it was conceived along with C. It's not worth it. It feels like a toy with which you reinvent the wheel instead of solving practical problems. Memory safety should not even be a language problem but a problem that should be solved at system level. Work on that before shitting yet another meme language.

>It is an argument
It wasn't, not reading the rest since you're clearly not a sound person to talk to.

That's what usually happens when you face someone with actual ideas and have actually nothing new to expose except your vacuity.

In proper Go it would look like

varFoo := x.GetFoo()
sliceBar := x.SliceTheBar(varFoo)
x.CheckBarSlice(sliceBar)
return x.Err()

A couple of magnitudes of performance difference. One is an if and a return, one is a full stack unwind

Huh, that looks pretty similar to

I dislike Go but I use it for little web services anyways. JVM and CLR languages are way too bloated and use far too much memory for small to medium sized services. I have a little Go site that serves around 10,000 requests a day and it uses around 15 MB of RAM and never goes down.

I also have Gogs install on a RPI that uses like 20MB of memory. Meanwhile, Gitlab basically requires 8GB of RAM or else it's slow as shit and occasionally crashes.

These threads work. Constant Go bashing with stupid points like 'lol no generics' and 'muh tooling' actually works. All the idiots on youtube like Mishook and Chris Hawkes will parrots these as bullet points. Even guys giving talks at conferences will mention no generics without giving any examples (how can you in a language with no OO and interfaces only lol). All I can say to everyone who laps this shit up is enjoy your forced OO patterns in Java, C#, C++

I've never seen Jow Forums criticise Go for lacking OO.

What kind of "remotely low-level" stuff are we talking about here? Because full-fledged OSes in Common Lisp exist even today, if that's the example you were going to bring up.

You mean you can run an OS designed for 1980’s hardware constraints on today’s toasters because of moores law?

What did google do to this man?