Why I’m Frustrated with Go
dev.to
dev.to
In general, I found it a chore to maintain Go-based systems.
There's a lot to like about Go. But it doesn't seem pragmatic for the types of applications I see people using it for.
For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log + "sorry, try again"). You can do this with error values, but at best it's verbose. Maybe error values makes sense for system programming, I could certainly believe it makes more sense.
But, really, the main problem is the type system. I'm a huge fan of dynamic languages. I think they're so much more productive. This is especially true when your system is interacting with external data - like user input and a database. I did C# and Java for years. These interactions are, at best, painful with static languages. But they're downright infuriating in Go (poor reflection, no generics). I wrote a somewhat popular library to help deal with map[string]interface{} nonsense (2), but it's not enough.
When it comes to web/tcp stuff, I think OpenResty for any middleware-ish system and Elixir for everything else are far more productive and enjoyable ecosystems. We've been doing Elixir for about a year now, and I've never seen such a consensus on productivity and quality (everything else always had some issue: Ruby is slow, Node is single threaded, Java is verbose).
There's certainly more space than just that. Go might still be a good choice for CLI tools, and both OpenResty and Elixir have a distinct memory/threading model that precludes some use cases - but those are in the minority.
(1) - Nothing against Erlang model, but I do think it's more restrictive.
My opinion is the opposite. Almost every go code base I've seen is extremely consistent compared to other languages. Going from one code base to another is almost always seamless because learning Go involves learning the Go tools which forces you to follow Go coding standards. I'd choose to work on a Go code base over Java or C++ any day of the week.
I don't have much experience with elixir, but that's because I like to stay employed.
>the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler
This is almost always unacceptable in production, especially when it comes to mission critical hard/software. You need to be able to handle errors in production that you may not even be able to catch in testing and that means you need to catch all the errors and think critically about what should be done when that error is encountered. "Central error checkers" are almost never robust enough for mission critical systems.
Go basically forces people to write high-quality, resilient code bases, and I like it for that.
While the previous commenter gave an objective and rational overview why he think Go gives him a hard time you can't resist to get polemic.
Same message and nobody loses his face.
Maintaining Cobol code is a chore, though, partly for the same reasons as Go code.
But, that doesn't really have anything to do with it being a chore. We can just agree to disagree on that.
However, I think you misunderstood my point about errors (or maybe you're just working with very different types of systems). Empirically, looking at Java codebases, the C# team found that most errors weren't "handled" beyond an outer exception handler. Anecdotally, this has been my experience as well. I admit that this is a very 'web' point of view, where requests are isolated and most exceptional situations are best handled with logging + showing the user a friendly error message.
At this point, they should adopt the Elixir approach and consistently provide a ! alternative across the stdlib (Must* is inconsistently available and verbose). They thought Go would be used by C++ programmers, instead it's being used by Ruby programmers (1). The language paradigm doesn't fit how people are using it as well as it could.
I'm not sure what other languages you've been exposed to, but your last line is hard for me to believe. If you look at other languages, you'll find a lot of techniques aimed at quality and resilience that are nowhere in Go. Again, that doesn't make Go bad, but "resilient" ? Go has mutable, shared memory, nils, no thread isolation, no generics (so runtime casting), no pattern matching and so on. Even the error system which you like is reckless (??) compared to what you'll find in languages like Rust and Haskell (Result and Maybe).
(1) https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
> This is almost always unacceptable in production, especially when it comes to mission critical hard/software. You need to be able to handle errors in production that you may not even be able to catch in testing and that means you need to catch all the errors and think critically about what should be done when that error is encountered.
Absolutely. My approach is usually that errors are always wrapped not just returned. The wrapping itself ends up looking almost like code documentation: "could not do X: <previous error>", "error while doing X: <previous error>". Every error string is then unique in the program, easy to grep.
"Could not perform the operation", maybe together with a 500 lines stacktrace in your logs (which are maybe line-by-line bacause that's the default)... you are up to a nice middle of the night debugging session :)
This is not true for almost all software outside of embedded domains. In fact responding to an error near where the error occurred is almost always a mistake. The rare exceptions to this are when "error" is unavoidable due to concurrency (e.g. I/O), and even then many errors shouldn't be handled (misconfiguration, incomplete system initialization, etc.) or should be wrapped and transformed for human consumption (e.g. user tried to access a resource that couldn't be found - we still bubble up).
> you need to catch all the errors and think critically about what should be done when that error is encountered.
If you support this position, you'd support checked exceptions like Java - something that's widely considered a mistake.
There's lots of reasons why it's a mistake. A more important reason has to do with dynamic construction of control flow. If you use any monad design patterns in the construction of your application (easy to do because the monad design pattern is so powerful), you quickly create boundaries that errors need to cross unmolested because they're generic and cannot possibly encode policy. The same criticisms follow through into dependency injection and other forms of modular decomposition that use dynamic recomposition. Java style has you doing utterly pointless things, like wrapping all the implementation errors in a generic module-level error - obscuring the very thing that might theoretically let user code react to the error state!
More philosophically, abstractions fail in implementation-dependent ways. When you encode policy about failure outside the abstraction boundary, you're encoding implementation-dependent behaviour; but you can't put the policy inside the abstraction boundary either, because then the abstraction isn't reusable - different applications have different policies. Error handling is inherently opposed to abstraction. That's why microscopic error-handling close to the cause of the error only flies in small closed systems, like kernels, databases, embedded.
The primary problem of checked exceptions in java is not that they exist, it's that they are very badly integrated with the rest of the language e.g. it's impossible to be generic or transparent over checked exceptions, their hierarchy is messy and it's often unclear why specific exceptions are checked and others unchecked. Haskell's error handling (reified through Either error values) has similar effective semantics but nowhere near the dislike because it's well integrated in the language and you can be generic over the error, the value, and the result itself.
Generic composition that lets error types flow through abstractions also lets implementation details flow through, so it is an architectural choice, make no mistake. You don't dodge the tradeoff between abstraction and error handling.
Yeah, because Go is the epitome of employability...
>"Central error checkers" are almost never robust enough for mission critical systems.
Go is not used in mission critical (embedded, medical, aviation, communications, etc) systems anyway.
Besides the notion is wrong: mission critical systems DO centralize error checking. The code local to the error wouldn't have enough context (and shouldn't have the reach) to call the right procedures for cleaning up and moving on.
Why? I find when you're importing external data or user input, that's exactly where you want strong types as that's the most likely place unexpected values are going to be generated (e.g. unexpected null values, string instead of an array).
Let's say we're doing a user registration. In most dynamic languages the JSON body will get parsed into a map. Excuse the fat controller and pseudo-language, but it'll end up looking something like:
func create(conn, params) do
if not Validator.is_email?(params["email"]) do
return error(conn, "email is not valid")
end
if not Validator.min_length?(params["password"], 10) do
return error(conn, "password must be 10 or more characters")
end
create_user(params)
true
end
type RegistrationInput struct {
Email string `json:"email"`
Password string `json:"password"`
}
var input RegistrationInput
if err := json.Unmarshal(req.body, &input); err != nil {
...
}
What safety does Go's version buy you?
Now, if we are talking about error handling, the way it is done in Go is not particularly representative. Most static languages would go with exceptions (or maybe checked exceptions in Java). Haskell/Rust/Scala would probably go with a Result type, and then it's more a question of the language giving you the tools to propagate the errors and wrap them (Rust with error-chain is excellent at this kind of thing).
Your code starts by making a few checks on the shape of the data you're receiving and failing earlier if some conditions are not met. Great.
Once these checks are cleared, you now know that you can materialize an object with valid values in it, something the rest of your business code will be able to manipulate. So you instantiate that new object, return it and... all the knowledge about the shape of that data is lost.
The only thing your callers will see is an Object and zero information about what operations or fields are available on this object. They'll have to guess.
With a statically typed language, you don't have such a problem. You have asserted all these properties about the data that came in, you know exactly the class of the object you are creating, why forget all this precious information that will keep your code robust?
In my experience, dynamically typed languages are at an evolutionary dead end and offer close to zero advantages over modern statically typed languages (e.g. Kotlin, Swift).
I'm not really seeing how that necessarily falls out of the example given by GP. Could you go into that in more detail?
Is there something preventing create_user(params) from emitting an object with a well defined interface?
If you call that function, you have no idea what the type of that object is. Only the function knows it and that information is lost as soon as the function returns.
And yes, you really have no idea what the type of that object is unless you look at the source of the function. Which is obviously suboptimal, especially if you don't have access to that source.
A statically typed version guarantees you haven't made some fundamental mistakes and enables automatic refactoring.
Say we wanted to change an ID field from being a string to an int later in development for example. You've now got to hunt around all your files making sure the right type is being used. It feels incredibly primitive when you need to do this manually or have to rely on an exhaustive and annoying to maintain test suite for this.
As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful.
See marshmallow for Python: https://marshmallow.readthedocs.io/en/latest/
It will validate everything, including nested recursive data with cross references in fields and a need for sanitation and casting. But you don't need a lot of code to do so.
Static languages are good to enforce safe practices at scale . That's why they are popular in big IT structures. Dynamic languages are fantastic when you have a lot of external data manipulations. Hence their popularity for the Web, banking, biology, geography, etc.
>>> (1,2) > {1: 2} True
>And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful.
Marshmallow looks like it works the same way as existing systems in statically types languages. e.g. Serde in Rust:
This validates at compile time.
In [60]: (1,2) > {1: 2}
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-60-f9d83a4c8f73> in <module>()
----> 1 (1,2) > {1: 2}
TypeError: '>' not supported between instances of 'tuple' and 'dict'And the keyword in my schema validation sentence is "easy".
I love rust, but a low level language cannot be compared in productivity to a high level language for this stuff. They are much, much easier. That's the whole purpose. You trade easiness for rigor.
You mean a dynamic check? It's better than nothing but I don't exactly want my e.g. scheduled data import process crashing because it was sent some bad data. I'd much rather have static checking and have all the possibilities accounted for before the code runs.
> As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful.
Why couldn't you write this with static checks? Statically checked functional languages for example are great for writing compilers.
If you have decent type inference there isn't extra typing and any time you think you're saving with dynamic languages gets eaten up having to manually fix things when errors happen at runtime. I'd much rather spend time fixing predictable compile time errors than unpredictable runtime errors.
I do like Erlang's approach with hierarchical error domains ("processes" and "supervisor trees"), and I honestly think Go made a mistake here: The semi-recent introduction of Context acknowledges that a control hierarchy is present and an important part of a concurrent, distributed application and that there are aspects of this that need to flow through everything. The Context exists to permit a caller to call functions and launch goroutines that inherit deadlines, the ability to cancel their work, and so on. But this is a rather blunt and intrusive tool that could have been better solved by baking termination into the goroutine scheduling runtime. Of course, one reason goroutines cannot be forcibly terminated is because everything is mutable all over the place, but you could still have termination induce system-level errors that the goroutine would be forced to handle (or maybe you could safely induce a panic)... but that ship seems to have sailed a long time ago.
And yet a hierarchical approach similar to supervisor trees would have been awesome to have in Go. Managing hordes of complex, "crash only" goroutines in Go gets gnarly fast, and you tend to end up with your own ad-hoc type of supervisor trees that uses waitgroups and maps and what not to corral trees of composed workers to ensure they are all able to cancel, retry + back off, and time out appropriately. Even something like retry with backoff isn't part of the standard library, even though it's extremely core to distributed, concurrent programming.
I think I agree with Go's authors that exceptions are bad, but exceptions in an explicitly hierarchical, supervisor-type process model, where processes are "crash only", actually make sense. It means you tend to design your system into discrete parts consisting of dumb workers (that give up and crash on the smallest error) and slightly less dumb supervisors (that react to said crashes). It's not a panacea, but it's better than the loose, somewhat impoverished set of tools that Go gives you.
I really like Elixir and the Erlang VM but supervisor trees are not a perfect solution either. For all the talk about how in Erlang you just let things fail and don't have to do defensive coding, any non-trivial application requires a lot of very thorough design on how to handle error scenarios and keep your application consistent.
If a process fails too many times too often (say your web service it's trying to ping is inaccessible) it can take out your whole supervisor. If that supervisor is holding an ETS table that holds important coordination data (but not data that requires persistence) that ETS table (and all it's data) is now completely gone, and unless that case has been handled you have a lot of processes running but not doing what they should be doing, and your application is inconsistent until you completely shut it down and restart it.
And if you don't plan for a lot of these scenarios then you will be caught completely surprised when it happens in production.
Also you have a lot of control of your supervision tree. You can specify the quantity and frequency of failures that would cause a supervisor to fail. For some use cases, 3 failures in 5 seconds might be reason enough to restart that supervisor. For other use cases, a much higher failure rate might be justified.
These decisions are not trivial and are exacerbated because of the Actor style of flow due to the independent pieces.
So from my experience you have non-BEAM languages where a single error can take down your whole application if you don't plan your failure scenarios properly, where as in BEAM languages if you don't plan your failure scenarios properly you are more likely to end up with an inconsistent system. The former isn't that bad in a lot of circumstances as you should have an external application monitoring and restarting a critical server that's no longer running (even for BEAM systems) but the latter can be very bad because it can be a silent issue.
I have systems working at my job written in .net that have been running for over 6 months without a restart, even when Azure had failures and it could not talk to its command and control server for an hour and kept running perfectly fine with using a well thought out architecture and a well placed central error handler for generic errors without things cascading throughout the whole system.
So resiliency has less to do with language or supervisor trees and more to do with making every step has failure scenarios thought about and planned for.
You are correct that this is how it's often done - 9 out of 10 errors probably ARE "handled" by a central error handler. But this is an incorrect approach if the goal is a reduction of catastrophic errors.
In the following paper, "Simple Testing Can Prevent Most Critical Failures" (OSDI '14). the authors discuss how some catastrophic errors occur in distributed systems that they test (Cassandra, HBase, Redis, HDFS, MapReduce).
http://www.eecg.toronto.edu/~yuan/papers/failure_analysis_os...
Notably section 4.1: Trivial Mistakes in Error Handlers:
"""
Figure 5 further breaks down the mistakes into three categories: (i) the error handler ignores explicit errors; (ii) the error handler over-catches an exception and aborts the system; and (iii) the error handler contains “TODO” or “FIXME” in the comment.
25% of the catastrophic failures were caused by ignoring explicit errors (an error handler that only logs the error is also considered as ignoring the error). For systems written in Java, the exceptions were all explicitly thrown, whereas in Redis they were system call error returns.
"""
I haven't used Go much but I personally much prefer Rust's error handling which appears to be largely similar.
As for infrastructural software, yes you want to handle errors in a more thoughtful manner. If you can't and the process has corrupted it's own stack or heap (in the case of C or C++) then sure, abort. But I'm saying this line is often chucked over to "log the exception and do nothing" too quickly because it's often the easier thing to do. 25% of catastrophic failures in this one study appear to occur because of this.
tl;dr: The devil is in the "If you can't".
You can still utilize all of your cores in Nodejs. So which problem are you encountering?
Please, nobody write full fledged WebApps or all of your middleware in lua. Trust me that's a horrible idea. I have seen about everything you can do in lua/nginx and it does not turn out pretty.
Is this a happy-hour for Reddit users on HN?
* Unfortunately error handling sucks (no stacktrace by default? Let's go back to the days of peppering print statements around just for fun).
* DB support is terrible (I've spent hours doing what I could have done in half an hour with python).
* It's so verbose, even simple things like mapping over an array to create another array requires a for-loop dance. Same for just checking if a value is in an array. Same, obviously for no exceptions which you either love or hate. I hate.
I can't see myself doing any other projects with it.
goroutine 1 [running]:
main.b()
/home/rjp/git/godiggy/test.go:8 +0x64
main.a()
/home/rjp/git/godiggy/test.go:13 +0x9b
main.main()
/home/rjp/git/godiggy/test.go:18 +0x9b
exit status 2This hasn't been my experience. I work in Python (and JS) by day, and I can't wait until we upgrade to 3.6 so I can reasonably employ type annotations. Without them, people tend to write hacky code, such as functions which do completely different things based on the data type passed in (rather than fixing the abstraction) or build up huge, nested data structures with no formal definition (various parts of the code base just tack on whatever they like, and the documentation inevitably falls out of date). Even my prototyping is in Go, because I would rather have a compiler catch my errors than to spend tenfold the time trying to debug. Also, when I'm working in Python, I sorely miss the tooling that I have in Go and other static languages.
I don't think Go is the end-all-be-all of programming languages, but I think any dynamic language would be more productive if it was at least optionally typed.
Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data.
Also, to provide good 'const' support in containers, you usually have to provide extra read-only iterators that are largely identical to the writeable iterators. Go look at the C++ standard library. All the containers have both 'iterator' and 'const_iterator' (not just a 'const iterator').
Another approach is to just declare member variables 'const'. So you have a 'const map<int, int>' as a member variable. Except for that to work, you need to construct that member variable in the initializer list. The body of the constructor is too late. This likely means taking an already-initialized map as a constructor argument and copying it (probably exposing implementation details in the process) or writing a helper that returns the appropriate map type and copying it. Good optimizers will elide many or all of these copies, but relying on quality of optimizers isn't portable.
Anyway, I'd say the complexity of the Go approach isn't significantly worse that the C++ alternatives, if it's worse at all.
(1) Of course, with casting shenanigans or use of the 'mutable' keyword, anyone can circumvent 'const' without a lot of work.
Both are just immutable views on top of mutable containers. But in both C++ and Java it is trivial to create a truly immutable container of T. Not so in Go.
This is possible, but it's an unfortunate form of code duplication.
const std::set<int>& s // This is a read-only view.
const std::set<int> s // This is immutable.
Foo() : s(helper()) {} // This is a move, not a copy.I would also mention that using mutable and const_cast is frowned upon and it can be trivially searched for and forbidden.
Their comment about const iterators also misses the mark. Yes, the designers of the C++ standard library did a bit more work and now everyone has a high-quality type-safe dictionary implementation available. That's how it's supposed to work...
On the contrary, I've had to mentor a lot of C++ developers where they were surprised when their put-const-on-it approach to providing safety resulted in production bugs. I think it's fair for people to be surprised by this sort of thing. And I don't think the things Go developers have to do are all that much worse than equivalent code in C++.
In C++, 'const' mostly means the compiler will give you nice diagnostic errors if you do mutable things to 'const' things. There aren't any guarantees about the data itself being unchanged.
> the designers of the C++ standard library did a bit more work
My point was that all container implementations need to do the same work if they want both const and non const iterators. You can't just return 'const iterator' from you 'begin' method because that implicitly converts to a non const 'iterator' and a mutable view of your container.
> Yes, the designers of the C++ standard library did a bit more work and now everyone has a high-quality type-safe dictionary implementation available.
I very much appreciate the hard, mostly unpaid, work that people put into the C++ standard. But everyone has to do a bit more work if they want, say, a read-only key-value store laid out in contiguous memory. The standard key-value stores are a pretty straightforward rb-tree and a suboptimal (to allow for iterator semantics) hash table. It's not hard to implement (again, due to hard work from the standard committee) a sorted vector<pair<Key, Value>>. It's a bit of arcane work, however, to make that optionally const or to have it share an interface with map and unordered_map.
I mean the discussion was about declaring a simple map. In that context, it really is as easy as writing
const std::map<int, bool> map;
It was on topic because I am saying the C++ boilerplate wouldn't really be better than the Go boilerplate. All the "out of context" details are basically my point. You need to know a lot of surprising things to C++ well.
Can you provide any concrete example on how adding a const qualifier introduces bugs? Besides disallowing calls to mutable member functions, adding const qualifiers changes nothing in the code.
> Foo() : s(helper()) {} // This is a move, not a copy.
First, I'll point out that the data of s is not immutable. The fact that you can const_cast away the const and change the value makes that clear. If people do things like that (or corrupt memory or have race conditions in the code), C++ doesn't necessarily give you clear exceptions or compiler errors. Many of the ways to break things result in "undefined behavior", which might involve data corruption and crashes. I've seen both happen to 'const' objects in production code.
You have a fair point about the move. But not all projects are using C++11 yet. And your use of a 'helper()' builder was actually part of my point as well. The article complained about all the extra code needed in Go to do immutable maps. But it's not true that in C++ you can just add 'const' to a few spots and move on.
I'll also point out that having the 'const' member in 'Foo' likely makes it impossible to implement assignment operators and possibly a move constructor, depending on what you are doing. It's likely if you want to have read-only semantics in your data in C++, you'll have to be aggressive using unique_ptr and shared_ptr so that you can have things like proper move semantics. And that means you'll likely need to be checking for null data.
Point being, you can achieve read-only semantics in C++. But it's not foolproof and it's not as clean as the article seems to imply.
const std::set<int> s; // This is immutable.
const_cast<std::set<int>&>(s).emplace(); // This is UB.No, you cant. The standard states that "any attempt to modify a const object during its lifetime results in undefined behavior".
If you're intentionally writing code that relies on undefined behavior, you are intentionally writing broken code.
const std::map<int, int> constMap = { {1,1}, {2,2 } };
How is this not immutable data, and "only provides a read-only view"?
It is linguistically guaranteed to be non-mutating - const-casts excepted of course.
All languages that are constructing const data types on the fly are putting them in a writeable pages in memory, after all.
Technically even after const-casting, if it was declared const then it's still not possible to mutate it, as doing so is undefined behaviour. "Modifying a const object through a non-const access path and referring to a volatile object through a non-volatile glvalue results in undefined behavior." - http://en.cppreference.com/w/cpp/language/const_cast
It could for instance have been stored in non-writable memory, so any attempt to write to it will instantly segfault. This is one of my favourite things about C++ as people engaging in terrible programming practices like const-casting a const object get their just desserts, so to speak.
Ended up with this. [0]
Turns out the Go authors don't think you should do this so I had to majorly alter and recompile the stdlib.
I still appreciate many go tools and the cross platform single binaries that work great on Solaris/Illumos. But in many cases the strong opinions of Go authors really stand in the way of getting work done.
This is supported by the fact that contexts have been added, and I won't be surprised to see Go reverse more of their decisions as the language grows and devs prioritize shipping over Go dogma.
I left it a while back, with a lot of the same frustrations. But then I tried a bunch of other things, and nothing seemed to work better. There seem to always be some frustrations with whatever language. And I found myself craving that simplicity again.
I might get annoyed with it again, and try some other stuff. And that might stick. But I suspect Go is the worst language except for all the others [1].
[1] http://www.goodreads.com/quotes/267224-democracy-is-the-wors...
In retrospect however, I was frustrated with these languages because I was wanting it to be something it wasn't. To my mind, the loss of that feature meant that programs were less expressive - particularly in large codebases - I had to read methods to work out if something was being modified or not.
To complain here about Go lacking immutability and constness features seems to be the same as complaining that it is missing in Python, Ruby or JavaScript. It's a fact that constness isn't a feature of these languages, if you want these features, use a different language.
Go should have had it from the beginning IMO, immutability can help avoid some coding mistakes and also makes it easier to reason about code. It'a nice match for a language with static typing.
It deprives the creators of that technology of the opportunity to react to any complaints and it deprives everyone else of the opportunity to choose a different technology from the start.
If that's enough for you to consider that a language provides a feature, just wrap the immutable ordered map implementation in your blog post in a library, publish it, and now Go provides that functionality too.
Every user of the library will need to run codegen to post-process their source files and generate the relevant instantiations of the "generic" collection.
[0] https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
In either case, the reason was that the target language was considered not expressive enough, though ubiquitous.
I don't know if there is a term for Go like programming. I'm tempted to call it minimalism. It may be uncomfortable for people coming from classical programming, but the simplicity of the language and the code is a clear win in the long run.
Now it seems everyone is bashing Go. Moral of the story; never buy into the hype whether it is positive or negative. I think that Go is just fine and so is Node.js.
Maybe the author of the article makes a valid point, but no language is perfect and ultimately you have to understand it well in order to use it well.
It seems a lot of these articles, and programming language theory in general, is just complaining about features without any thought as to why they matter. What is this "problem" stopping him from doing? Why does it matter? And why should I abandon a language that has served me very well just because some edge-case feature is not supported?
Once I figure out what it is, I ask myself what problem it solves (the literature typically doesn't say). The answer tends to be one of:
1. Saves some typing.
2. Saves some work when refactoring.
3. Avoids some class of bug.
4. Highly useful in a kind of programming I don't do (e.g. compilers).
#1-2 in my experience are much more common than #3-4 and often #1-2 can be dealt with through tooling (IDEs for example).
This is the major problem I have with this sort of article; people never talk about languages in the context of actual working programs, just engage in dry theorizing or armchair programming. If the author put the complaint from this article into context, I'd not have a problem with it. But because it's a toy example with no relevance to actual programs people might want to write and use, it's unhelpful and misleading.
Almost 30 years ago when I first learned C one of the first design principles I was taught was to avoid mutable global variables. And ever since that time I haven't found anything as key to avoiding bugs as knowing and controlling exactly what code can change what data.
I find it totally baffling that a practicing programmer could possibly think of mutability as a purely theoretical concern.
This fad of using immutability everywhere and treating it like a silver bullet absolutely is new and is a fad.
I mentioned global mutable state as an anecdote and also as an example on one extreme end of the spectrum that should make it clear what the problem is in principle: Not knowing what code changes what state.
But I see that you have decided to avoid debating the core issue entirely.
Your mention of Go's const keyword in this context leaves me scratching my head as you probably know that it doesn't allow you to define immutable maps, global or otherwise.
One thing you're correct about: I have avoided debating it, because debating concepts like this is pointless and has nothing to do with real-world code. Which brings me back to the point I made on the article: why does he care so much that he can't have an immutable map? What problem can he not solve as a result of it? The example he's given is a toy problem, and the constraints that make him want such a thing are left unspecified.
It does have everything to do with my real world code. There is not a single piece of code I have ever written that let me get away with not keeping track of all the mutations that could possibly occur.
Let's leave aside complete immutability for a moment and consider a closely related issue that you can see in his code. He needs a map with defined iteration order, something I have needed occasionally in real world code.
He uses Go's builtin map type and a slice to define such a map. Now, how do you keep these two data structures in sync without restricting mutation? I think it's obvious that controlling mutation is a requirement here.
Go even admits that restricting access to data (i.e encapsulation) is necessary, and obviously preventing inconsistent mutation is a key reason why that is needed.
But then Go turns around and says, oh but you can't define fully featured data structures (i.e supporting range loops, type safety and indexing expressions) of your own that use encapsulation.
I have defended Go many times before, but the only way I can defend it is to say, yes it's true, this is a major weakness. We just don't know how to fix it without creating a lot of complexity elsewhere.
1. What the heck is this thing everybody keeps talking about, with an impressive fancy name? It must a major step forward, after all this time, I should finally have a look at it.
and then
2.a. Oh, it's just a big shiny name for something I accidentally kinda do sometimes, I didn't know it bore a name. Why is it suddenly a fad to base everything on this?
or
2.b. Hmmm... right... so in C it would mean doing this and this... hmmm... okay... and why would I want to do that? I could do it in C, if I haven't done it yet, that's because I didn't see the benefit of it, and I still don't.
Possibly. But I use other languages, and I sometimes use a few of those other features in those languages, but I don't miss them at all when I come back to, let's say, C. They don't fit, or don't bring benefit, etc.
As noted in the post, generics could solve this, so I'm looking forward to Go 2 if indeed generics is included. There's a few QOL issues I'd like to see addressed in 2 which would make Go a lot nicer to work with, and I say that as someone who spends most of their time working on Go codebases.
I'm always wary of such "<language X> isn't great because..." posts as I find that the frustration is as much a function of the developer's competence, (lack of) imagination and familiarity with the language and its idioms, as it is with the language itself.
The blog posts topic was not "immutable data structures", rather the need for boilerplate code in Go because of the lack of generics. The particular example was one of immutable data structures, however that was an example rather than the topic. The author themselves notes that "generics would solve all of the issues above".
> No, Generics make it possible to create a generic immutable data structure
I am sure i can read.
James' comment you quote was responding to your comment, which he parsed generically as "Generics don't solve T", with a comment of the form, "Generics make it possible to implement a generic T."
I'm confident you can read, but I'm not so sure about your reading comprehension and critical thinking.
Might as well not pretend something is an ORM if it can't do the fundamentals (like upserts), fully hydrating structs, etc.
So I wrote bellows [0], a helper to flatten and expand nested maps and structs. Not quite the same but might help someone.
[0]: https://github.com/doublerebel/bellows/blob/master/README.md
I was thinking of the ImmutableDictionary that's more recent. Normally in C#/Java you should rarely expose collection types directly so you almost always encapsulate the list/dictionary and provide e.g GetReservation(string id) to the outside, which makes it less common to even need the readonly types at all. Immutable ones are a whole different thing since they enable proper sharing of whole collections.
Me neither. But I have reached for a fast single producer, multi consumer queue, futures/promises, concurrent safe maps, non-blocking queues, and even plain async queues with batch semantics, many many times.
So either the author, me and everyone else that is claiming this is a problem are doing it wrong or its actually a problem.
Java doesn't do that well at all though; its immutable maps can be used in place of mutable maps, since there's no way of having a Map interface that extends ImmutableMap to add extra operations, so you can get nasty runtime surprises if you've got the wrong one. Conversely, if you want a mutable map keyed on a non-trivial structure, you have to do just as much boilerplate as the author complains about to set up private members, setters, builders, etc.
Obviously C++ can do it quite readily, but nobody accused it of lacking features.
This is really just another use case for generics, and the discussion there is well-trodden. Go probably isn't the language for you if you value generics more highly than fast compile times, native binaries, etc, but I'm not sure why that still seems to come as a surprise.
Code generating tools for Go also exist. The difference is that they produce source code, while things like Lombok, or any reasonable macro system, never surface intermediate code, unless explicitly asked.
I really hope that someone will use JVM with another built from the ground sane library.
The only thing Java misses is covariance/contravariance for generics, but with some unsafe casting it'll work.
I often read criticism of Go which is based on a missing "feature". In my experience, implementing these features is surprisingly easy in Go, as the building blocks are all there. In this respect, Go has some resemblance on Lego :).
My background contains a lot of Scheme/Lisp, so abstracting things with functions comes natural to me. It turns out that Go has basically the equivalent function concept (first class functions, closures, ..) so enables all the powerful abstractions coming from them.
This is the opposite of DRY.
But it can be done.
Speaking of sort.Interface, people say they want generics, but I think there is an implicit ask for operator overloading, too. Or the code they are asking to not write is probably still going to be there.
1. So you have a map of sort.Interface, and that's just as absolutely-not-convenient-or-type-safe as a map of interface{}
2. TFA does not want a sorted map, they want an ordered map, so sort.Interface has no relevance whatsoever: the order of iteration of an ordered map is the order of insertion, not the sort order of the elements.
> Speaking of sort.Interface, people say they want generics, but I think there is an implicit ask for operator overloading, too. Or the code they are asking to not write is probably still going to be there.
Not really. Java does OK without operator overloading. Having to use methods instead of operators can be annoying in some cases (mostly when working with non-built-in numerics e.g. decimals or infinite-precision integrals) but it doesn't limit you much if it does at all.
Guess it is due to a different architecture and design which makes the client faster (e.g. chaindata is smaller) but does anyone know why they chose Rust instead of Go for the Parity client?
I pretty much agree actually. I won't be necessarily writing a database in Go, but for robust and fast application services it's very very good.
Yes that's a more likely culprit, interfaces mean dynamic dispatch, outside of hand-rolled codegen I don't think Go can statically dispatch abstractions.
"Safe" as in "memory safe". Panicking is better than allowing one to read into that memory. I would prefer panic-safe, but we might have to wait for a new dependently typed systems lang for that.
Er yes, it's safe as in memory-safe, as in an OOB will not own the entire application let alone machine. Error on OOB is a very common (if not quite universal) strategy — and incidentally also the one Go uses, the other primary one being returning null (which would be difficult in a language where most types are not nullable).
If you want panic-safe, use .get.
I'm using them for the same purpose, but panic is rust-specific whereas error is not.
> Can a panic as is caused by the OOB situation I described be recovered from, or is it necessarily fatal?
Technically it can be recovered from[0] but practically it usually should not be. Panics should not be used as an exceptions system. An OOB panic is basically a failed assertion. If OOB is a normal part of your operations, use a panic-safe access method (e.g. slice::get[1] which returns an Option<&T>)
[0] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
[1] https://doc.rust-lang.org/std/primitive.slice.html#method.ge...
Sanitizers also exist for rust.
Furthermore, often time the bounds check can be elided when using standard constructs like iterators.
Maybe ask them? According to their FAQ (https://github.com/paritytech/parity/wiki#our-priorities):
> Minimise Moving Parts: While Rust is multi-paradigm, we aim to write intra-function logic in as functional a manner as possible. Mutability is avoided except where necessary for the algorithm or efficiency.
> Minimum Footprint, Maximum Performance: Maximise references, minimise copying and holding copies. Rust makes it safe. When there are dynamic data structures, provide means for keeping them under control.
> Reliability: Through Rust's language-level memory and thread guarantees and a disciplined approach to exception-handling we can state with a high degree of certainty that our code cannot crash, hang or bomb-out unexpectedly.
But I can't tell you that's all of the story. In the original announcement thread on /r/ethereum, the main point of comparison was C++ rather than Go so ymmv.
Rust rejects programs with data races unless you opt out by explicitly marking code in question as unsafe.
Quite a bit of a difference there.
The Go based client isn't that much "older" either, both are actively developed and received some code overhauls.
I've also found the go client's web3 console to be much more reliable and complete than Parity's.
Low memory requirements means portability to memory-constrained platforms. Interoperability with C presumably also implies easier access to low-level resources such as GPUs, and being able to take advantage of existing libraries for C, such as SDL.
People are also experimenting with Go in the same space, but it seems much less promising. Go is notoriously slow at calling C (or being called from C) due to goroutine context save/restore. It also has GC and a runtime.
If Rust was less complicated I might consider it.
Where is the list of problems that are easier to solve with generics?
Here is a random example from my recent adventures, a channel implementation in C++ which uses generics to provide value-semantics for user-specified message types:
https://github.com/andreas-gone-wild/snackis/blob/master/src...
And here is a column class that uses generics to inject both record type and value type into the implementation:
https://github.com/andreas-gone-wild/snackis/blob/master/src...
Doing any of these without generics would mean either erasing types or writing duplicate code. Go provides generic channels, slices and maps; but it doesn't extend that power to user-code since users are supposedly not smart enough to be trusted with power.
The problem is that you can't create your own generic structure. Try building a statically type-safe red-black tree, or something like that, without copy-pastig the implementation for each new node data type.
Higher-order functions are also basically impossible.
Pointers and slices as well, and of course the various builtin operators or functions used to work on them (make, range, len, close, …).
D compiles faster than Go usually and with templated generics all over its std lib
Languages are like tools. If you need a saw, use a saw, instead of complaining about the knife you are using.
Basically, something that takes coder discipline in Ruby/JS/Go is handled a compiler/runtime enforced restriction.
24 lines, really ?
"Oh, you think you want an ordered map? No you don't. Your reasons are stupid. You're stupid. Now gtfo and start using Go to write things we deem to be respectable."
Most sorted map implementations are based on trees.
If you just want a very temporary ordered list you could probably use a channel.