Recently discovered cloud run and it's absolutely amazing. I will be using it for as much as possible going forward. Cheap, easy, scaling. For a crud app it does everything you could ever want.
Location: PST
Remote: Yes, only remote
Willing to relocate: No
Technologies: Node (5+ years), React (4+ years), AWS (4+ years), Go (0.5 years), Rust (no experience, very interested)
Resume/CV: on request
Email: corymaloy at gmail.com
Yeah, me too, the whole appeal of Go for me was that it was as barebones as C (with GC and concurrency). It was a breath of fresh air. Generics opens the door to the abstraction olympics in other "modern" languages. Might as well just go back to Java.
I wondered this too. It's not like there's a part of a language you MUST use. Perhaps they are fearful that it'll grow and grow and add features in that will make it difficult to learn and unwieldy. Stroustrup always said that new languages seem fast and easy to learn precisely because they are new languages and don't have the features of maturity. Perhaps this is the case here.
He is quite right, yes C++ is a monster dragon, but most languages of similar age only look simple on the surface, even a beginners friendly language like Python.
Beneath that simple surface for beginners lies a multi-paradigm language, with overloading, metaclasses, dynamic code generation, multiple inheritance, breaking changes across minor versions in 30 years of history, a standard library that can be used as doorstep when printed, several implementations not 100% semantic compatible with CPython,.....
Maybe because you take away one of the big advantages of Go which is easily maintainable code, and end up with just another clone of Java/C#, so why don't you just use those instead?
The type variable in any generic declaration is inherently unreadable. What's <T>? Every language with generics has tried to come up with ways of making this less opaque. Typeclasses, concepts, traits, interfaces, bounded type parameters. If you implement one of those then you'll have another unforeseen problem on your hands, playing wack-a-mole until you have C++.
How about just code gen your generic implementations then check them in. That way I can see what's going on without having to guess. The whole thing is about saving time typing and DRY right?
The type variable in any generic declaration is inherently unreadable.
The concrete type variable of a generic parameter does not matter at all, you need not to clutter your brain thinking over it.
With a simple T you do not know anything about the type and you cannot do anything else with it directly except using the root type methods of your type system (e.g get hashcode, toString, etc)
Most generics to be useful needs either:
1) To be type tested (e.g through reflection).
This allow you to manipulate it in a fine grained manner and you can know exactly what it's type is.
But generally we want
2) to abstract over many types in the same way because those type would have a same invariant, a same behavior.
Some language allows you to represent this through union types instead but there's nothing wrong to say that T extend an interface/concrete class that specify what will be accessed from T inside the function. There is no cognitive overhead, no ambiguity. What would have been many types become simpler, factorised under the same contract, the same interface.
If you implement one of those then you'll have another unforeseen problem on your hands, playing wack-a-mole until you have C++.
This is a claim, could you explain it?
I see no reason to think that way.
C++ "generics" are cancer, we can agree on that.
How about just code gen your generic implementations then check them in.
I'm not sure to understand.
Would that be like C++ template? What's the difference?
You would like the N redundant implementations of a generic function to be visible? Why desire this clutter?
And the alternative, manually maintaining redundant code is error prone and a maintenance burden. Also the fact that there is an invariant, a meaningful intersection of behavior between those types become hidden instead of being explicit through an interface/type test.
what's going on without having to guess. there is zero guess involved as explained above, it's all type safe and your IDE will autocomplete only the shared behavior.
Indeed you can. But if I want short-term work, I take contracts. If I'm looking for a permanent job, I'm specifically looking for some place that I'll be for years. So it is a bit like marriage in that sense.
Also, it's not a great look on your CV when you've only been at a non-contract job for a very short time.
Spending a bit of time to do research on a job, versus going through the hiring process, possible relocation, training and team familiarization, and all the physical and mental stress involved - only to find out you don't fit and then going through the exit process.
I have plenty of time, but the games these days are awful and are purely centered around siphoning as much money out of the consumer as possible. It's quite unpleasant. I'm stuck playing older games because of this.
