Brave does (did?) not allow creators to opt-out of donation collection and by default opts them in. This means you as a user may think you are donating to your favorite creator but in fact Brave is just holding on to the money.
> Publishers must verify ownership of their properties with Brave in order to receive contributions from Brave users. If a publisher has not verified ownership, then a user’s contributions will be held in reserve inside the browser for 90 days. The browser routinely updates an internal list of all verified publishers to determine whether a property can receive contributions. At the end of the 90 day period, any contributions marked for unverified publishers will be released back to the wallet. No funds leave the browser except to go to verified creators.
Nothing per se against repl.it, but I'm surprised to see this on #1 of the front page as it's basically a call to free labour.
Will there ever be a future when companies innovate themselves again?
IMHO all these "hackathons" or "jams" are really just about finding use cases for their product and getting it tested for a very affordable reward ...
Repl.it is an amazing idea, but it's infuriating to use. No syntax highlighting in the REPL, laaaaaag everywhere, hardly any version control… It's useful for performing a 30 second Python interaction on machines without Python installed, but that 30 seconds becomes 3 minutes because Repl.it is so clunky.
I tried to log in to check whether things had improved, but apparently I need Google's permission to do so now? And, in fact, nothing will run without allowing Google's JavaScript, even once I've logged in.
Anyway, version control is there now, and you can edit existing Git repos! Except it's actually GitHub, not Git, so I can't use it for any of my existing projects, including my programming language…
That being said, I think the world is better with Repl.it in it. It's not like these other things I criticise where I think we're better off without them; Repl.it's flaws are infuriating because they're stopping me from appreciating something potentially great.
> Repl.it is an amazing idea, but it's infuriating to use. No syntax highlighting in the REPL, laaaaaag everywhere, hardly any version control… It's useful for performing a 30 second Python interaction on machines without Python installed, but that 30 seconds becomes 3 minutes because Repl.it is so clunky.
We've improved performance a lot and we'll keep working on it. I just timed it and it took me 5 seconds to start a new Python repl and execute code :)
> I tried to log in to check whether things had improved, but apparently I need Google's permission to do so now? And, in fact, nothing will run without allowing Google's JavaScript, even once I've logged in.
What do you mean by this? You can log-in via Google but that's about it.
> That being said, I think the world is better with Repl.it in it. It's not like these other things I criticise where I think we're better off without them; Repl.it's flaws are infuriating because they're stopping me from appreciating something potentially great.
Thanks we're always happy to hear feedback, negative more important than positive. I'd invite you or anyone who loves Repl.it but find it to be lacking to apply to work with us https://repl.it/jobs
Correct. It's a known issue that all of two people (including me) have ever run across! https://repl.it/feedback/p/make-replit-work-without-google (In reality, the people who submit feedback are a very skewed representation of the population-at-large, so there might actually be three people who've encountered this issue.)
I'm more interested in your response to the paragraph you conspicuously skipped:
> Anyway, version control is there now, and you can edit existing Git repos! Except it's actually GitHub, not Git, so I can't use it for any of my existing projects, including my programming language…
Repl.it is set of automation and UI tools that makes it easy for beginners learn to code and for developers to test or prototype projects.
Any feature that's implemented in the UI is implemented as abstraction over things you can do by opening the shell. Because we are a small team that prizes simplicity over completeness, and because GH is the most popular we just made that the default.
But you can open the shell (command/cntrl+k and type "shell") then use git to your hearts desire :)
We'll probably add native GitLab or whatever others want in the future. You can always leave feedback here and tell us what you want: https://repl.it/feedback
That's excellent to hear! Perhaps I can use it, after all – just as soon as I figure out how to add SSH keys to git, anyway.
I last used Repl.it so long ago, I didn't know that there was a shell. (Which is odd, since I read about how you can technically use arbitrary programming languages by installing them via the shell just a few hours ago…)
Leaving feedback now. (Fortunately, you don't need Google to do that, so I don't need to mess with my browser again.)
OK, that sounds a bit better, but what is both simplest to implement, most generic, and most useful is supporting _Git_, not some half-baked forge site APIs.
It's all actually git. And you can start a local repo without calli g to GitHub. You can just use it in half the time it takes to have this discussion.
We make all of our money from the education market through our classroom products and believe me teachers don't need more languages to teach nor in a hundred years will they teach a hobbyist language.
So I invite you to provide a compelling case for how this is a call for free labour.
I wouldn't say this is a call to free labor. It would be if you were asked to port an existing unsupported language to repl.it (which is how I read it at first). However, this is a contest to reward building your own totally new language (which presumably you were going to do anyways) at least, for some segment of time, on repl.it. I suppose it could be seen as debugging repl.it for free, because this endeavor is likely to break repl.it in so many unforseeable ways.
Fingerprint scanners are legacy tech. The cool kids now are using palm vein scanners - great CER and non-contact, you just hover your hand an inch above.
The problem is convenience. I have to press the elevator button every day. After I disinfect my hand for the 5th time that day I use the stairs. Same with the fingerprint scanner.
Is it just me or is this happening more and more often recently, i.e. since Microsoft acquired GitHub?
It's also very shady that they don't even seem to detect these incidents properly.
Fitting analogy: If there's an article about McDonald's, people would always talk about Wendy's instead. No one would mention BurgerKing (C++), Subway (D), KFC, ...
The thing is, most discussions about Go are about adding features Rust has or making changes where Rust has something relevant to say.
I chose my analogy carefully. Coca-Cola tried to change its recipe to make it sweeter because they did studies and found people liked the taste of Pepsi more. So any discussion of changing Coke's flavor means Pepsi is highly relevant. But the converse is not necessarily true. Pepsi doesn't have any (recent) history of trying to match their flavor to Coke.
Maybe a better analogy is this: if Mercedes comes out with an electric car, you should expect to see Tesla in the discussions. But if Tesla comes out with a combustion engine, there's nothing particularly relevant about Mercedes in that discussion.
I'm sure that if there were discussions about adding structural typing or lightweight fibers to Rust, then Go would show up. But most of the discussions tend to be around adding generics or sum types to Go.
I wouldn’t say that I’m obsessed with Rust. However, it’s the sort of language I’ve wanted essentially since I started programming: a Haskell/OCaml-like language with the sheer performance and practicality of C++.
I’ve been a long-time user of Haskell, but I can safely say Rust has supplanted it almost entirely for me at this point. I never would have felt comfortable betting on Haskell in a commercial environment. Rust? Absolutely.
Can you expand on why you would not bet on Haskell for commercial work? What are those things that make Rust suitable for it but not Haskell in your opinion?
This is cool to hear. I've been interested in Haskell/OCaml to learn functional programming. Rust has other cool applications like WebAssembly too. I think I'll start learning it after I learn Clojure (trying to get into functional stuff first with Lisp).
Everybody that talks about rust is talking from a different perspective with different values. What makes rust different from other languages is the breadth of use cases for which rust is a candidate worth mentioning. That's not so much an obsession as it is an availability bias on your part. You're seeing different people talk about rust obsessively in different contexts and assuming that those same people talk about rust in all contexts.
If any of these features is of significant value to a programming use case, it is worth talking about rust:
* Speed
* Type safety
* Memory safety
* Memory determinism
* Latency
* RAII-based resource acquisition and destruction
* Concurrency correctness / safety
* Minimal runtime requirements
* Low level bit manipulation (eg. Cryptography, compression)
* Startup time
* Networking
This isn't exhaustive, but it gives a lot of different people in different domains working on different problems a reason to talk about the same language when comparing to their usual choices.
I don’t know if this explains the entirety of the phenomenon but I do think this post helped me understand at least a portion of the pervasive mention of rust in almost any programming conversation on HN, which makes the fact that happens slightly less frustrating.
You do realize that the lack of generics in go pushed a lot of go programmers towards rust, right? This feature of go is long overdue, and many people gave up on trying to get them implemented. The fact that they are now available has many programmers wondering if it is even worth switching back.
That is context for discussion, and yes, it is relevant. Directly relevant, in fact.
I get that. And that's a great discussion for the Rust community to have.
I wanted to hear what Go devs have to say about this latest iteration of the generics proposal. But to do that I have to wade through endless comments about type systems and Rust. Even on comments directly talking about this iteration and how to use it, every other reply starts with "In Rust..."
If implementing generics leads more of the Rust community back to Go, then from what I've seen here: no thanks. I have a feeling we'd see every conversation in every community forum start with "In Rust.."
> I get that. And that's a great discussion for the Rust community to have.
It's also a great discussion for the go community to have. The only problem here is that it's not a discussion you wanted to have. Should every discussion about go revolve around you and your wants?
If all you wanted was to hear what the go devs wanted to say, you could have clicked on the link and read it. Or could you possibly use the feature that was built for you: the [-] button to collapse a thread. Or maybe, just maybe, you could go to a place that is explicitly only about go, like /r/golang.
I'd be totally cool if it was this once, and actually interested.
But it's every freaking time. Every single time Go is mentioned, there's a ton of Rust folk commenting on how Rust does it (better).
Just for once, it'd be nice to have a comment thread discussing a Go-specific item, that has nothing to do with Rust, without talking about Rust.
And yeah, /r/golang is at least Go-focused. But it has its own problems too. Mostly PHP and JS folks learning Go and asking basic questions (which would be great if they didn't then reply to the answers with "but that's not how PHP/JS does it, why does Go do it so strangely?" and without reading any of the billion answers for that question already).
No I do not realize that at all. It's like saying "Lot of Americans will renounced their citizenship if Trump won" Yes a lot of people said that but I am not sure if there is data to conclusively say it happened in either case.
The only cases I know of are people moved to Rust to avoid GC pauses.
