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.
If iOS and Android devices count as consoles (and I think some of them do) then Delphi has console support. :)
Free Pascal (http://www.freepascal.org/) says it supports the Nintendo GBA, Nintendo DS and the Nintendo Wii (to what extent and how well I don't know, never tried it). It also supports Win32, Win64 and FreeBSD so I suppose it could be made to work on the PS4 and XBox One without too much trouble.
A real strength of Object Pascal is that it can be as low level (inline assembly, manual memory management, etc) or as high level (OOP, generics, etc) as you like. It satisfies most of the article's wishlist items.
Today I happened to find a simple but still interesting programming language feature matrix on Ian Hixie's website: http://ian.hixie.ch/programming/
He'll have to update the Execution column for Free Pascal to be both "Native" and "VM" since Free Pascal 3.0 can now also compile to JVM byte code: http://wiki.freepascal.org/FPC_JVM
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.
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.
> 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.
> Generics is not the only way to separate data and algorithms.
Do you see any way other than the 3 ones discussed in the OP article under the label "Generics"?
> 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.
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.
> 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.
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.
>* 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.*
Thanks for not being defensive and taking my rather harsh critique lightly!
I wasn't trying to attack your specific document either, it's just that those things have often been repeated (often verbatim) by the Go-dev camp.
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 :)
It doesn't mention the major inconsistencies in golang at all.
Go has generics. For arrays, slices, channels, maps, and some "standard" library functions. Go has generic functions. "append" being the obvious example. Go has polymorphic functions : append, make, ... If you look at the compiler source, the type system has generics, to a large extent. It's simply not accessible to normal programmers, instead only allowed for golang's authors.
As if this is not bad enough. Go cheats the type system in thoroughly non-obvious ways to get more C-like behaviours that obviously do not improve safety or programmer productivity.
Go has shudder return value polymorphic functions. Range being the obvious, but not only example (range changes in meaning depending on it's parameters AND on what you assign the result to).
As for your boxing argument. As soon as you use reflect, you're boxing everything. Oh wait, if you use a package that uses reflect, of course you're also boxing everything. Surely that can't be much ... hmmm half the standard library uses reflect. Fmt, everything in encoding, text or html templates, rpc, jsonrpc ... No need for boxing, or compile-time function evaluation or generics (all present better solutions to this, for the CTFE solution see D-lang).
Golang even has functions with type parameters. Make and new being the obvious examples. Again, this is present in the type system (not just there, also in reflect, things like printf, ...). It's simply not made accessible to us lowly go programmers.
So can we please stop with the crap that generics aren't necessary ? That nobody uses advanced type system features ? Or that polymorphism isn't necessary ? It's crap, and obviously the golang authors don't actually believe that. They just think that only they can be trusted to write such functions and that their datastructures are all anyone ever needs. If you disagree with that assessment (and everybody will, soon) Go is not for you.
So Go is simply a throwback to pre-80s programming languages, and a perfect illustration of the frustrations that led to the development and extension of the C++/Java/C# programming languages. If you give people the minimal implementation of sorting an array of structs, it becomes blatantly obvious why other languages are necessary.
The more I write Go, the more I yearn for C++. There is nothing in the C++ language that I can't do for my own datastructures/functions/... That is a huge feature, and may I just say :
From my cold, dead hands !
Btw : there is a better solution to generics as well at compiler-level, that is used in things like the CLR. First, generate unboxed versions of functions where that makes sense. If specializations are possible for 1-bit, 1-byte, 2-byte, 4-byte and 8-byte primitive data types, expand those. Then for anything bigger, like structs, create a boxed implementation, because for structs there is no longer any advantage to working unboxed. Then make it possible to pass in the version to be used in a parameter, so you don't have a combinatorial explosion when many type parameters are given.
Btw : there is a better solution to generics as well at compiler-level, that is used in things like the CLR. First, generate unboxed versions of functions where that makes sense. If specializations are possible for 1-bit, 1-byte, 2-byte, 4-byte and 8-byte primitive data types, expand those. Then for anything bigger, like structs, create a boxed implementation, because for structs there is no longer any advantage to working unboxed. Then make it possible to pass in the version to be used in a parameter, so you don't have a combinatorial explosion when many type parameters are given.
That sounds sensible.
I'd like to figure out a way to extend the concept of interfaces to cover use cases like generic containers, but I'm not quite sure how that would work.
> 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.
It has relevance to generics. Right now the question implies Go does not have generics, which is not true at all. The question should be reworded :
Go has generic types and generic/polymorphic functions. Therefore all the focus on that such functions are not necessary/useful seems entirely beside the point, the result of misunderstanding. Can normal Go programmers please be allowed to make use of that feature ?
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.