26

Re: Application field Golang

Hello, Qbit86, you wrote: Q> faced such problem that I can not unsubscribe from messages from a forum. I press on a fat dog, very strongly I press. And it all the same not . On the right button "to open in new ". Further to "unsubscribe".

27

Re: Application field Golang

Hello, Pzz, you wrote: Pzz> Hello, A13x, you wrote: A>> I would make so (with hypothetical templates): A>> A>> type MyHeap Heap <int,/*Less*/func (lhs, rhs) {return lhs <rhs;} > A>> Pzz> And I would prefer, that MyHeap generated exactly one copy of the code which would work with all compatible types, instead of on a copy  each variant of disclosure  as it does a C ++. Pzz> Here it would be cool, if it was possible to write something of type: Pzz> type MyHeap <type T: I>..., Pzz> where I is the certain interface defined earlier, and described thus MyHeap the code of methods  so as if it would work with the interface (i.e., once) works with any type T which satisfies to the interface I, and, but in invocation point is checked that specific types are used how is declared in type declaration MyHeap and its methods. In a case with Go it, apparently, not a problem - as far as I understand there it is not necessary to care about ABI and by result it is always generated self-sufficient  a file. Accordingly on a phase  (or even earlier) it is possible to generate only one copy of a template with covariance of types. Alternative variant: it would be possible to make easier and to implement on type  from , with type erasure. In this case would be more restrictions and the construction of the pseudocode a post above would look on another, but nevertheless it is better, than anything, at least because of partial checking of types in compile time.

28

Re: Application field Golang

Hello, night beast, you wrote: NB> the right button "to open in new " At Obama of such disgrace was not!

29

Re: Application field Golang

