question: are Companies Migrating from Java to Go? it looks improbable once the companies generally doesn't matter to the tech, they matter to results... real result to the clients... fake video?
Giving a thumps up in the first 14 seconds! Not saying we shouldn't use scripting languages where they are useful, but every time I think about all the sad saps out there using Javascript to make their website, I kinda wonder why? When GO makes system level programing so easy, it only makes sense to design all your programs in a scalable language first!
Early return error is not a sub-type of Early return. Despite it looks similar in the Go code. Early return (in other languages early throw) error means whenever we are able to detect error -- we should do this as early as possilbe. Just look on the simple example that doesn't follow this principle: func divide(x, y float64) (float64, error) { if y != 0 { return x / y, nil } if x != 0 { return 0, errors.New("DIVIDE BY ZERO") } return 0, errors.New("INDERTIMINATE FORM") } func linearEquation(a, b float64) (float64, error) { root, err := divide(-b, a) if err != nil { switch err.Error() { case "DIVIDE BY ZERO": return 0, errors.New("NO ROOT") case "INDERTIMINATE FORM": return 0, errors.New("INFINITE ROOTS") default: return 0, err } } return root, nil } The linearEquation maps the error received from the divide function, because we don't check correspondent conditions directly in the linearEquation. So, in context of error handling "return early" means don't push the issue down to stack whenever it is possible. The code that follows "early error return" principle in this case must look like this: func divide(x, y float64) (float64, error) { if y == 0 { return 0, errors.New("DIVIDE BY ZERO") } return x / y, nil } func linearEquation(a, b float64) (float64, error) { if a != 0 { return divide(-b, a) } if b != 0 { return 0, errors.New("NO ROOT") } return 0, errors.New("INFINITE ROOTS") } So, here we can see that code doesn't follow general early return principle, but it follows the "early return error" one. DISCLAIMER: never trust in error messages, use custom error classes or error codes to describe the expected errors. The example above uses error messages just to reduce number of abstractions.
At 1:42 The pointer is already pointing to the address of Ninja itself, so why are you assigning jPointer = returnNinjaByPointer again? That's why it is slower compared to pass-by-value in your example. In fact, we only need to operate on one address when we have already passed the value by pointer, and it only takes about 0.3309 ns/op.
This was a very interesting demonstration. I love functional programming but this is making me re-think the way I do things. It would be nice to know what is the cause of this overhead that is introduced by the functional approach. Also, I wonder what the difference would be in doing an experiment on release code as opposed to debug. You would have to change the way you perform measurements instead of using benchmarks as I assume that would be in debug mode. I wonder if the poorer performance would be down to the extra function calls and the associated cost of cleaning up stack frames, but perhaps there could be a way of optimising away some of this overhead. Great video and gives me a bit of inspiration to perform further research in this area.
Is me, I know but why you don't use logical names instead of single character like in C/C++😢? At some stage I didn't know which one to use and their meaning like in the html file name everywhere, is the id, is the name😂, the value😅? Maybe I'm a newbie but for maintenance it will be a waste of time looking for those ...? Thank you!
4:48 bro! Even my grandma won't develop a REST api like this in Java, even dumbledore now uses Spring Boot. I use both Go & Java, but for the sake of showing a contrast of verbosity this was a terrible Java example, lol. Good video though! Thanks
Hey thank you for the content. I think it would be interesting to show go working with slice architecture given that both a re super minimalistic. Thank you again. Keep going :)
Channel "Golang dojo " shitting on java, seems legit :). I can say there's probably no real reason for most changes in programming apart from personal preference of the people in change and maybe development time. Can you develop faster in GO? I really doubt it but maybe.. ))
