problem with interfaces in Go, is that theyre not compile time. which means

1. No errors - debug later (HAHAHAHAHA EVIL) jk
2. Runtime-Casting.

So, tbh I dont think interfaces are a solution. Problem is that Go was built with “Simplicity in mind” and “Remove every single feature modern languages have” like enums … or generics … which were both made for very good reasons. And I hate that. It makes me think that some kind of hipster made that language (yes I know who the “hipster” is :P damn you Rob Pike and your hipster mind) and now they’re trying to retaliate with “putting Generics 10 years later” … generics that barely work or are useful at all, let alone the things they still don’t have but should have. I dont wanna pollute my package namespace with ““enums”” that have HUMONGOUS names just to make them different from other enums. Reminds me of C when Golang is supposed to be … “the modern C” or “how modern C should have looked like”?? (which is stupid assessment imo, it’s not comparable in any way) As they advertised it? Or at least I’ve heard that many couple of times.

Well let’s not be unfair, aside from things like enums or other features, sometimes generics do work, but in comparison with Rust’s, C++, C#, Java’s generics they’re not comparable at all. It’s like a drawing on top of Go. It doesn’t feel like it’s Go-ish and that Go has adopted generics properly at all. But still, good enough for making performant but not critical as you said projects, in an efficient way without having to deal with memory too much and still keeping some middle ground until you need the “critical” part.

tbh happy we came to a middle ground. thanks for discussing through it.

https://github.com/exapsy/capcli

I’m making a capital.com CLI using https://open-api.capital.com/ API to make position movements via CLI.

And who knows maybe it will evolve into something more powerful.

Unfortunately, Capital.com does not offer a CLI tool so had to make one with its own API.

edit:

I also made a sendgrid tool with Golang-Cobra, because Sendgrid also does not provide a CLI tool, but it’s proprietary (for the company Im working for). Whenever I can, I actually try to be sneaky and open source them as “my projects because nobody asked for them”. Like the Sendgrid CLI tool came after they saw my ability to build CLI tools and they got interested after making a proprietary tool on my own for the company, so I couldn’t have made it open source because they asked for it. But whenever they don’t, I try to make them open source on my private github or gitlab.

Bro, it’s not a battle. Like Golang Vs Rust. You treat it like a battle. “Go has very limited safety guarantees in comparison to Rust”, “Go was designd around go routines, Rust adds it as an option” as if this is an advantage? How exactly?

In any case, just look at Primeagen, any Rust programmer. Or do your own websocket server in Rust vs Go.

Go = 10 minutes Rust = 10-20 hours.

Does that mean that Rust is worse? NO. Absolutely No.

You though make it seem like a hecking war like Go Vs Rust. Jesus chill bois. I know Rustacians are fanatics but chill.

Go provides you a type-safe way and a clean-very-self-documentable, efficient, multithreaded/async/parallel way (yes yes … I know … yes … they’re all different, don’t be nitpicky jesus christ, I know somebody in the commends will try to “correct me”), to write programs VERY fast in a as type safe way as a company usually needs.

I’m not paid by the hour, I’m paid by the month. I’m not gonna spend 3 months just dealing with Tokio, Features, “async” which is not a feature but an option in Rust which is horrible nowadays, our machines are VERY powerful to be able to do async things very fast, it should have been a feature which you might use it or not like in Go. NOBODY forces you in Go to write a Goroutine, it’s just a language feature, get it? Mutlthreading, a hell in comparison with go.

Like, sometimes we just have to accept … each tool is best for its own job.

You want a VERY performant CLI tool? A system kernel mod or something that has to do with memory so much that Go will just be really bad decision? Go to Rust or C++. EACH TOOL, FOR ITS OWN JOB. It is not a heckin battle.

And sometimes we just have to accept, that no language is flawless. Stop trying to excuse the fact that Rust is very slow to program on and document in comparison with languages like Go. Go is not flawless either, what language is?

Go

• has no pattern matching
• has garbage collection. horrible if you want an app which is very memory heavy and with many arrays, structs and lists.
• Structs - Structs fucking amazing in Rust. I love them to the point I almost said to myself “Im not going back to Golang”.
• Enums … same with structs. They’re very powerful
• Generics - Whoever “Go” elitist says “But but … Go has generics” … I swear to god, I will pick his nails and throw his body to the ocean. Generics in Go suck. Still. Even 1-2 years after their release (1.18 was it? and we’re at 1.21 at go?) Rust has proper generics

