Merkur

Yea, LLM remove the burden of typing - so if token cost don’t explode the new high-level languages will be above the current - and the new low-level language will maybe just weights…

I feel the same, but still believe there is a way to organize my work to make it happen. It’s more like leading a team of juniors: don’t let them drag you into their private rabbit holes, enable them to implement how ever tiny or big chunks they are able too. The common problems is exactly a Junior habit: always inventing new stuff instead of moving existing pieces, always adding never removing and punching holes in blackboxes to workaround mystery.

Agree, but I think it is still better than before, because of the color differences to the headline.

I still would prefer a true Icon.

It would be ok if America would ban Huawei from building national infrastructure - it wouldn’t be very capitalistic tho.

But it is down right evil to impose extraterritorial sanctions against a company and preventing other to do business with them.

Your phone nummer is global unique id of your person. Even more as many nations require you register the phone number with personal informations.

While waiting for the article to load i was thinking - was zero or one the first number? Or was it two, because you need at least two to start counting?

Then i realized that i was offtopic in a kinda funny way

While Waiting until the article has loaded, i tried to figure out if Zero or One came first ... doh

great! thanx!

Indeed! After all we live in a world where many ssl private certificates are only protected by OS file system rights on a internet facing server. And clear text database passwords in config files are common, in all content management systems - and even many customer relationship systems!

mysqldump got a CLI argument to provide the password! As far as I know - visible to anyone with some access on the system. the documentation warns about that and suggest to create a config file to store the password.

security is a spectrum - but if it's about password storage in modern web applications live on the lower end.

I am increasingly frustrated by that - and if I raise concerns many admins stick to binary security "storing stuff unencrypted on disk is okay, cause the attacker is inside already" followed by "you must store the key somewhere" it's wrong and it's true at the same time. it's also sad - because not only the users, but also the ppl paying us trust us to keep them save. and we don't. :( we can say "it's a spectrum" and we are truthful - but we just can't keep em safe. I think it's important to recognize that simple fact.

...or is it me who is just meticulous?

I did not know such thing is possible. very cool! thx for pointing it out! :)

but still..some rhetorical questions: Is KMS based on this concept? Is it's implementation open sourced? Is it verified to run unchanged in the instance I pay? Who is verifying it? Who is paying the one verifying it? Can I meet him / her to drink a coffee and build trust between us?

pls, do not misunderstand me. I got more trust in the amazon techs than in my own ability to admin a complex linux system on bare metal. But while all that is great progress toward security we still need to make a leap to find a solution. don't we?

Please correct me if I am wrong, but I think there is no secure way to store stuff in an virtual environment.

I wish I am wrong - cause my heart always bleeds if I see db passwords in configuration files! But As long as there is a hypervisor you do not control access to - you must trust the owner of the bare metal to (1) honor your privacy (2) be competent to secure his system. Trust is nice, but it is not security.

granted - Confidant and KMS seem better solution than most. Will look into it at more detail. thx for open sourcing it and moving the solution forward.

cool Release! i realy like the all the improvements in tooling. thx!

seems cool, but what is it good for?

I had fun reading - thx. I found the solution of "requesting workers" interesting. My first reflex to the round robin argument was - a better load balancer but the requesting worker made that totally not necessary! I wounder what negative sites sutch architectures may have?

whee exciting new stuff AND a foundation for even more stuff in the future. great thx!

looks tiny. great!! I'll use it in my next toy project to test it out.

thx!

LWN got an article about it... https://lwn.net/Articles/644675/

I didn't find very mutch information about it.. yet. :( anyone played with it?

while arguing against your self is nice practice - diarrhea is just... you know... really messy. I hope you get well soon. :)

Actually it would remind me on C. It did not even support a redundant comment token, and of course they did not used a comment to mark directives.

go troll your self. I am always open to argue, but you have no leverage to be snarky.

well, i see - my statement was flawed. :)

okay, i'll jump :)

1) First of all change is not nessesary - because within the current "comment directive convention" the tooling needs can be achived. Even more so - they can be achived without changing the current spec of the language.

2) As I learned during this discussion there are "comment directive convention" that are older as go 1.4. I could imaging they play a role deep inside the go tooling. i.e. I could imaging that the cgo stuff has some deep roots. It would some work to change all occurences - that is glass clear - because even now there are legacy directives // +build //link that are not updated to the "new convention" //go: foo

