Perhaps try another language like Rust?
atomly
On Fri, May 4, 2018 at 10:44 AM, Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:
> Well after bashing my head against a brick wall I finally understand what
> a mess it is for my specific purpose to work with Go. Nobody really
> specifically said it in any discussions up to now but what my design needs
> is generics. If code generation could be done more transparently I could
> use that but it really kicks interactivity and flow in the nuts. I'm going
> to probably abandon Golang on this basis. I am inclined to go with C but I
> am nervous about issues relating to pointers and runtime breaks but oh
> well. </discussion for me>.
>
> If there was a way to transparently add code generation that would be
> sufficient and remain type safe. *sigh*
>
> The biggest headache I am running up against is that between packages. I
> think that before I throw in the towel I am going to study exactly how the
> sort package is implemented, since in essence my library does the same
> thing, so maybe I just don't understand well enough how to use interfaces,
> embedding and composition.
>
>
> On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote:
>>
>> Yep, you are correct, more or less. My code is using interfaces and
>> panicking when it's fed the wrong thing.
>>
>> For example, in my test I had a literal number going into a write
>> function to put a value into a node in the tree. The insert implementation
>> panicked saying it couldn't put an int into a uint32 slot. Eventually I
>> worked out it was the assumed int typing of the literal causing the problem
>> (happens all the time, I should be used to it by now).
>>
>> The thing is, it is intended that the user of the type specific library
>> that imports the tree library will not make a type assumption like the
>> compiler did about a literal. The type specific part has to be written for
>> any given type. There is a little verbosity in the part that wraps the
>> injected functions with syntactic sugar so the base library has the
>> functions to work on the concrete data agnostic of its content and only the
>> return values provided by the functions it gets to do various comparisons
>> and whatnot. It's not excessively wordy for my tastes and I know it's doing
>> it the best way possible.
>>
>> It's just learning how to play with interfaces that I was struggling with
>> and I seem to have pretty much got it all figured out now. I'm happy with
>> how the code is developing and pretty much joyous that I can do this inside
>> a type safe language. Type safety is a big part of how Go is such a fast
>> compiling language. Implicit casts and inheritance have a massive cost in
>> complexity not just a naive translation to binary code, but also in
>> optimising it. When can it cut out the dereferencing to methods and when
>> not? Since one could be using a method to do a relatively simple thing, in
>> very long, tight loops, if the OOP compiler guesses wrong and puts
>> dereferences in where they are not needed, it's a big cost over 1 million
>> iterations compared to being aware of it, like in my code, and avoiding the
>> need for dereferencing.
>>
>> I firmly believe that Go could replace C as a language to write systems
>> kernels in. I saw an amusing post recently relating to Dan Larimer's work
>> on EOS mentioning an automated code correctness checking application for
>> C++... Having intimately dealt with Dan's C++ source code, I can see why he
>> might be waking up to this, especially with the ether leaks going on, that
>> EOS has inherited (literally, I presume).
>>
>> This would not happen if it were written in Go. Note also that Geth lacks
>> this problem and there was almost going to be a split over code changes
>> from the Go side.
>>
>> Linus Torvalds famously said he wrote the Git CVS in C specifically to
>> exclude C++ programmers. But as any avid gopher would know, C has all kinds
>> of gotchas to do with busting out of stacks, heaps, allocated memory, and
>> forgetting to free memory. This does not happen in Go.
>>
>> So to cut a long story short, this is why I choose to program in Go. I
>> have a background in low level programming, I used to do a bit of M68k
>> assembler on my amiga when I was a teenager. I don't mind verbosity that is
>> necessary due to hardware architectural constraints. And as to the
>> potential users of my code, I am not responsible for them having a lack of
>> awareness of the exposed inner workings and them scratching their head at
>> panics when they try to push the wrong type of value into one of the
>> functions I wrote. They probably need to do some more study.
>>
>> I think of programming a bit like carpentry. Sure, you can just whack
>> together an Ikea table in half an hour, but if you want to make a nice one
>> that will last hundreds of years, you probably will need to at least spend
>> a week or two practicing before you even have something simply crude and
>> functional. C++ and other OOP and interpreted language users are like Ikea
>> customers. Gophers are like people who go to the sawmill and the specialist
>> tool store. Disregarding the zero cost of reproduction of course (that's
>> what Ikea does).
>>
>> On Friday, 4 May 2018 11:36:33 UTC+3, M P r a d e s wrote:
>>>
>>> > Eliminating code duplication shrinks the base of code that must be
>>> changed
>>>
>>> Except go was designed a certain way that will make whatever you are
>>> attempting to do here burdensome. We've all been there at first trying to
>>> fit a square into a round hole, it doesn't work. Unless you start ignoring
>>> Go type system with interface {} everywhere, you're not going to go far
>>> trying to emulate method overloading in Go. The price of using Go is
>>> absolutely code duplication and a certain amount of verbosity in order to
>>> remain type safe. The only real way to achieve method polymorphism in go is
>>> to use interfaces, since Go supports neither inheritance nor generic
>>> programming. Go does not allow developers to write "clever" code without
>>> sacrificing readability or compile time type safety.
>>>
>>> Le vendredi 4 mai 2018 06:26:59 UTC+2, Louki Sumirniy a écrit :
>>>>
>>>> The specifics of how it is done is not as important as why to do it:
>>>>
>>>> I am writing this for a later project. It will need at least 5
>>>> different, sometimes nearly not very different, short data types. They all
>>>> have the property of being comparable. The code that keeps them stored and
>>>> sorted does not need to know anything other than this comparability, and to
>>>> be able to pass the data back to the caller.
>>>>
>>>> I am not making claims about something, trying to sell some snake oil,
>>>> I am attempting to solve a problem and make use of low level architecture
>>>> of the hardware to improve performance. It worked for B-heaps so maybe
>>>> MAYBE it will also benefit binary trees. The way some people respond you'd
>>>> think I was running an ICO!
>>>>
>>>> Programming is usually 5% writing and 95% debugging. Eliminating code
>>>> duplication shrinks the base of code that must be changed, otherwise I have
>>>> to delve into code generators or macros. If I have an intended use for a
>>>> library I am writing, that would require 5 different source files for each
>>>> data type, yet 90% of the code was the same, what happens when I realise I
>>>> made a mistake in this common code?
>>>>
>>>> I pretty much concluded that it is better to just pass an 8 element
>>>> function pointer struct as value anyway. Whether the compiler does it
>>>> differently doesn't really matter since I can't control that. What matters
>>>> to me is that it's readable so I don't have to spend more time reading than
>>>> understanding.
>>>>
>>>> On Thursday, 3 May 2018 23:40:07 UTC+3, Jan Mercl wrote:
>>>>>
>>>>> On Thu, May 3, 2018 at 10:14 PM Louki Sumirniy <
>>>>> louki.sumir...@gmail.com> wrote:
>>>>>
>>>>> > As some here may know, I am implementing a novel binary tree based
>>>>> on complete trees and using ideas from B-heaps in order to achieve maximum
>>>>> data cache locality in a search and sort algorithm.
>>>>>
>>>>> ...
>>>>>
>>>>> > Note that this is not really at all an OOP paradigm that I am trying
>>>>> to ape with this.
>>>>>
>>>>> ...
>>>>>
>>>>> > I have the base type that concerns itself with the walk, search,
>>>>> insert and delete functions in an interface.
>>>>>
>>>>> ....
>>>>>
>>>>> > The b.Overloads - I am not sure, whether it should be pass by value
>>>>> or pass by reference. I think pass by reference adds an extra resolution
>>>>> step, but it is probably more expensive as every call of the functions
>>>>> will
>>>>> have to perform this dereference.
>>>>>
>>>>> ...
>>>>>
>>>>> > Thanks in advance for any feedback on this.
>>>>>
>>>>> - Novelty is only valid when established by peer review. Self-claimed
>>>>> novelty often means just lack of research. Even if eventually correct,
>>>>> it's
>>>>> a warning sign for me meanwhile.
>>>>>
>>>>> - Attempts to make non-interface types in Go behave in the OOP-style
>>>>> inheritance is usually a telling sign of using the wrong language - or
>>>>> abusing one - to solve the problem.
>>>>>
>>>>> - Pass by reference has not even a well defined meaning in Go.
>>>>>
>>>>> No insult intended, you've explicitly asked for _any_ feedback. My
>>>>> apologies if you feel offended anyway,
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> -j
>>>>>
>>>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