Like do you get me? You make it seem like a battle between languages. Stop being fucking elitists. No language is perfect. Rust is SLOW to PROGRAM on. FAST on performance, but just to deal with the borrow checker its like it’s programming for you instead of you programming for the compiler and some changes require massive changes. And this steap learning curve, and mistakes, and really big complexity, make Rust just a NONO for small project. Do you really wanna make a websocket server in Rust? Be my guest. In Golang I can make it in ~50-100 lines and it’s perfect. But in Golang, when memory performance starts to matter and it’s not insignificant, which happens after decades most likely when you already have the budget to refactor, like Discord did (which just burns money of its investors btw it has no profit).

My point being 1 -> STOP being fucking elitists and “RUST IS THE BEST FUCKING LANGUAGE”. No its fucking not. No language is. Or trying to excuse the choice of not having Async by default and being so overly complex at times you just require hours to debug some sht.

2. -> EVERY language has its advantages and its disadvantages. CAN you please … for god’s sake … accept that? Just for once? Rust has big flaws when it comes to async, parallel and multithreading programming. It’s a mess. You’ll be debugging for hours or days.

3. -> Every language = a tool. Every tool has is used for a specific reason. It seems that Rustaceans fell in love with Rust so much they wanna make Rust everything. Dude or girl, girl or dude, that’s just … bogus and out of mind. It means you’re the cult. You’re not in a cult, you’re the cult when you do that. No language is perfect for anything.

4. Accept judgement. Okay? Languages just suck at somethings. Every - single - one - of them. NodeJS at multithreading, typesafety, documentation, memory (copying everything) and making programmers careless. Go at not having enums, proper generics, pattern matching, garbage collector etc. Rust at multithreading + async + parallel + making simple servers + borrow checker making it a PITA to program and design things the way you want to, instead you design things the way the borrow checker wants and it drains MUCH of your time redesigning things when you make mistakes, youre a human, u will make mistakes. … C++ and being so overly complicated you can barely read it and it makes stupid people think they’re smart because they used the “new C++22 feature” while there was a much simpler and efficient way to do it. But hey, they’re smart because “they follow the news and C++ has a new feature they wanna use in production which makes code slower”. C for being so simple and barebones and without language tools, like C++ too, it requires things like Ninja etc. to compile the headers etc. or do anything complicated. Thus why it’s not used by companies to make simple microservices. hello? It’s a PITA to write in languages like C++/C/Rust for a simple micro-service, and insignificant until you are actually a multi-million-hundrends or billion company with much traffic. Like, accept fucking judgement. It’s not bad for once. Some languages just such at some things. Even my brother, who works at Cadence, a software company for firmware for Chips and testing chips like ARM for Apple etc. a fortune 500 company, used python because it’s just … more convenient instead of having to recompile C++ every f’in time on each client’s CPU and there are countless when you’re such company. But Python is really bad at many things as well, but see? It has its own very nice uses despite that my brother works for almost a decade with C++, he chose python for that job because he knew it was the correct choice. Stop trying to excuse everything.

Rust sucks at async & multithreading. Period. In comparison with other languages, it’s a PITA to debug and deal with. That’s why the main rule in multithreading is “do not use multithreading unless you have to”. Well, in Go, you kinda dont have to think about that despite that you have to learn some patterns for data-races safety. I can make you a multithreaded program barely thinking about the multithreaded-side of things because that’s the scheduler’s job. It was built for it. But it sucks at many other things. Like Rust, just accept that and we can keep going on with our lives

Guys and girls, This problem has been solved in 1980 already. Why are we still struggling?

It’s called Communicational Sequential Routines. Like, why do we have to come to full circles and Rust after a decade still hasn’t solved the “Async”/Multithreading problem. It’s mind boggling to me, Im sorry, people are gonna hate me for me being frustrated, but I just can’t say that it’s irritating that Rust, a language that really has offered many great ideas, STILL hasn’t figured out how to properly do things like channels and sequential communication? A concept that has been invented since the 80’s? Or if that doesn’t fit at least see how it could fit Rust’s standards?

It’s HORRIBLE that Rust as a language and community STILL uses Tokio and Async-Std and we can’t even decide always which one of the two to use and while they also have some incompatibilities afaik, and this is just for ASYNC. Multithreading and Async? God bless your soul if you’re going to do that in Rust, because prepare for debugging for days and for many weird issues and caveats.

Go, a much MORE inferior in features language has done it. What makes it so difficult to inherent such or a similar approach? It’s a simple concept. Channels. In and out. And syntax and scheduler like Goroutines to make it easy to have async AND multithreading without the caveats Rust has nowadays if you were going to do such thing.

http://www.usingcsp.com/cspbook.pdf

I saw esoterics and heavily opiniated jargon such as .each!writeln; and immediately said … “fuck this”. I don’t wanna learn another shitty scripting language that thinks it’s cool because it created its own esoteric opiniated jargon. A language that isn’t even POSIX standard. Thank you.