Are people Re-Inventing everything in GO?

Community
1

Im about 4 months old in GO (Gopher Pup ?! :dog:), with experience in Enterprise Java

I’ll dive right in. There are things a binary needs to depend internally as an API like Log, Networking, Security etc. And it makes sense to have GO equivalents to support that internally.

As a JOKE, I certainly think anything written in PHP that has had success should be re-written (lol) :stuck_out_tongue:

But then you start looking @ object databases, CMS, Rules Engines, Message brokers etc. Components in an architecture that ideally you should not care about their origins of implementations as long as they are reliable, secure and time tested. At an enterprise scale context talking about Mechanical Sympathy, and ubiquity seems unnecessary. DISCLAIMER: I do not say these concepts are unnecessary, rather them in the context mentioned. (before I get trolled)

I get it that a lot of people in GO come from say Ruby, PHP, Python. And GO is like dream land but when you look @ enterprise systems written in .Net, Java ; do we really need to re-invest and re-invent them in GO? Programmed in Python, I prefer GO too.
I find no justification for a lot of projects re-inventing stuff in GO other than it doesn’t yet exist in GO. And the solutions are immature (not gonna name them). True, maturity is a progression … but this is re-invention.

Programming and Software engineering are not the same thing. GO is a great programming language as am discovering and am happy about it. But for commercial projects selecting the right components in the architecture, I find people biased to selecting components written in the same language.

I will avoid a language comparison as thats not my intent and I respect every language (except the one that shall not be named... take a guess; and it isnt GW-Basic or even Logo ..heh), …but after following tons of pod-casts, forums I just a impression people are celebrating anything re-written in GO.

I guess a natural process of selection will filter such projects out and thats how it rolls. I think one has to caution in using just ANY framework written in GO because you are using GO and should think about the component in absolute terms of the enterprise architecture.

A cool thing to have at some point
Im wondering if a standard exists or needs to be in place for every system language to be able to share Stack, Heap in memory, on the same Processor and memory mapped to the processor (Research TODO). It would allow the door for components in different languages even to connect without networking overhead, in a ubiquitous manner and eliminate the need for EVERY LANGUAGE to HOARD and RE-INVENT every framework from scratch. Its silly !

Bottom Line
Languages suit HUMANS in how they try to read and write their code. They are an abstraction layer for the most. Ok, ignore compile optimizations etc. But most people dont select languages based on that right?!

The machine doesnt care, its all binary at the end. SO Because WE HUMANS cant agree, we all create cheap copies and hierarchies of interdependence in every language.

Think about it!

2 Likes
2

What you’re worrying doesn’t just happen in Go; it happens across every languages. Don’t worry about it.

Since Go standardizes its code formatting and styles, I personally find it okay for aspiring developers to re-invent things with a team or self for:

  1. It’s very easy to read the codes and decide your integration decision, freely (as in freedom).
  2. It’s much better for them to gain necessary experience bona-fide style instead of someone abusing others in the forum to do his/her homework for becoming “senior developer”.
  3. It’s very easy to check their efforts/integrity/results since there is an existing reference for it.
  4. You have a reference point instead of starting from scratch.

There was an incident with go-bindata in the past. The lesson learnt from it is that you should always audit the libraries you integrated in. This is also one of the exhibited cases for creating Go module.

Let others have the freedom. Similarly, you have the freedom to choose based on your requirements. Enforcing enterprise architecture thinking to every Gophers can be unfair to others. FYI, I served a 9-years old (age) aspiring Gopher on setting up Go compiler in other forum, past time. Do you expect him/her to deliver “enterprise grade” architecture like us?

Complete absurd. The argument is like we shouldn’t use natural gas stove but roll back to woodcutting and stone pilings for our home-cooking because both can light fire, it’s usable, and it cooks.

If there is a compiler that does the optimizations without needing me to read a very thick processor manual, I would choose that. Ultimately, I want a language that works as close as possible to manual assembly / binary and as abstract as a human can easily manage and understand. Go is the best candidate by far.

The key sentence should be “programming languages are just tools. Choose the right one for the right problem and its constraints”.

2 Likes
4

I wasnt saying, we goto Binary, I was implying its equally or more absurd to re-invent full hierarchies where in an enterprise environment one can cross pollinate and be language agnostic. I think you misunderstood the intent there. Anyway.

5

Thats programming not software engineering. I think I did mention there is a difference. And my context is enterprise environment. And the same can be done in any language, I dont see your point here. Illogical. Your 9 year old friend can get started on any language oblivious to concerns. I really dont see the connect. I would not want to reply on this but its a joke right?!

6

Well… let’s lay out the possibilties:

  • if the package has no API, then, written in C, you have to at least write a Go “C” wrapper; if there is a command line interface, then you can os.Exec it.
  • if the package has a RESTful API, then you might want some convenience wrappers
  • if the package has a different API (like Postgres), then you need to implement a Go version of the client side API
  • if you don’t want the overhead of APIs over socket connections, then you might end up writing a Go version of the tool from scratch (this has been done for Redis, for example).

Finally, I would point out the situation with Oracle databases. Since their JDBC implementation isn’t open source, Go has a harder time connecting to Oracle. It has to use the C wrapper approach, which isn’t ideal.

HTH!

unless the API to the non-Go

7

Either reword your conclusion to tackle specifically reinvention as a bad practice or my implications still stand.

Specifically attacks the compiler as conclusion and reject the many built-in optimization the compiler has to offer makes no sense. That’s equivalent of asking people to stay away from Go at all and strictly stick to whichever legacy tools/practices that was available “as a conclusion”.

The way I see your point is that “the process on how we burn firewood must be carried forward when we migrate to using gas stove so we must be able to burn the gas tank the way we burn firewood. After-all, we’re burning stuff to get the heat.”.

The point here is that Go has a role connecting developer as young and green as 9-years old with people like you and me without a lot of reading frictions or editing. You can’t do that in Python (either focus on teaching or focus on production), C (too hard to learn for new learner), Ruby (too magical), and Java (too complicated to learn for beginner). If Go can facilitate such easiness, reinvention and duplication are bound to happen.

That’s why I emphasize it is upto the consumer sides to filter packages based on our requirements instead of enforcing the specific requirements onto all the creators. After-all, Go’s source codes are the easiest to read and audit anyway.

p/s: That 9-years old was an incident that also made me learnt to be extra cautious and careful in any Go forum because you really do not know any minors is around. Apparently, they don’t read T&C. :man_shrugging:

3 Likes
8

Dear Mr. h*anho,

Specifically attacks the compiler as conclusion and reject the many built-in optimization the compiler has to offer makes no sense. That’s equivalent of asking people to stay away from Go ??! lol

That’s equivalent - Transitive, assumption and policing. Dont know what to say man.

… I never attacked GO, BTW i love GO. Just that some of the libraries I feel dont need to re invent the wheel. It seems you’ve bypassed the entire intent of the post and I’ve checked the words. While am sure you are a veteran in GO perhaps we are both not speaking the same english. I apologize if any words of mine are mis interpreted as any attack on GO; if I didnt like Go i would not be here. Just trying to make the world a better place like you ! :slight_smile:

1 Like
10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.