nur0n

I believe BuildKit solves the dependency graph problem. Docker has shipped with it since 18.09. It is opt-in for now so you have to use e.g. `DOCKER_BUILDKIT=1 docker build ...`.

https://github.com/moby/buildkit

This primary source provides better details on YouTube's policy: https://support.google.com/youtube/answer/9891785?hl=en. It includes concrete examples of content that is banned under this policy.

Can you elaborate on your experience?

I have great respect for Rich Hickey and I recently saw a cool talk about a financial startup using Clojure in production [1]. I have kept track of the language for some time but have never had the chance to use it in any serious capacity.

[1] https://www.youtube.com/watch?v=fnediEWRuyI

I like to watch talks by programming language designers. Some that readily come to mind are Rich Hickey, Joe Armstrong (RIP), and Stefan Karpinski.

Some of my favorites are:

- Simple Made Easy (Hickey): https://www.youtube.com/watch?v=oytL881p-nQ

- The Mess We're In (Armstrong): https://www.youtube.com/watch?v=lKXe3HUG2l4

- The Unreasonable Effectiveness of Multiple Dispatch (Karpinski): https://www.youtube.com/watch?v=kc9HwsxE1OY

They do not just show ads. They also display content.

Existing in a filter bubble has a strong effect on your perception. Perception has a direct influence on your actions. Couple this with interfaces which are purposefully addicting ("high user engagement" is a euphemism), and you can very directly influence behavior.

The pervasiveness of smartphones means that these apps are only a few clicks away for virtually the entire world population. And worse, once these apps are installed on your phone, they relentlessly pull you back in with and endless stream of notifications.

It is not only Facebook. Applications like Reddit, YouTube, Instagram, Twitter, and TikTok all follow the same basic patterns.

It is not an overly dramatic description. If anything the public has been frightfully unaware of the influence that these companies can exert on the world. I am glad that this film has brought these issues into the spotlight.

There was a huge discussion shortly after Julia 1.0 was released regarding scoping [1]. Beginners intuitively think of scoping in a manner different from the way scoping should work in production projects. There was a lot of tension between seasoned programmers and educators (who had to constantly interact with beginners).

The community exhausted the entire design space (along with some full-blown prototypes). Eventually, the core Julia team chose to use more forgiving scoping in the REPL (virtually always the first point of contact for beginners), while actual projects enforced stricter scoping rules.

My key take-away is to consider how the language interacts with its ecosystem, not just how it should ideally operate in isolation. I have found the Julia team to be consistent in this pursuit. If the first point of contact is intractable for beginners, the project is dead on arrival. A technical tool should be tailored for experts, but you don't want to kill adoption along the way. Engineering is tradeoffs.

This article goes more in depth along the same lines: https://pchiusano.github.io/2016-02-25/tech-adoption.html

[1] https://discourse.julialang.org/t/another-possible-solution-...

Yep Microsoft has the good habit of dogfooding its own products. All of Office 365 uses Azure AD for identity management.

I love how easy it is to view the machine code for a function. Julia actually ships with a handful of these introspection macros: https://docs.julialang.org/en/v1/devdocs/reflection/#Interme.... They are invaluable when it comes to optimization.

"Language agnosticism" is an ideal I have never been able to attain. Sure, I can hack together a solution on the first week of learning a language. But, am I able to write elegant, idiomatic, efficient code during the first few months? No way.

A language is not just the basic control flow operations, but includes package management, performance gotchas, correctness gotchas, standard library, library ecosystem, data representation, etc. Then there are details and edge cases that you just don't hit without months or years of hard work with a language.

My experience tells me to take choose a reasonably robust language, then stick to that language until you have an overwhelmingly compelling reason to switch.

Vice made a mind-blowing series on this if anyone wants to see with their own eyes: https://www.youtube.com/playlist?list=PLw613M86o5o7a0FGlPRdt...

People seem to focus on the volume of cars. But traffic is not just a matter of volume but of friction between cars. Reducing the friction (naively) appears to be a simpler problem. You wouldn't even need full self driving, only enough tech for cars to merge/switch lanes without slowing down.

