191–200 of 217 posts
Earlier quoted context omitted.
I'm saying I've had that stupid import error pop up in my face 5 times and changed my code as a result, rather than the imports, because it surfaced an error.
Shouldn't it be a warning, though? You'll still notice it, but you aren't forced to deal with the problem immediately.
Earlier quoted context omitted.
> I had a Python .... IMHO, the biggest win of Go over anything Python is the single distributable. You write once. Compile (or cross-compile) once. Distribute the binary. Job done. Python you've got the hell of dependencies. Write your script once, but then users have to endure pip hell for the hundreds of libraries you've depended on. And then the potential different dependencies between different Python stuff. Go…
Also, you can run that Go binary on any Linux system whereas with Python you'll be lucky if you can run on any non-Ubuntu/RHEL Linux system. Moreover, that Go binary will be like 10% of the size of a Python artifact (which amounts to significantly faster deployments and cold start times for things like Lambdas) and it will perform about 2-3 orders of magnitude faster than Python and there will be headroom to optimize…
Sure, it's not as nice or compact as a single binary, but "you'll be lucky if you can run on any non-Ubuntu/RHEL system" is massively overblown.
Earlier quoted context omitted.
Shouldn't it be a warning, though? You'll still notice it, but you aren't forced to deal with the problem immediately.
I'm not saying it caught syntax errors. I'm saying it caught actual bugs in my code. I don't want to be allowed to blow those off.
It did so 5 times, versus how many times it gave a false positive where you just had to delete the import or underscore the variable?
Warnings are intended precisely for this type of "hey, you probably made a mistake here". Errors should imo be reserved for cases where the compiler is more or less sure you are wrong.
Rust has probably the biggest possible focus on "making sure only correct programs compile", and rustc does not error on an unused variable or import; it gives a warning. Precisely because it does not know if it is a bug, or just, I don't know, "commenting out the code that uses it to try something".
Also, in the case of an unused variable, you CAN blow it off, by using _. In fact, this makes it far easier to forget about it later compared to a warning that can be silenced in the same way, because if it's a warning you'll only do it if you're actually sure, while with an error you might do it even if you're less certain, because it's absolutely necessary.
Earlier quoted context omitted.
It's not "shiny features". It's things that can make you more productive. Or would you say golang's channls are also a shiny feature? Also, I'm not "disparaging" anyone here. Please read it again and notice that I was simply saying that golang is good if you are inexperienced. That does not mean that every golang dev is inexperienced. If you interpreted my post in that way, I think you should probably ask yourself wh…
But you said: > Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck. which implies that people who use Go have not grown and become as productive as people that use more expressive languages (because such languages are a "must" to grow in this way). At the very least, you are obviously disparaging Go pro…
That's not what it says, or at least not what I meant.
People are different and can accept a different amounts of repetitive work. Heck, there are even people who really like it and want to think as little as possible. So all I'm saying is that there exist people in Go that grow and then want to improve their productivity but are now restricted by the language.
And I think I have a point in the sense that Go is already adapting to those people by e.g. adding generics. So the number of those people can't be that small, otherwise I don't think they would follow their requests.
> because such languages are a "must" to grow in this way
And yeah, there are of course different ways to become more productive, e.g. through other kind of tooling, better organization etc. But the language is definitely one of our most important tools so if the language limits you then switching it is the only way to improve in this regards.
In fact, English is not my native language and I often feel limited in both my mother tongue and English. Sometimes I'd love to just mix the two but obviously I can't. It's the same thing, but natural languages are much closer to each in terms of expressivenes than programming languages are.
> At the very least, you are obviously disparaging Go programmers' productivity.
I'm saying that a developer who feels limited by golang can and will become more productive with a less restrictive language, all other things being equal(!).
Earlier quoted context omitted.
Simply because it's limiting. Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck. For some people it's this feeling of being stuck that they don't like - others can live with it more easily. > I honestly also have no idea why Rust always makes an appearance in a Go thread Both Rust and Go people are ver…
I have about 30 years of coding experience, try again. C++ to Python, C to Go. Often I want to get shit done and not marvel at how smart I am.
Earlier quoted context omitted.
Error handling is strictly worse than pretty much any other language out there — you are only making you believe that you are handling your error cases. A pragmatic “handle it here or bubble it up” is a much better approach, as more often than not you can’t actually handle the error at call site. Goroutines in themselves won’t give you actually correct concurrency. I really hope that Go doesn’t replace Java.
>Error handling is strictly worse than pretty much any other language out there — you are only making you believe that you are handling your error cases. A pragmatic “handle it here or bubble it up” is a much better approach, as more often than not you can’t actually handle the error at call site. It could've definitely be better (just Rust-like Result type would make it so much clearer to handle) but Go's insistence…
I read it as "let's stop pretending we are wizardy wizards and can do things right way in 100% cases and let the language to enforce us to handle errors, producing better result for average Joe SR SWE".
Am I right with my readings (i'm not a dev guy at all)?
Earlier quoted context omitted.
It is good to be forced to recognize errors and manually send them up the stack. Too many programmers have a "not my problem" attitude about errors. 1. Immediately when the error occurs, send it to logging with all required data to find the exact point of failure + data to understand the "why". 2. Send the error up the stack. If you do these two things, your systems written in golang will be resilient.
So rely on the programmer countering their laziness instead of having these things the default in the language also known as exceptions?
Earlier quoted context omitted.
I don’t see any automatic bubble up with Go.
I don’t think the original commenter said anything about “automatic”. That’s more of a subjective decision—whether or not you manually bubble up an error, or it just floats up because of the exception handler. Empirically, java code has had terrible error handling, because people just stick one catch statement at the root of their program. Go atleast confronts you with the error at every step.
In go you would just verbosely (and error pronely!!) have to manually bubble it up, while this is automatically happening in Java with an informative stack trace, with no option to forget about it. Java is the one that handles error cases properly (and that’s why you might see exceptions more there — because they weren’t silenced somewhere wrongly!) here.
I was tired of the dogma of wrong in PHP. Everyone was an armchair expert trying to tell me how wrong everything I was doing for the last 11 years as a professional was.
Go was a relief. At first I didn't get the hype, why were variable definitions the other way around? But then I took the tour and bam. Instant love and i learned so much about everything using it.
It's not perfect but good enough for my needs.
I feel like it's a language that is the product of a higher language, like swift. Because it's so primitive. I also find it easy to translate thought to code with Go.