3) I dont know about the internal mechanism that the go team needs to observce to change the spec of a language, that is perhaps in wide productive use within the google. But i can imagin there is procedure. Changing the spec meight just not be possible before Go 2.0 because of policy.

4) It meight not be desired to introduce something that smells like a macro language into the code. There meight be some animosity againt it - give the clean code philosopy that Go aimes for.

No, i dont realy believe that. I am Sorry to have accused! On contrary: The yacc tool gives great power to expand the language. But yacc is a heavy lifting tool and not something like a macro every one could use. Its also not part of the spec, just given as magic comment - no prommise made.

5) One counter argument that is invalid: I am pretty sure the go team cares about semantic. :-) All programmers do breath semantic. Of course there are different tastes.

6) You basicly cant prevent magic... in comments or otherwise its the reason its called magic.

7) those commented directives can stay in all levels of the build process - without adaptions of the spec. This means tools have the potential to hook on source, on ast, etc.

if you can agree that i got arguments that convince - i do you the favor. :)

thank you, for beeing open to be convinced :)

I too like the idea that comments are more than blabber. I do use comments like //BUG: //TODO: and //HOT:

My argument is semantic? Yes it is! In my optinion thats the reason my argument is so strong.

Please dont tell me you dont see a problem between //go: foor and //todo: bar - the first instructing some tool to change stuff in your build, the later merly mention that there is something left to do here.

A directive like #todo: bar - is a great example for a great tool in the chain. the go tool could look for a "todo" command and this todo command could print out a warning that the code should not be released because XX todos arn't done. If the go tool would'nt find a "todo" command it could warn me that a tool in the chain is missing. I could evaluate in decide to use get this tool, or choose to ignore it.

This would be imposible if comments are missused as directives!

Code should not be magical. Magic is bad engeneering. Magic involving a whitespace is madness.

One of the best features of go is "go fix" Yea! A migration tool for the language it self? Before they need to worry about compatibility they can break a lot of stuff.

Yes, I like to elaborate. Good code is unambiguous.

IF has a meaning - and it always have this meaning. FUNC has a meaning - always the same. // are comments. The meaning of comments is to communicate with humans.

We know the principal of "overloading" syntax. Things can have a different meaning in a different context. One could argue using //go: is overloading the comment. BUT: Go is not a language that do's overloading - in fact its philosophy is against overloading, as it is against generics. (and I realy like this philosophy!)

I argue that directives to the tool chain should not apear in a comment - because a directive to the tool chain has a different & incompatible meaning than a comment.

I argue future: There is a need for directives to the tool chain in the Go source code. The go-team has this need, and there can be great things done with such e mechanism. The go community will do great things with directives! I see tons of use cases for godep. I see tons of use cases for debuggers, profilers and all kinds of other tools.

The go-team not only implements go, they also set an example to the usage of the language. If they misuse comments to express directives, other projects will eventualy follow.

But what will happens in the long run if we embrace that example and use //foo: bar as directives for our tool chains?

The go tool chain could not generate meaningfull errors about missing tools, or syntax errors in directives. Also: Comments would not be safe to communicate with fellow programmers - who knows that kind of tools where used in my dependencies? And what kinds of //foo: should be marked pink in my editor? All of em?

All this could be solved by using an other syntax for directives. I do not care if its # or @ or #! or whatever - as long as it is not a comment.

I also have no argument about macros, generics or whatever. I just want go to be unambiguous.

I would define a directive as an instruction to the tool chain.

A macro processor could be one of those tools in the chain. There could be other (and Go implements other use cases!)

I would also argue that a macro preprocessor do'snt need to "parse comments", it could parse any syntax the preprocessor wants to (and remove it from source befor the compiler sees it) In fact my point is, that parsing comments at all is a very bad idea.

But my argument is NOT about, if Go needs a macro processor, or not. (i think it dont!) My argument is about the syntax of the directive.

I argue about the syntax of declaring "Here comes something that is not Go Language!" I argue that this syntax should not be a comment - because a comment is part of the Go Language. (...among other reasons i stated in this discussion)