Not requiring a central point of control is an additional benefit. The reduction of traffic would be an "emergent" behavior.

I feel compelled to restate how wonderful this book is.

> it has also helped me think about my feelings

The book focuses on communication with others, but effectively fosters constructive inner dialogue as well. I know of at least one other person who claimed it helped them avoid destructive habits.

> it has helped me put more structure around tough conversations

I deescalated a nasty dispute between two people close to me after reading only the first few chapters. I was impressed because I wasn't the type of person to emotionally connect with people so effectively.

I believe the world would be a better place if more people read this book.

There is a very cool Julia library: https://github.com/Evizero/UnicodePlots.jl

One way is to show that, given a state of the universe, it is possible to determine the next state. From what I understand, this does not seem to be the case.

> So, what we do is take money and move it around into other businesses. The newspaper business earned great returns but not on incremental capital. But the people in the industry only knew how to reinvest it [so they squandered a lot of capital]. But our structure allows us to take excess capital and invest it elsewhere, wherever it makes the most sense. It's an enormous advantage.

Wow, they are playing the game at a higher order than I have even considered.

> since most things Internet are US-based

What is meant by this?

I don't know Julia's history, but it sits right next to CommonLisp in my head.

Racket has a special place in my heart. Racket, together with https://htdp.org/, helped me reach a point where I felt my code truly reflected the structure I was modeling. It helped me focus on data flowing through my code, rather than blindly following "cookbooks". Racket is one of the very few languages that get out of your way, so that the model is almost tangible.

Code design is what keeps complex projects from collapsing under their own weight. There are always trade-offs when constructing software, but I feel that design is often neglected needlessly.

This is a known `Pkg` bug (the patch should be merged this week). In the meantime, you have to `pkg> rm SymEngine` followed by `pkg> add SymEngine#master`.

Apologies, I wasn't trying to be pedantic. My point is that Juno is decoupled from the language itself. You don't have do depend on it to be productive with Julia.

I agree that tooling has a significant influence on the productivity of a language. One does not only adopt a language, but the ecosystem and community around it. I think we both agree on this. I am simply trying to point out that there is an unavoidable delay between the maturity of the language and the maturity of the ecosystem. I think its fair to take this delay into account.

JuliaComputing is not Julia the language

To be fair, points 1,2, and 4 are regarding the ecosystem, not the language. There are definitely rough edges, but one can not expect a fully mature ecosystem only a few months after 1.0 has been released.

For a streamlined workflow, I recommend Emacs + Revise.jl. I just edit my code in an Emacs buffer, and the Revise automatically updates the REPL to reflect the source. This makes the code feel tangible, more than any other language I have experienced.

> We're just about due for another doomed effort!

It seems Google will take a shot at it: https://en.wikipedia.org/wiki/Google_Fuchsia

Drug scheduling is a joke. Schedule I is defined: "Substances in this schedule have no currently accepted medical use in the United States, a lack of accepted safety for use under medical supervision, and a high potential for abuse."

How do alcohol and cigarettes not fit this definition!? Meanwhile, edible cannabis is relatively safe and Ecstacy has shown promise as a component of PTSD treatment. Just a few examples...

Link to the interview?

I think the lack of information (conversely, the increase in noise) is what is being downvoted. It is possible, although much more difficult, to be both funny and informative.

That being said, it cracks me up when people get downvoted so heavily for jokes!

I want to learn, can you elaborate?

The security of the product is the responsibility of the vendors. If they want to control how exploits are handled, then they should compensate security researchers for that service, just like anything else. The poster of the exploit outlined some reasonable steps to that end.

I'm no security expert, but the feeling I get from other discussions is that big players have acted dishonestly with regards to proper compensation of bug bounties. It seems that sad state of affairs is being protested.

I think the inverse argument can be made against shared libraries: if an update introduces a vulnerability, now all programs which depend on that library become vulnerable.

Thanks for your work. I have been wanting a tool like this. It really appreciate the design; both in terms of functionality and aesthetics.