Yeah, at the moment, unfortunately only works for Go.
But implementing a different backend (e.g. llvm-symbolizer, objdump etc.) shouldn't be too difficult. The main things it needs to do are 1. list the decompilable symbols in the file, 2. disassemble and pull in the relevant source code.
I like to think that in an alternate world, somebody wrote:
> There is of course a questionable degree of consonance that can be tolerated, but the most obvious fact is that the brain can well be conditioned to accept and even enjoy these consonances, as long as they are part of the only music it has ever experienced.
Replicating Erlang processes -> usually you use goroutines. When that level fails you fail the whole process and restart it using some supervisor. You may need computer level failover as well, depending on the requirements.
For the servers/protocols part of OTP, the stdlib is usually sufficient to get things running; although may need some additions for rarer encodings.
For machine level deployment there are cluster managers i.e. kubernetes, aws, google cloud etc.
Regarding debugging/monitoring I haven't seen anything that is close to Erlang.
Basically, I have no idea what you are doing and cannot recommend anything particular. For the full feature set there is no single replacement. If you need OTP then use OTP.
> Do you see any way other than the 3 ones discussed in the OP article under the label "Generics"?
The one I mainly meant was interfaces. Of course there are also DSLs and code generation.
> I could agree with that if time wasn't limited, but imho building custom data structure/algorithms for each problem will precisely leave less time to optimize for performance since reaching a working state first will be longer without reusable abstractions.
I mentioned that in the summary. It's about tradeoffs. Even if all the cons/pros are listed people could still come to different conclusions, because people value different things. And there's nothing wrong about it.
The amount you need to reimplement depends on the amount of available third-party packages - the more good packages there are the less you need to build those custom data structures.
Abstract things are harder to optimize than concrete things. A package for a concrete problem can be more optimized than a generic/abstract package.
I don't mean that the manually specialized version is faster than automatically specialized template. Rather that this encourages to not write abstract data-types, but rather concrete types that solve a real world problem - editor.Buffer vs. gap.Buffer. Once you have a real world problem it can optimized much better for that use case.
> It doesn't mention the major inconsistencies in golang at all.
It has little relevance to "Generics". They are simply how Go is implemented, the question is whether "Generics" as a user implementable thing should be added.
> CLR
From my quick reasearch, it uses runtime code generation and Go must run in environments where that is disallowed.
Basically, I have nothing to be defensive about - it's a summary of discussions, which means that any properly stated argument should be incorporated to the document, no matter what I personally feel about that argument. Although, the content has to be moderated somehow, I dislike deciding what is "properly stated" argument, but I don't really have a better idea how to do it either, at least not yet.
Personally, I stand in the middle of the generics discussion so I pretty much can see both sides as a valid approach. And it's a WIP and I know if one person writes it, it will be biased no matter how hard you try.
PS: I find the "straight to the point" comments much more useful - they are much easier to understand. So don't worry about it :)
> Without generics you can't separate algorithms from data structures so everything is much less useful.
Generics is not the only way to separate data and algorithms. I agree that it is possible to sub-type/embed and rename - although looking at generic code, I rarely see that happen.
> That "concrete solution" not only has to be written, but it will also perform identically to an instantiated template.
When you know where exactly the code will be run, it can be possible to create a better package taking into account the context where it will be run. By concrete, I mean a package in a real-world problem.
Basically, abstract things are harder to optimize for a particular case.
Didn't intend for it to end up on HackerNews - at least not yet. It's still the first draft, most of it I wrote up in ~2hours. I made a mistake for not putting the "Draft" note at the top of the page in the first page.
I try my best to be objective - obviously this isn't easy. This is intended to be a review of both sides of the arguments. The generics discussion comes up again and again - I made this document to stop arguments going around in circles.
I will go over all the suggestions and add any missing information. Of course, if you have some good overview of some particular generics implementation you can PM me, or simply add that as a comment.
Thanks, didn't intend for it to end up on HackerNews - at least not yet. It's still the first draft, most of it I wrote up in ~2hours. I mentioned on the forum that this document (currently) is highly biased towards my views, this is unfortunate, but this can only be fixed after numerous reviews.
Thanks for pointing out the problems with wording. I'm slowly fixing those. I've changed that "best" to "As with any feature it should solve a set of problems, if there are better ways of solving the problems, those should be used instead."... it's better but not perfect.
"in other cases the hit from interface{}" - added that addition to the alternatives section.
Generics don't have to be perfect, but it must be actually useful and it mustn't compromise simplicity of Go.
One programmer can make an impact to a degree. Yes, making an enterprise system for some industry requires a ton of coding for business rules. But it might be possible to make that coding simpler/easier so that people with domain knowledge could express it without having to code it, of course this is easier said than done.
Also taking a step back and seeing how things could work differently is a nice idea. One of the most recent examples is Bret Victor, just his demos gave a rise to a lot of new cool stuff. Or take LightTable, it has quite interesting ideas for interactive programming.
Regarding start-ups, take for example TransferWise, it solved a business problem, and it started as a two man band. ZeroTurnaround with it's JRebel, solved a technical problem, but was conceived by one person.
So, yes, one person can make an impact, but it takes solving unsolved problems or noticing problems needing to be solved. Of course one person usually can't be a business, which is somewhat different from making an impact.
As a start I would suggest watching Alan Kay and Bret Victor videos.
But implementing a different backend (e.g. llvm-symbolizer, objdump etc.) shouldn't be too difficult. The main things it needs to do are 1. list the decompilable symbols in the file, 2. disassemble and pull in the relevant source code.
The UI part doesn't care whether it's Go or not.