I have so many disagreements on goals for the language with Russ, but have been a fan since his early days of writing the regex package and the c-to-go conversion code. Glad to hear he will still contribute to the lang, and hoping for a bit different direction from the new leads.
If you already have your own functions or variables named max, min, or clear in-scope, they will shadow the new built-in functions and your code will continue to use your own version of the functions. No breakage to existing identifiers that match the new function names.
(This is the same behavior as the append built-in function today, for example. These things in Go are _not_ reserved keywords, they are simply global functions that can be overridden at other scopes.)
In what way? Overall as a language, identifier shadowing is a feature of the language in nested scopes. Are you saying built-in identifiers (that aren't language keywords) should be treated specially and work differently than user-declared identifiers?
It's terrible, IMO, because every package that has generic words is now a variable name I can't use. A simple example which i find unreasonable:
package main
import (
"fmt"
"path/filepath"
)
func main() {
filepath := filepath.Dir("./")
//filepath.Dir('./") -> This is now a string. Can't use filepath package anymore
fmt.Println(filepath)
}
Now I have to make up variable names because `filepath` will shadow the package. How it this sensible in any shape? Zip just does this better by having @ in front of builtins.
you're complaining that the nomenclature for packages is not differentiated in a way that allows user code to have variable names with the same name as package names
you can still allow this, of course, by aliasing the package import
At a company with “flat team” aspirations it’s like this but the loudest juniors call the shots. Come in with 10 years exp in a language and get constant pushback on my suggestions because I’m new and unproven. After 2 years most of the loud ones that made all the decisions are gone and we’re stuck with something that doesn’t scale and needs to be rewritten because before end of quarter. Amazing how much tech debt is possible in this model.
Sorry it's hard to hear this, but you are definitely lacking some skillset of persuasion or communication. There are always "fights" in the beginning I guess, but if you are confident, know your shit, it should be very easy to convince less experienced people.
One thing you might not be aware of is "social capital", "setting expectations", "assertive communication" and things like that.
Sure, in an ideal world, wisdom should always win over loudness, but until that happens (never), you have to learn these soft skills to be the reasonable voice in a team.
I always found my voice in every team very early on, due to my knowledge, my high quality of work and being confident (in my abilities and my work.)
> if you are confident, know your shit, it should be very easy to convince less experienced people.
No, it isn't. I am fully aware that I am lacking some kind of ability to champion projects, explain things that seem obvious to me, and convince others, but I am also the absolute subject matter expert, know every piece of this shit and am completely confident in what I'm telling them. That's why it's infuriating to watch blatantly stupid projects with no basis in reality kick off then crash and explode in exactly the way I predicted. It is 100% a communications failure on my part. The confident salesman idiot will win every time.
In my experience coming in as the new guy with X many more years of experience doesn't automatically mean you're going to be listened to no matter how "assertive" you are. Communicating assertively can easily cause others (especially newer devs) to be on the defensive. If a whole team has decided on a trajectory you're not likely to change things very quickly by just exuding confidence. You don't have much "social capital" on a brand new team until you've demonstrated your skillset.
Also I find the habit of passing judgment of a person on an internet forum extremely distasteful and pretty disingenuous - you don't know enough about this person from a two sentence forum comment to judge their communication/persuasion skillset. It does nothing to support your argument or do anything other than make you feel superior to that person.
Why think this by default? I am in a similar situation as OP, 20 years of experience as dev, team lead and engineering manager, yet because I didn't know the intricacies of our custom framework the second I walked in the door, many of my suggestions were dismissed upfront and, a year in, I feel it's an uphill battle to get my ideas treated with anything other than suspicion.
That suspicion is healthy. You don't know the technology being used, per your own admission.
Ah, if only I had a dollar for every project turned into a mess because some engineering manager (who probably coded in COBOL last) thought they knew what they were talking about and pushed down some crappy choice
> There are always "fights" in the beginning I guess, but if you are confident, know your shit, it should be very easy to convince less experienced people.
Why would anyone do that, though? This is management's job to help get value out of senior engineers. It'll be the company debt to pay this technical debt. You still get a salary at the end of the day.
