GnomeTankWhat the what?Portland, OregonRegistered Userregular
Interesting. That was a very, very long argument in the Go community. I've always supported their inclusion but it seemed like some of the core team was dead set on them not being in the language. Glad to see they are coming.
Word was that the accounts weren't compromised but the private git they ran was, so they took that down and moved to using github as the official repo.
+3
Options
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
Interesting. That was a very, very long argument in the Go community. I've always supported their inclusion but it seemed like some of the core team was dead set on them not being in the language. Glad to see they are coming.
My sense was that, while everyone wanted it and saw the value, nobody could agree on a syntax that was sufficiently idiomatic. It took a few years, but it seems like we've settled on something. It is exciting, though I'm holding my applause until I can do some benchmarks on pre vs. post generics code and see if it actually worth using in real life. I tend to use Go when I need performance, but don't want to go Full C. Or, ironically, if I just want a quick script with any kind of loop or logic in it that makes me want to avoid bash.
I don't know assembly at all, only played with a fake ISA in college, but it looks really cool if you are into this kind of thing.
Monkey Ball Warrior on
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
+1
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited April 2021
In theory, with proper compiler integration and proper use of the LLVM back end, generics should be a zero cost abstraction. They shouldn't slow code down at all because they shouldn't be a runtime facility. They could possibly implement it poorly and take a dynamic dispatch hit, but even that should be extremely minimal (and completely avoidable).
In theory, with proper compiler integration and proper use of the LLVM back end, generics should be a zero cost abstraction. They shouldn't slow code down at all because they shouldn't be a runtime facility. They could possibly implement it poorly and take a dynamic dispatch hit, but even that should be extremely minimal (and completely avoidable).
Go comes with its own compiler (written in itself, of course) and there's a GCC front end too. I'm not sure about LLVM though, but I don't see why there couldn't be one if there isn't already. I've only ever really used the built-in one.
Monkey Ball Warrior on
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Self hosted compilers are pretty much the standard these days. If the changes for that compiler, and the LLVM output from the resulting back end changes, is done correctly, with modern ways of implementing generics, they should net to a zero cost abstraction. Rust does it with LLVM as it's primary compiler back end, so can Go.
Generics*? I think I just became interested in using Go again, having moved much of my daily development work to C++, C#, and Swift!
I like Go (Hoare knew his stuff!), but I got frustrated by having to e.g. write a wrapper for the ipv4/6 PacketConn stuff (containing literally identical code) so I could write a single handler routine and easily set the control message flags etc.
Little things like that tend to bug me.
* I tried to write some numerical code in Rust about a year ago to kick the tyres a bit, but the trait definitions seemed to be scattered all over the place, and I got sick of sifting through the documentation trying to figure out what traits were specified where. Has this situation changed since then? I quite liked Rust, but it was driving me nuts.
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Generics*? I think I just became interested in using Go again, having moved much of my daily development work to C++, C#, and Swift!
I like Go (Hoare knew his stuff!), but I got frustrated by having to e.g. write a wrapper for the ipv4/6 PacketConn stuff (containing literally identical code) so I could write a single handler routine and easily set the control message flags etc.
Little things like that tend to bug me.
* I tried to write some numerical code in Rust about a year ago to kick the tyres a bit, but the trait definitions seemed to be scattered all over the place, and I got sick of sifting through the documentation trying to figure out what traits were specified where. Has this situation changed since then? I quite liked Rust, but it was driving me nuts.
Not really. Once you know the subset of system level traits, it's an easy list to deal with...but the discoverability is kind of garbage. This is true of a lot of idiomatic Rust.
thatassemblyguyJanitor of Technical Debt.Registered Userregular
All your APIS are belong to fair use. hooray!
Applying the principles of the Court’s precedents and Congress’codification of the fair use doctrine to the distinct copyrighted workhere, the Court concludes that Google’s copying of the API to reimple-ment a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative pro-gram, constituted a fair use of that material as a matter of law.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited April 2021
IANAL, but from listening to some folks I know who are,, it's a good ruling, but it's also a narrow one. It actually doesn't enshrine API's as non-copyrightable as a matter of jurisprudence. Just that in this particular case Google met fair use. It does mean that's the direction the court leans, but as with most things it would just be easier of congress wasn't a dysfunctional mess and updated legislation to cover the topic.
thatassemblyguyJanitor of Technical Debt.Registered Userregular
6-3, I'll take it over a 5-4, and it doesn't really clear up if you can copyright the APIs, but it doesn't matter: fair use. (though patents would probably override things if the API was specific enough that there's no way an implementation doesn't violate some claim on a granted IP).
IANAL, but from listening to some folks I know who are,, it's a good ruling, but it's also a narrow one. It actually doesn't enshrine API's as non-copyrightable as a matter of jurisprudence. Just that in this particular case Google met fair use. It does mean that's the direction the court leans, but as with most things it would just be easier of congress wasn't a dysfunctional mess and updated legislation to cover the topic.
It's more useful than this makes it sound. When fair use cases go to trial they are usually ruled on based on previous cases. This will be used as precedent for fair use for any api related fair use case well into the future.
Applying the principles of the Court’s precedents and Congress’codification of the fair use doctrine to the distinct copyrighted workhere, the Court concludes that Google’s copying of the API to reimple-ment a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative pro-gram, constituted a fair use of that material as a matter of law.
6-3, I'll take it over a 5-4, and it doesn't really clear up if you can copyright the APIs, but it doesn't matter: fair use. (though patents would probably override things if the API was specific enough that there's no way an implementation doesn't violate some claim on a granted IP).
Barrett did not participate, so it was 6-2. Is she on record as dissenting? I couldn't find any quote from her on the topic.
IANAL, but from listening to some folks I know who are,, it's a good ruling, but it's also a narrow one. It actually doesn't enshrine API's as non-copyrightable as a matter of jurisprudence. Just that in this particular case Google met fair use. It does mean that's the direction the court leans, but as with most things it would just be easier of congress wasn't a dysfunctional mess and updated legislation to cover the topic.
It's more useful than this makes it sound. When fair use cases go to trial they are usually ruled on based on previous cases. This will be used as precedent for fair use for any api related fair use case well into the future.
Sure, but it still leaves the copyrightability of API's in complete limbo. Yes, in this case, Google proved fair use, and in future cases if people can prove fair use this precedent will likely be used...but it doesn't blanket solve the issue of whether an API is something you can copyright.
It's important as you can't copyright a set of API techniques, so open standards are still a thing and you don't have to hunt down prior art. That's huge. I think copyright is a bit out the window as any IP you wish to protect would be in patented techniques/technology or owned data.
+2
Options
thatassemblyguyJanitor of Technical Debt.Registered Userregular
Applying the principles of the Court’s precedents and Congress’codification of the fair use doctrine to the distinct copyrighted workhere, the Court concludes that Google’s copying of the API to reimple-ment a user interface, taking only what was needed to allow users to put their accrued talents to work in a new and transformative pro-gram, constituted a fair use of that material as a matter of law.
I didn't quite understand what Google did. So Google just had methods with the exact same signatures and names as standard/Oracle Java?
Exactly. They took the Java API you can see using Javadoc and just reimplemented it so they wouldn’t have to deal with oracle’s money grab.
0
Options
gavindelThe reason all your softwareis brokenRegistered Userregular
As a new developer to C#, the details of await cost me several days of hair pulling. I was quite convinced that a routine authentication library was somehow broken and spent hours digging through cloud configurations looking for the broken link.
Nope. Incorrect await. My tests happily finished instantly, never listening for the server's response.
We have a guy here that insists on keeping unused and commented code around "just in case we need it later" or "we might forget about it" despite "everyone" saying this is a bad practice (which I agree with). We have source control...just pull it out of there or keep it in a scratch pad. He has multiple decades of experience, so I'm assuming it's just a case of being used to not having source control? I don't know, trying to give the benefit of the doubt.
3ds: 4983-4935-4575
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
We have a guy here that insists on keeping unused and commented code around "just in case we need it later" or "we might forget about it" despite "everyone" saying this is a bad practice (which I agree with). We have source control...just pull it out of there or keep it in a scratch pad. He has multiple decades of experience, so I'm assuming it's just a case of being used to not having source control? I don't know, trying to give the benefit of the doubt.
While in general I agree, once it's in source control only it becomes a giant pain to find it.
So I kind of understand where he's coming from if it's for a one-off in response to a lot of pain in the past.
Yeah good luck ever finding it again. You have to remember it exists and where it was (and searching won't help you there) and roughly when it existed, and then you have to find the latest version of it and possibly port it to the latest version of the codebase. If you are a git wizard maybe you already know all the magic incantations to get git to do all this searching for you and that's the hard part, otherwise if it was potentially useful I'd probably keep it around until it started conflicting with other stuff or sat unused for a long time and then remove it rather than spend the maintenance. Maybe add a comment and a future todo to remove if unused
I don't mind keeping unused code around, but it can't be commented out. It has to retain decent test coverage so it doesn't rot. If you're just going to comment it out or let it sit without tests, then it's actively harmful and ought to be removed.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
If something is that important that I might forget it I'll stick it in a scratch folder I keep git'ed up.
Outside of that, old code gets dumped. It's a maintenance and readability nightmare to have old code just floating around your source base that does nothing. I like it even less when it's just dead code that gets called nowhere but tests. Now you're just adding test time and test maintenance to code that isn't even run anymore. IMO cleaning up after yourself is part of being a professional engineer. It's really not that hard to find something in your history if you really need it again. One has to question just how important the code was if the hurdle of "figure out how to search old commits" is too much.
If something is that important that I might forget it I'll stick it in a scratch folder I keep git'ed up.
Outside of that, old code gets dumped. It's a maintenance and readability nightmare to have old code just floating around your source base that does nothing. I like it even less when it's just dead code that gets called nowhere but tests. Now you're just adding test time and test maintenance to code that isn't even run anymore. IMO cleaning up after yourself is part of being a professional engineer. It's really not that hard to find something in your history if you really need it again. One has to question just how important the code was if the hurdle of "figure out how to search old commits" is too much.
Also, having dead code in comments is just things for ctrl+f to find.
Possibly dumb git question, if I tag a commit on a branch and then push the branch+tags to the remote with --tags will that tag now automatically follow the branch through pulls/checkouts/merges? Like will a
git pull taggedBranch
bring the tags with it or does that require an extra flag like pushing tags?
Carpy on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Possibly dumb git question, if I tag a commit on a branch and then push the branch+tags to the remote with --tags will that tag now automatically follow the branch through pulls/checkouts/merges? Like will a
git pull taggedBranch
bring the tags with it or does that require an extra flag like pushing tags?
You want -t/--tags if you want to ensure all tags are brought down with the pull.
I'm evaluating Sentry for distributed tracing, and it turns out it's amazingly easy to blow through those 100k transactions you get with a basic paid account. If I mathed right 100k transactions monthly equals one transaction every 25 seconds.
This was just with a very basic linear rate limit, I have plenty of ideas to limit sampling to useful stuff.
Interesting stuff to dabble with, though. We'll see if we end up using it for tracing, they seem a bit pricy as soon as you have more than a very basic volume of stuff. Also considering Grafana Tempo for tracing, though it's still pretty early in development.
Echo on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
We have Sentry at work...it's okay I guess? It's like most of these tools...if you don't do the work to set them up correctly, and make sure all your code is using them correctly, they are just noise.
We're actually moving all our distributed tracing/observability in to DataDog, which is a massive project.
Possibly dumb git question, if I tag a commit on a branch and then push the branch+tags to the remote with --tags will that tag now automatically follow the branch through pulls/checkouts/merges? Like will a
git pull taggedBranch
bring the tags with it or does that require an extra flag like pushing tags?
You want -t/--tags if you want to ensure all tags are brought down with the pull.
We've had Sentry to report frontend errors for some time, but now we're checking it out for backend stuff as well, since we already have it in the frontend. It's simple enough to report errors, but yeah, doing tracing right needs some thought put into it.
Grafana's Tempo does look very promising if they can deliver on that "don't do sampling, just shove everything into Tempo" statement.
I have no idea about the biling side of things, but Sentry has been a hell of a lot more helpful at tracking down bugs than trying to pull teeth with replication steps from QA or clients
I have no idea about the biling side of things, but Sentry has been a hell of a lot more helpful at tracking down bugs than trying to pull teeth with replication steps from QA or clients
Yeah, so far it's been really useful.
Too bad I'll have to enter the Thunderdome to get expanded usage of it approved.
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
Possibly dumb git question, if I tag a commit on a branch and then push the branch+tags to the remote with --tags will that tag now automatically follow the branch through pulls/checkouts/merges? Like will a
git pull taggedBranch
bring the tags with it or does that require an extra flag like pushing tags?
You want -t/--tags if you want to ensure all tags are brought down with the pull.
Much appreciated
Alternate answer: use TortoiseGit or a similar GUI and don't think about the idiotic defaults and insane command line names to make it do what you want it to do.
Difficulty: you may still have to drop back to the command line to do things like bisecting or identifying common ancestors (unless your repo has few enough users you can do it visually)
Orca on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited April 2021
To each their own. I'll continue to use the command line because it's infinitely flexible and always available. For common operations I can type faster than I can click a UI. Most of the UI's don't support the really complex "break glass in case of" operations anyway, so you end up back at the CLI for those.
I used to use things like Tortoise, but when I moved out of the Windows world and in to the Linux/OSX world I just kind of learned to grey beard it.
e: Also any modern shell is going to have auto completion for major tools. I use Oh My Zsh everywhere and I have full auto completion, with integrated help strings, for git, docker, terraform, helm, etc. etc.
Posts
https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d#diff-a35f2ee9e1d2d3983a3270ee10ec70bf86349c53febdeabdf104f88cb2167961R370
Yikes, apparently 2 accounts compromised. Also happen to read about this today: https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/. Attack vectors keep increasing, it seems.
Word was that the accounts weren't compromised but the private git they ran was, so they took that down and moved to using github as the official repo.
My sense was that, while everyone wanted it and saw the value, nobody could agree on a syntax that was sufficiently idiomatic. It took a few years, but it seems like we've settled on something. It is exciting, though I'm holding my applause until I can do some benchmarks on pre vs. post generics code and see if it actually worth using in real life. I tend to use Go when I need performance, but don't want to go Full C. Or, ironically, if I just want a quick script with any kind of loop or logic in it that makes me want to avoid bash.
Speaking of go, Some folks I follow are speaking highly of this Go Assembly Generator dodad. Avo: https://github.com/mmcloughlin/avo
I don't know assembly at all, only played with a fake ISA in college, but it looks really cool if you are into this kind of thing.
Go comes with its own compiler (written in itself, of course) and there's a GCC front end too. I'm not sure about LLVM though, but I don't see why there couldn't be one if there isn't already. I've only ever really used the built-in one.
I like Go (Hoare knew his stuff!), but I got frustrated by having to e.g. write a wrapper for the ipv4/6 PacketConn stuff (containing literally identical code) so I could write a single handler routine and easily set the control message flags etc.
Little things like that tend to bug me.
* I tried to write some numerical code in Rust about a year ago to kick the tyres a bit, but the trait definitions seemed to be scattered all over the place, and I got sick of sifting through the documentation trying to figure out what traits were specified where. Has this situation changed since then? I quite liked Rust, but it was driving me nuts.
Not really. Once you know the subset of system level traits, it's an easy list to deal with...but the discoverability is kind of garbage. This is true of a lot of idiomatic Rust.
https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf
It's more useful than this makes it sound. When fair use cases go to trial they are usually ruled on based on previous cases. This will be used as precedent for fair use for any api related fair use case well into the future.
I didn't quite understand what Google did. So Google just had methods with the exact same signatures and names as standard/Oracle Java?
Barrett did not participate, so it was 6-2. Is she on record as dissenting? I couldn't find any quote from her on the topic.
edit: wikipedia article is good enough. https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.
Sure, but it still leaves the copyrightability of API's in complete limbo. Yes, in this case, Google proved fair use, and in future cases if people can prove fair use this precedent will likely be used...but it doesn't blanket solve the issue of whether an API is something you can copyright.
(Again, IANAL).
Exactly. They took the Java API you can see using Javadoc and just reimplemented it so they wouldn’t have to deal with oracle’s money grab.
Nope. Incorrect await. My tests happily finished instantly, never listening for the server's response.
Uuuuuuuuugh.
While in general I agree, once it's in source control only it becomes a giant pain to find it.
So I kind of understand where he's coming from if it's for a one-off in response to a lot of pain in the past.
Outside of that, old code gets dumped. It's a maintenance and readability nightmare to have old code just floating around your source base that does nothing. I like it even less when it's just dead code that gets called nowhere but tests. Now you're just adding test time and test maintenance to code that isn't even run anymore. IMO cleaning up after yourself is part of being a professional engineer. It's really not that hard to find something in your history if you really need it again. One has to question just how important the code was if the hurdle of "figure out how to search old commits" is too much.
Also, having dead code in comments is just things for ctrl+f to find.
You want -t/--tags if you want to ensure all tags are brought down with the pull.
This was just with a very basic linear rate limit, I have plenty of ideas to limit sampling to useful stuff.
Interesting stuff to dabble with, though. We'll see if we end up using it for tracing, they seem a bit pricy as soon as you have more than a very basic volume of stuff. Also considering Grafana Tempo for tracing, though it's still pretty early in development.
We're actually moving all our distributed tracing/observability in to DataDog, which is a massive project.
Much appreciated
Grafana's Tempo does look very promising if they can deliver on that "don't do sampling, just shove everything into Tempo" statement.
Yeah, so far it's been really useful.
Too bad I'll have to enter the Thunderdome to get expanded usage of it approved.
Alternate answer: use TortoiseGit or a similar GUI and don't think about the idiotic defaults and insane command line names to make it do what you want it to do.
Difficulty: you may still have to drop back to the command line to do things like bisecting or identifying common ancestors (unless your repo has few enough users you can do it visually)
I used to use things like Tortoise, but when I moved out of the Windows world and in to the Linux/OSX world I just kind of learned to grey beard it.
e: Also any modern shell is going to have auto completion for major tools. I use Oh My Zsh everywhere and I have full auto completion, with integrated help strings, for git, docker, terraform, helm, etc. etc.