Hello, Pzz, you wrote: Pzz> To me the thought about implicit interface is not clear. That does not suffice? A method to tell, what such type implements such interface? There is no possibility looking at the type declaration to tell what interfaces it implements without considering other files with signatures of functions. Plus implicit interface as far as I understand (here I can be mistaken, correct if it not so) does not give possibility to describe in interfaces implementation of methods without allowing to enter thus trait. It is possible to resort to a trick in the form of the separate declaration of functions, but it not the same as does not allow to redefine methods with default implementation. An example as it is possible to make in the same java: interface Visitor {private default void visitUnknown (Base o) {throw new VisitorException ("Unhandled object" + o);} default void visitFoo (Foo o) {visitUnknown (o);} default void visitBar (Bar o) {visitUnknown (o);} //... visit the rest of hierarchy...} class ConcreteVisitor implements Visitor {//this visitor deals with Foo objects only @Override public void visitFoo (Foo o) {...}}

30

Re: Application field Golang

Pzz> And I would prefer, that MyHeap generated exactly one copy of the code which would work with all compatible types, instead of on a copy  each variant of disclosure  as it does a C ++. If these compatible types are inherited from one ancestor (as in Java) and use the virtual functions in a C ++ though and  in one copy for each type (and for everyone cpp a file), but  for each type leaves only one copy, and then the optimizer  checks up, whether the code of these functions for different types and if they as a matter of fact identical, leaves only one coincides. Then your dreams in a C ++ are implemented for a long time, and you and do not know.

31

Re: Application field Golang

Hello, A13x, you wrote: A> In a case with Go it, apparently, not a problem - as far as I understand there it is not necessary to care about ABI and by result it is always generated self-sufficient  a file. Accordingly on a phase  (or even earlier) it is possible to generate only one copy of a template with covariance of types. Not so I understand, how it could be made in practice? To generate the general code and a heap of adapters for  types? Is, theoretically, gccgo which, probably, when  wants to stabilize ABI. In  go there is  an implementation  plug-ins (while works only in ), and there too there is a question about stable ABI. So I do not think that go absolutely to spit on ABI, it is simple for the present is not made. I briefly offer something like it: type Comparable interface {func Less (Comparable) bool} func Min (a, b T: Comparable) T {if a. Less (b) {return a} else {return b}} Thus in function Min of both parameters behave how if they were type Comparable, but in invocation point is checked that they of the identical specific type, satisfying to interface Comparable, and returned value has the same type. Implementation is trivial enough, and there is no blowing up of the code. A> an alternative variant: it would be possible to make easier and to implement on type  from , with type erasure. In this case would be more restrictions and the construction of the pseudocode a post above would look on another, but nevertheless it is better, than anything, at least because of partial checking of types in compile time. I not the big expert  so if you refer to it, will be better, if you briefly describe, how there life is arranged.

32

Re: Application field Golang

Hello, Glory, you wrote: To the Russian Federation on it wrote only ours  Precisely wrote? Something me doubts take.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

33

Re: Application field Golang

Hello, pagid, you wrote:> To the Russian Federation on it wrote only ours  P> Precisely wrote? Something me doubts take. The projects developed on the Hell working in Russia are known some. Among them: Station of document communication  the Russian Federation. The primary goal is support of an exchange by the documentary information in networks of date transmission of the Ministry of Defence of the Russian Federation...

34

Re: Application field Golang

Hello, A13x, you wrote: Pzz>> To me the thought about implicit interface is not clear. That does not suffice? A method to tell, what such type implements such interface? A> there is no possibility looking at the type declaration to tell what interfaces it implements without considering other files with signatures of functions. I think, it is specially made. It allows to define the interface to existing types, changing nothing in the description of these types. If it would be desirable to ask the compiler in a type declaration point to check up that the type implements a certain interface, it can be made such method: type MyType struct {...} var _ = Interface (MyType {}) it is real thus any , connected to a variable institution, does not happen (the identifier _ has special value), but the compiler checks up that such expression basically can be written. A> plus implicit interface as far as I understand (here I can be mistaken, correct if it not so) does not give possibility to describe in interfaces implementation of methods without allowing to enter thus trait. It is possible to resort to a trick in the form of the separate declaration of functions, but it not the same as does not allow to redefine methods with default implementation. Yes, to the interface a method you will not attach. Actually, I do not see technical reasons why it could not be made. Possibly, simply solved not  language.

35

Re: Application field Golang

Hello, Masterspline, you wrote: Pzz>> And I would prefer, that MyHeap generated exactly one copy of the code which would work with all compatible types, instead of on a copy  each variant of disclosure  as it does a C ++. M> If these compatible types are inherited from one ancestor (as in Java) and use the virtual functions in a C ++ though and  in one copy for each type (and for everyone cpp a file), but  for each type leaves only one copy, and then the optimizer  checks up, whether the code of these functions for different types and if they as a matter of fact identical, leaves only one coincides. Then your dreams in a C ++ are implemented for a long time, and you and do not know. I do not have any dreams connected to a C ++, except desire to meet this language less often.

36

Re: Application field Golang

Hello, Qbit86, you wrote: NB>> the right button "to open in new " Q> At Obama of such disgrace was not! Always only so podpisyvalsja/otpisyvalsja

37

Re: Application field Golang

Hello, Pzz, you wrote: Pzz>... Pzz> If it would be desirable to ask the compiler in a type declaration point to check up that the type implements a certain interface, it can be made such method: Pzz> Pzz> type MyType struct {...} Pzz> var _ = Interface (MyType {}) Pzz> Pzz> it is real thus any , connected to a variable institution, does not happen (the identifier _ has special value), but the compiler checks up that such expression basically can be written. Yes, it is a pity, just explicitly it is impossible to specify it, and the most important thing is not clear in what a scoring of such approach in comparison with explicit declaration of implementable interfaces. A>>... Pzz> yes, to the interface a method you will not attach. Actually, I do not see technical reasons why it could not be made. Possibly, simply solved not  language.

38

Re: Application field Golang

Hello, Pzz, you wrote: Pzz>... Pzz> I not the big expert  so if you refer to it, will be better, if you briefly describe, how there life is arranged. Briefly - at level code byte all looks as as if  is not present. The compiler fulfills check of types, castes the automatic machine become in JVM. Pluses of such approach: backward compatibility with to-generic-ovoj , simplicity (it is not necessary to tear  for  type, is always sufficient one and only one implementation). Minuses are obvious, for example this approach does not work with primitive types (for example int), check of types in compile time not settling, and sometimes it should be suppressed, as in implementation any ArrayList - key places with SuppressWarning ("unchecked") see for example. More in detail here.

39

Re: Application field Golang

Hello, Pzz, you wrote: Pzz> I briefly offer something like it: It already is in Rust in the form of trait. And, most likely, appears in a C ++ 20 in a type . Go initially developed as language in which there were only the most simple and trivial tools, hardly in Go sometime deliver Rust-ovskie trait (without speaking already about  ). It at once  language "forage reserve" since half of developers cannot master them.

40

Re: Application field Golang

Hello, so5team, you wrote: S> It already is in Rust in the form of trait. And, most likely, appears in a C ++ 20 in a type . S> Go initially developed as language in which there were only the most simple and trivial tools, hardly in Go sometime deliver Rust-ovskie trait (without speaking already about  ). It at once  language "forage reserve" since half of developers cannot master them. Forage reserve Go is not the people, incapable to master language more difficult a BASIC, and people who consider that excessive complexity of language does not help, and hinders to work.

41

Re: Application field Golang

Hello, Pzz, you wrote: Pzz> Forage reserve Go is not the people, incapable to master language more difficult a BASIC, and people who consider that excessive complexity of language does not help, and hinders to work. There is a suspicion that as soon as complexity Go exceeds some threshold, its attractiveness as development language sharply decreases. It perfectly understands Pajk (and understood in an operating time over the very first version Go), therefore in Go the set of the things which have perfectly proved in others (including safe, since Java) programming languages did not enter. Well and yes, if the C ++ is an ancient shit of a mammoth which hinders to work, what for to compare Go to a C ++, instead of with the same Rust th? What for to wait for the advanced possibilities in Go which there can never and not happen if it is possible to use not less safe and faster Rust?

42

Re: Application field Golang

Hello, so5team, you wrote: S> Well and yes if the C ++ is an ancient shit of a mammoth which hinders to work what for to compare Go to a C ++, instead of with the same Rust th? What for to wait for the advanced possibilities in Go which there can never and not happen if it is possible to use not less safe and faster Rust? To me the thought that the programming language should be simple, is very close, and I came to it long before acquaintance with Go. In this plan we with the Ration think equally. And I in course that this thought programmers, and some divide not all, on the contrary, abundance in language of "the advanced possibilities" very is pleasant. On Rust I looked, eye edge, and found its language rather elaborate and difficult, though and not without the useful ideas. To people who search for a rich dial-up of the advanced possibilities in language, Rust it can seem pleasant language, but on my taste too difficult. Therefore desire of the Ration not  language quite suits me. But absence generic', really, sometimes hinders - because of   static check of types there a little where pertinently to make generalized "class" or function. I hope that Pajk invents years through 100 ingenious and on what not a similar method to make generic', not  language.

43

Re: Application field Golang

Hello, Pzz, you wrote: Pzz> To me the thought that the programming language should be simple, is very close, and I came to it long before acquaintance with Go. In the history there were enough simple languages. As those who in essence tried to remain simple: Pascal (which not the Object Pascal), Modula-2, Oberon. Even Ada83 which here already remembered though just Ada83 on the times was completely not simple and one of the most difficult in large quantities applied  though to PL/1 to it it is far, finite. And those who became complicated in due course: ObjectPascal, Java, C#, Ada95. Anybody from those who tried to remain in essence simple and did not become complicated in due course, and did not fall outside the limits the niches though in the niches they were rather competitive (for example, to use Modula-2 for development of responsible projects in the early nineties it was more reasonable, than a C or a C ++). And one of the reasons of it, possibly, was that not all developers agreed to be reconciled with limitation of the tool which has got to them. For example, in Pascal there was a built in type "set". But this type could be used only with the several built in types and listings. I.e. while you within the limits of that is in language, all are good. But as soon as these frames start to "press", that then? Here it was required in Pascal set of own structures and? And  the hand-operated code resources. Whereas even in an ancient C ++ it was possible to make "set" and it would differ nothing from other built in types of language. So simplicity is such ambiguous criterion. While tasks are laid down in a niche defined for language by authors, all is good. As soon as cease to be laid down, so simplicity becomes worse than larceny. That to simplicity Go remains not clear why people prefer Go with poor indicative abilities to the same D (same  and with GC) or Rust (, safe, but without GC and without C problems ++). Possibly, tasks at people such that as that programming language also is not necessary. Enough simple "glue" for integration of indirect components. And if for these people simplicity (i.e. if instead of exceptions or Either+pattern-matchinga, interface {} instead of trait is key and inheritance, manual defer instead of RAII), to calculate on appearance in Go something more advanced hardly costs.

44

Re: Application field Golang

Hello, so5team, you wrote: S> Anybody from those who tried to remain in essence simple and did not become complicated in due course, and did not fall outside the limits the niches though in the niches they were rather competitive (for example, to use Modula-2 for development of responsible projects in the early nineties it was more reasonable, than a C or a C ++). And one of the reasons of it, possibly, was that not all developers agreed to be reconciled with limitation of the tool which has got to them. S> so simplicity is such ambiguous criterion. While tasks are laid down in a niche defined for language by authors, all is good. As soon as cease to be laid down, so simplicity becomes worse than larceny. The C ++ too does not quit in any way a niche: the server software is written on Java or C#. On a place  I would think, as this niche to occupy. Instead of as it is theoretically beautiful to implement boost on templates that the code worked on 2 % faster, but it was written and understood in 5 times longer. And something prompts to me that new standards do not solve this problem.

45

Re: Application field Golang

Hello, lpd, you wrote: lpd> the C ++ too does not quit in any way a niche: the server software is written on Java or C#. On a place  I would think, as this niche to occupy. Instead of as it is theoretically beautiful to implement boost on templates that the code worked on 2 % faster, but it was written and understood in 5 times longer. And something prompts to me that new standards do not solve this problem. Well, it to put it mildly a lie. On With ++ it is possible to write the mathematical code in style of Matlaba or the Python (numpy means). And the code will be same laconic, clear, but will faster work. I had already a rewriting experience on With ++ both from the first, and from the second. Process has been at one time organized R&D: the mathematical model is written, she , then corresponds on With ++, the software is integrated in finite. There was a question: and whether it is necessary to write generally prototypes in these languages? The answer: it is not necessary. Prototypes and a floor-mat. The model appeared to write easier at once on With ++.  fell off absolutely, and the Python managed a role of the functional testing.

46

Re: Application field Golang

Hello, lpd, you wrote: lpd> the C ++ too does not quit in any way a niche: the server software is written on Java or C#. What server software? Loaded as in Google, Facebook and Yandex quite to itself it is written on a C ++. Web-muzzles for "clever devices" quite are written to themselves on a C ++. Everything that is between two these extreme measures, is written on everything. That is correctly since tools, like PHP, and the same Java, it is literally for this purpose and sozdavalis/were sharpened. However, the C ++ quite to itself  language, only here a niche at it explicitly is wider, than at Go. Well and the C ++ proved that is capable to get over from one niche in another. It is interesting to look, as with it will be at Go. For example, on GUI-appendices on Go. Or on the decision of computing tasks on Go.

47

Re: Application field Golang

Hello, so5team, you wrote: S> Hello, lpd, you wrote: lpd>> the C ++ too does not quit in any way a niche: the server software is written on Java or C#. S> What server software?... Everything that is between two these extreme measures, is written on everything. That is correctly since tools, like PHP, and the same Java, it is literally for this purpose and sozdavalis/were sharpened. ' ' it is a lot of All - the most part back-end. The code on Java in 2-3 times more slowly a C ++. I understand that it is possible to tell that the C committee ++ excites it a little. Also that all somehow manage Jav. However in my judgement, language with convenience Jav and productivity of a C ++ would be claimed. It is not ready to describe in details such language (probably, I have not enough experience on Java), however did not meet while arguments in favor of impossibility of existence of such programming language. To me normally answered about GC both complexity and inconvenience of a C ++. Of this of lacks new standards do not eliminate Any. There is a question, what for to complicate the code move-designers for the sake of pity percent of speed if all manage slow Jav.

48

Re: Application field Golang

S> What for to wait for the advanced possibilities in Go which there can never and not happen if it is possible to use not less safe and faster Rust? In Rust is not present . And it is more difficult (there it is necessary to struggle with borrow checker, and syntax such, what not everyone Perl' masters). Generally, Rust - language for fans of puzzles, so, not for commercial development. Even Mozillovtsy write-write many years, but cannot rewrite on it a small part in any way the operating project which and is successfully written for a long time on so hated C ++. For practical language there are two requirements: he should solve tasks for which it is intended also should be simple, how much it is possible (for acceptance by broad masses). The already a language niche, the is easier it can be made. Rust - impractical language, necessity to solve a puzzle contradicts simplicity of its usage, and limitation of its possibilities narrows down a niche. Golang - simple  language, a C ++ - difficult, but approaches for very wide range of tasks. Rust - difficult , therefore it - a toy for .

49

Re: Application field Golang

Hello, lpd, you wrote: lpd> ' ' it is a lot of All - the most part back-end. And there it is necessary to a C ++? lpd> the Code on Java in 2-3 times more slowly a C ++. It is said that in server-side, after heat-up VM, tearing much less. lpd> I understand that it is possible to tell that the C committee ++ excites it a little. Also that all somehow manage Jav. Not the committee does not excite it. It is writers back-end in most cases does not excite. And so that back-end write not only on Java, but also on Python, Ruby and Erlang. And only appearance Go stirred this slot a little and induced to creation of alternatives like Cystal. lpd> However in my judgement, language with convenience Jav and productivity of a C ++ would be claimed. It is not ready to describe in details such language (probably, I have not enough experience on Java), however did not meet while arguments in favor of impossibility of existence of such programming language. This language already is: D. Somehow to very few people it is necessary while. And before was, for example, Eiffel. As to very few people it was necessary. lpd> there is a question, what for to complicate the code move-designers for the sake of pity percent of speed if all manage slow Jav. Because there where without a C ++ it is possible to manage (and it much where it is possible), without a C ++ manage.

50

Re: Application field Golang

lpd> the C ++ too does not quit in any way a niche... The C ++ do not have niche - it language for the decision of a wide range of tasks. And, similar unique such, all remaining in comparison with it just  (well except a C, but in it the functional is very restricted - there is no PARADISE and the virtual inheritance). Nishevye languages can be designed and implemented more optimally under the narrower circle of tasks therefore they and will force out a C ++ from this niche (the same Golang it is simple, but works in a narrow niche). However, when the project on  language reaches boundary of possibilities of language - here and insuperable complexities begin.