91–100 of 142 posts
When I read go specs or go vs python comparison, nearly every diff is a specific pain point of our big python code base. No keyword argument? to hell with them. Strict formatting? That should be in python interpreter. No unused import: would have saved our lives. No cyclic dependencies? No inheritance? No exceptions? Great, all of them are maintenance nightmares.
I think the author misses the point. The number one reason Go was created was to build maintainable softwares , the kind Google uses at large. The easiest way to build these are: - Automatic memory management -> GC - Bug catching before the software is run -> Static typing - Overall simplicity -> few features, added only if it is extremely needed The thing is, when you start using Go, you already know its features. T…
Why do I miss the point if, like me , you think Go is the new Java? :-) I think it's exactly that, it works and that's fine, and why the JVM doesn't do cheap concurrency I don't know. If it did Java might have been the new Java :-)
Thanks for the article with your first impressions of Go anyway - I read another post on your blog while visiting (about leaving C++ for a simpler OO C), and it actually echoes a lot of the motivations of Rob Pike and others at Google in creating Go - frustration at C++ compile times and baroque grammar was a primary factor in the creation of Go, so it feels to me like they went back to C as a basis and built something new...
I think the author misses the point. The number one reason Go was created was to build maintainable softwares , the kind Google uses at large. The easiest way to build these are: - Automatic memory management -> GC - Bug catching before the software is run -> Static typing - Overall simplicity -> few features, added only if it is extremely needed The thing is, when you start using Go, you already know its features. T…
Please show how he misses the point. His point, it seems to me, is "Things _he_ would miss in Go that Python has". Maybe he doesn't want to write maintainable "softwares" (sic). Maybe his bugs look like open_file();close_file(); read_file(). Static typing can't catch that.
Earlier quoted context omitted.
> Generic methods is one place where non-explicit error handling is essential. And, really, the error-handling part fits fairly well with Go (not only what the language supports -- which is, after all, full-featured exceptions with a different [IMO, improved] syntax -- but also with the conventions on their use across public API, though that requires some thought about the motivation for that rule and how it applies…
> OTOH, Go's type system, as opposed to its error-handling approach, is a real problem for generic functions. Though if you just mean non-generic higher-level functions, this is less of an issue. Without generic types, I don't think generic programming is very common in Go and exceptions won't be missed much yet. However, if they ever get around to adding them, I expect dominoes to fall :) > To fit with the Go conven…
Exceptions won't be missed at all, with or without generic programming, because, and I get tired of saying this, Go has exceptions. panic/recover/defer provide all the functionality of raise/catch/finally -- the main difference in structure being that (1) the context is always a function, not some other block within a function, and, (2) "recover" is done within a deferred function (loosely parallel to an "finally" block) as opposed to "catch" which is done in a sibling block to "finally". [1]
> So panic is basically an exception
Yes.
> but in callback form rather than block form
No.
Earlier quoted context omitted.
I'm not objecting to you choosing not learn something in depth because you don't like how it looks on the surface (that's a rational approach to avoiding wasting time, which is a valuable resource), I'm objecting to you, in the linked article, commenting in depth (and inaccurately) on something its clear that you decided not to learn in depth because you didn't like how it looks on the surface. The statement that Go…
[deleted]
I'm not worried about people who have learned Go getting turned off by inaccurate comments about it not having exceptions, I'm concerned about people who might read your piece before learning much on their own. If people believe your claim that Go has no exceptions and that multi-level error handling in your own code has to be done the way you described, that could turn people off of Go whether they like the standard library or not (and before they even decide whether to try it at all.)
Earlier quoted context omitted.
> I almost never used operator overloading in C# or Java. Dude, you can't overload operators in Java. You can overload methods of a class, but not operators. Operator overloading means that you can overload '+' for example for your particular class, which would enable you to write code like (in Java): Matrix a = zeroMatrix(4,4); Matrix b = identityMatrix(4,4); Matrix c = a+b; You can't do that, so you would have to w…
It's important to note that numerical calculation is a domain particularly suited to operator overloading simply because the underlying domain (math) already uses operator overloading heavily (e.g. multiplication means something different when done on scalars and vectors, but in both cases it is well defined and in common usage).
- Math (and it's very close relative logic) are the only domains that use operators, period.
- other domains use overloading; homonyms are very common.
Earlier quoted context omitted.
That creates some mostly unnecessary boilerplate. I.e., if an error happens down the stack in function to read config, which calls a function to parse a file, which calls a function to read a file, you'll have to either propagate (or otherwise handle) that `err` manually or lose the precious information. On the contrary, Java-like pattern of functions like `Config readConfig() throws IOError, ParseError` simplifies c…
OTOH, if you follow Go's idioms and handle every error where it happens, your code will look like having a lot of boilerplate at first, but you end up with better error handling. It's the same as putting a try-except catchall around every single call in python, because in python you can never be sure (without reading the source) what kind of exceptions something will throw. For request based services and something wh…
This is what the debate is about: "if".
The problem with Go's error handling is that people don't handle every error. And due to poor documentation structure and returning one error type, often you have to even go digging through source code to just find out what the specific error values can be and under what conditions they occur, which makes it easy to write code that you think handles all error conditions but in fact does not.
The code on the golang web site didn't even check the error code from println and you never see this done in code. If you point this out you're met with "why would you want to check that error?", which is a tacit admission that Go programs will always have missing error handling and that "if" in "if you handle every error" is never met in reality.
In contrast to this there are no Java programs that don't IOException from a failed println, and yes even println can matter. Redirecting output with ">&-" is different from ">/dev/null".
Earlier quoted context omitted.
I try to advocate polyglot programming - using the best tool for the job - everywhere I go, but unfortunately people are largely allergic to the idea. Most programmers don't want to learn new tools, much less new paradigms or methodologies. Even worse, the management agrees - the upside of building better systems isn't convincing enough to justify a temporary drop in performance while learning. More to the point, I d…
Though I agree with, the primary argument that I've heard has always been that fragmentation/heterogenous systems in a corporate infrastructure make the human and capital management more of a nightmare.
Earlier quoted context omitted.
You shouldn't be putting a try-except catchall around every single call in Python. Exceptions mean you don't have to do that.
For me the most important thing exceptions mean is that they might pop up at any time, with unpredictable types. So as long as I don't have a catch all exception handler wrapped around all code, it might crash at some point.
It's ironic that the author dismisses C++ to a small niche: > Those who still stick to C++, after all these years, either really can't live with the "overheads" (real time apps - those are waiting for Rust to mature), or think they can't (and nothing will convince them except a competitor eventually forcing their employer out of business). Yet later he gives a good example for an important area where C++ is still unb…
Zero-cost abstractions come at a pretty hefty price if you pick C++. The cost is in programmer productivity & quality of resulting software. I'm sure there are some fields of academia where this is a reasonable tradeoff (if you're programming DSP algorithms running on a embedded battery powered device strapped to a dolphin, say...) but your generic number crunching job rarely calls for it. (As an aside, zero-overhead…
I agree with you. But as with most prices, sometimes they are worth it. There are a lot of practical cases where you really want the performance (even outside scientific computing, which in itself is a pretty widely applied field).
> I'm sure there are some fields of academia where this is a reasonable tradeoff
I'm not sure where you got "academia" from; scientific computing is in no way restricted to research. Weather predictions, genome processing, and oil reserves exploration are just three of many examples for the commercial application of scientific computing.
> (if you're programming DSP algorithms running on a embedded battery powered device strapped to a dolphin, say...)
DSP applications are ubiquitous today; you'll find them, e.g., in your phone, or in your car.
> but your generic number crunching job rarely calls for it.
You're very wrong. Number crunching is the example for which you want lots of performance.
> As an aside, zero-overhead abstractions being unique to C++ doesn't sound right to me.
I didn't say they are. I said that no other language offers them to the degree that C++ does.
> so maybe it's just a name for C++'s tradeoffs?
No. It means abstractions which do not cause runtime overheads because the compiler can optimize them away.