Surely you don't mean the Go team, which has had this in the language FAQ since 2009 [1]:
Why does Go not have generic types?
Generics may well come at some point. We don't feel an urgency for
them, although we understand some programmers do.
Generics are convenient but they come at a cost in
complexity in the type system and run-time. We haven't yet found a
design that gives value proportionate to the complexity, although we
continue to think about it. Meanwhile, Go's built-in maps and slices,
plus the ability to use the empty interface to construct containers
(with explicit unboxing) mean in many cases it is possible to write
code that does what generics would enable, if less smoothly.
While that would probably be very valuable, it will probably come with lots of implementation details that won't really matter to you unless you plan to write a database yourself.
I'd suggest this one: https://dataintensive.net/ Its intended for _users_ of databases, that is, developers incorporating databases (and other kinds of data systems) into their applications. It gives just enough explanation on how those systems work and what they can (and can't) provide, and also gives a more general overview of what's available beyond relational SQL databases.
This was also commonplace in Spain, traditionally. Some people, especially old ones, will say "si Dios quiere" literally every time they refer to any event in the future, even if it's just "see you tomorrow". Not doing so would be considered a "challenge" to God, or Fate, more generally.
Curiously, from "inshallah" Spanish got the word "ojalá", a very common term for expressing hope of something happening (and with no religious or any other "deep" connotation anymore; just like you'd use "I hope").
In Poland we have a saying "jeżeli Bóg pozwoli". "If god allows" which funyly shows that deep down people "understand" (as their pre-monotheistic ancestors "understood") that the God is the malevolent being that messes up your plans and ultimately kills you.
These are two manifestations of the same feature: function arguments's default values are evaluated when the function is defined.
In one case, the value is a non-mutable int, while in the other it's a mutable list, but in both cases each call to those functions will share the same value for that argument (unless overriden).
Hold on. Instead of saying "some people" you should be more direct in what you mean. You should say, YOU and refer to me directly and have your words be inline with your intentions.
Now that being said. Go looks to me, to indeed be made by someone who doesn't know that a sum type exists. In my link Rob Pike himself admits that he didn't know about structural typing.
Additionally Rob seems to be in general not up to date on type theory. Please follow and read the link above to see what I'm talking about.
Now, that being said. Never EVER did I dismiss Rob Pikes background. He's done great things. Now I will say something exactly in line with my intentions: You have told an utter lie where you accused me of dismissing Rob Pikes reputation. I have done NO such thing.
Additionally one question. What site are you using to run a background check? doesPikeKnowWhatASumTypeIs.com? Sometimes people make mistakes. I admit the possibility that I'm wrong, but limbo is kind of an obscure programming language. It's not easy to given that they use the term discriminated union type rather then the "sum type."
I would argue that although this type is included in limbo, Rob likely didn't use it too much or know about its use case to bring errors into the type system as he could have easily used it in Go. I could be completely wrong here but one thing is not wrong:
>Some people are ridiculously daring at dismissing others's reputations without the most basic of background checks.
Accusatory language like this even disguised with "Some people" and that are additionally utter lies are not an acceptable way to start a discussion.
Other things equal, if companies need to pay severance, employees get paid less each month, because companies need to take into account expected severance costs in their total labor costs and there's less money left for other benefits.
So all employees effectively pay for layoffs, which goes against you if you're not the one that gets laid off.
(I am very much in favor of mandatory severance and generally other kinds of safety nets.)
Having done budgeting for hiring employees in the UK, for small and medium sized companies, the factors that went into calculating staff costs never included any severance or redundancy factors. Paying redundancy is relatively rare, so doesn't need allocated funding until you're in that process.
When you're employing people you're not already thinking about their future exit. You hire based on your growth, so you're usually optimistic about the future and thinking about employees being long term. If not you hire contractors, who you can lay off easily.
Part of this is that you can't just fire people without good cause and without following a process. There are probationary periods to allow the hire to be let go if they don't work out in the first 6 months or so, but after that you're into a long "managing them out of the business" process that may or may not end up with a pay off.
> but after that you're into a long "managing them out of the business" process that may or may not end up with a pay off.
I'm sure you already know, but in the UK you can be fired for any non-protected reason within the first 2 years of employment. I think UK companies are typically less cavalier than their US counterparts when it comes to firing, but in the frist 2 years, the employee protections are similar to US at-will states.
> When you're employing people you're not already thinking about their future exit. You hire based on your growth, so you're usually optimistic about the future and thinking about employees being long term. If not you hire contractors, who you can lay off easily.
+1 for the contractors thing. If there is already an expiration date for these people, then make them a contractor or reach out to a staffing firm.
This forgets the high likelihood that the amount that would have been paid as severance goes to the pockets of the owners and leadership. The market pays what the employees are worth, not what is left over after costs.
> So all employees effectively pay for layoffs, which goes against you if you're not the one that gets laid off.
Or you could say that the company needs to save the profit generated by your position until it equals your anticipated severance before paying dividends from that profit. So it’s still a drag on profits, but it has nothing to do with other employees.
> So all employees effectively pay for layoffs, which goes against you if you're not the one that gets laid off.
Sounds like a very acceptable compromise. I'm happy to chip in. I'm also happy that I pay taxes for universal healthcare so that I can take advantage of that when I'm in a disadvantaged position, but that's me.
`curl X | bash` provides _more_ transparency than most other usual methods of software distribution, as I can always inspect X, which is usually a simple, self-contained script.
In contrast, running code from an unaudited source (GitHub, NPM, etc.), or executing a binary from some random website, all less transparent yet just as dangerous, but for some reason raise way fewer eyebrows.
Those methods of installing stuff suck too, and its not like you have to pick one of the three...
The main problem isn't malicious code, you can review the script after all, the main problem is the app making unwarranted assumptions about your install/distribution, then breaking things in the process.
Correction: -n and -x are obviously mutually exclusive. Have to use -v instead.
curl https://example.com/setup.sh | bash -vn
As for trying to hide commands from an execution trace, it is not possible to hide the set +x command.
cat > 1.sh
echo visible
set +v
set +x
echo hidden >/dev/null
^D
cat 1.sh | bash -x
Output:
+ echo visible
visible
+ set +v
+ set +x
One can syntax check setup.sh before downloading it with -vn (or perhaps shellcheck). After downloading and reading it, one can observe it while it is running with -x.
The truth is that people download and run shell scripts without reading them all the time. For example, how many people installing software packaged with configure scripts actually read the scripts. (Except in the event they do not work.)
Bash scripting is incredibly powerful but also terribly broken with horrible edge cases. E.g. if syntax, bash quoting, -print0, parsing strings with regexps...
It's near impossible to build sound applications with bash.
Surely you don't mean the Go team, which has had this in the language FAQ since 2009 [1]:
Why does Go not have generic types?
Generics may well come at some point. We don't feel an urgency for them, although we understand some programmers do.
Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
[1] https://github.com/golang/go/commit/dd64f86e0874804d0ec5b713...