Hacker Newsnew | past | comments | ask | show | jobs | submit | martindevans's commentslogin

In my experience with running Discord servers you setup a couple of hierarchical roles (admin, moderator, user etc) when you first setup the server and never again.

However I'm constantly adding new roles which are really just groups of users. I would say 90% of all the Discord roles I've ever created have no permissions associated with them at all and just exist to ping a group of users (or act as a tag for bots).

Maybe that's served by a different feature in Matrix for user groups. If so, that's still not quite as useful, because sometimes later on you decide the group needs a permission (e.g. a casual gaming group has grown enough to justify having it's own channel).


Right - this matches my hunch; that folks want to define groups of users (which you can already in Matrix in 'spaces', but the UX in most clients is awful) - and what they really want is group-based permissions (which isn't part of the protocol, and instead gets layered on at the application layer today.

So the problem here isn't that folks want contradictory access levels (e.g. Admins can kick people but can't set topic, but Mods can kick people but can't set topic) but the ability to set them via group?


C# can compile standalone binaries for multiple platforms.


> Edit-and-continue comes to mind, which despite how many times people confuse the two is not hot reload

I'm certainly guilty of this! What's the difference?


I’m simplifying this for brevity but: Hot reload is a concept whereby changes will be saved, if necessary compiled (in the case of compiled/JIT-ed languages), then whatever is pointing at the original source is run again automatically (a web page/an app screen/whatever).

Edit-and-continue allows for changing the code and then updating the output directly in memory without re-compilation or restarting the execution. It sounds similar but in practice it allows for much more rapid iteration and is profoundly more useful. If you’re pretty deep into an application or web app for example (e.g. added to basket -> checkout -> process payment) and are 30 or 40 calls deep in a stack and realise you’ve a simple bug or change to make, you can edit the code in memory, drag the debugger back to the line, re-execute it and move to the next statement. The benefits of this compound really quickly for anything more than trivial scenarios, so much so that I’ll often code directly in a debugging session as it’s just handier to have a full rewindable call stack right there for simple cases where I’ve forgotten a property name or need to correct and XPath or something.

The surprising thing is that this isn’t even new, VS has had this for at least 20 years (and I think 25 or more as i know VB6 had it. Yes I’m old.)

Edit: 27 years ago in VC++5 (1997).


From your description it sounds like in-memory application state is lost with Hot Reload, but I don't think that's true? I admit might be wrong about this, it doesn't apply to Unity which is my main development environment.

Quoting from the docs (emphasis mine): > .NET Hot Reload applies code changes, including changes to stylesheets, to a running app without restarting the app and *without losing app state*

That sounds more like how you described edit-and-continue to me.


No, they spent billions on a model and released the weights, and that's fantastic! It's not not open source though.


There was a "green thread" experiment for dotnet a while ago, here is the conclusion: https://github.com/dotnet/runtimelab/issues/2398


Yeah, I saw that some time ago. Their conclusion is basically: "it's hard to integrate with the current ecosystem so we're giving up".


He doesn’t want to read all the research text, especially if it debunks his assertions. Your effort, although appreciated, is wasted on this kind of person.


I've read it. It was not impressive. They prioritized backwards compatibility which is of course their prerogative.

But that's not how you progress.

Having proper M:N parallel runtime is mandatory these days and it baffles me that there people who are still not sold on it. I take it they have jobs and tasks where it isn't necessary but it's an interesting question to ask: for how long?


Isn't there effectively a multi-billion dollar bounty on finding out who Satoshi is and deploying a bit of "Rubber-hose cryptanalysis"?


All three good candidates for Satoshi are beyond said cryptanalysis: Sassaman and Finney are dead, Paul Le Roux is in a federal prison and it is not known to the public where, even without Bitcoins, quite a few people want him dead so the feds are not going to make it easy to get access to him.


Early in the development of the Saturn-V they had issues with thrust instability in the F1 engine (in the worst cases causing it to explode). They had trouble diagnosing the issue (and blew up some engines) before they came up with the idea of setting off a small bomb inside the engine to trigger instability on demand (destroying some more engines).

Do you consider that a failure of the Saturn-V program? Or do you understand the value of testing prototype hardware to destruction?


Less time spent not firing engines, no need for separation hardware (e.g. hydraulic pushers), no need for ullage thrusters (settling fuel before lighting stage 2).


There used to be .NET Framework (which was a Windows only runtime built by Microsoft) and Mono (an open source implementation for various other platforms).

In 2016 they started building .NET Core which is new open source implementation (built mostly by Microsoft) which runs on more platforms. For a while all three existed side by side.

Eventually .NET Core caught up and overtook the other implementations. These days Framework is legacy. Core has been renamed to just .NET (since it's now _the_ runtime) and Mono (as far as I know) has been totally replaced by it.

This is all from memory, so apologies for any inaccuracies!


While correct, modern .NET supports currently two VM: CoreCLR and MonoVM. The later mainly as AOT compilation target for iOS, Android and WebAssembly. Mono is still better suited for that, but the AOT compilation of CoreCLR is progressing.

I think there is nothing else left from the Mono project like the class library or the compiler/toolchain.


Actually, .NET Framework is the Python 2 of the .NET world, with all the references that it entails.

Still too many enterprise products stuck in the old ways.


Unlike with python, some things simply can't be ported, though. I maintain a webforms page, the only upgrade path would be a full rewrite


Python 2 => 3 also has the issue that some things don't exist in Python 3, or are done in incompatible ways.

As I mentioned a few times, I have been involved in projects were that full rewrite happened to be .NET Framework => Java, which shows how the customers were mad at what was left behind.

Although there is some irony in that, as Java's Python 2 problem is the transition into Java 9.


> as Java's Python 2 problem is the transition into Java 9

Binary incompatibility between 7 and 8 as well, we got an enterprise product that got bought by SAP and will eternally be stuck on Java 7, but at least unlike the other one, it doesn’t require much maintenance as it’s only used internally ;)

> Python 2 => 3 also has the issue that some things don't exist in Python 3, or are done in incompatible ways.

What doesn’t exist? I don’t like python, but it always seemed like those changes were all relatively minor?


The way unicode was handled, integer division semantics, some libraries went away, and a few other things change enough that 2to3 wouldn't handle everything, which in a dynamic language is a big pain to track down in a huge codebase.

Naturally some changes on the C API for native libraries as well.


Fair enough, thought that still sounds like things where an upgrade path is available, just not automatically, instead of "you have to throw the code away because it simply doesn’t work anymore".


It's a good job that this planet doesn't have 8 billion unaligned intelligences on it. Someone might prompt them to be malicious!


Well, (so far) there's an upper bound on how destructive one of those agi's can be.


I don't know if that's entirely true. Wtf do I know and maybe it is genuinely difficult to start WWIII but my guess is that it's more likely that the AGIs in question are actually pretty well steered by certain motivations which prevent them from actually destroying the world. At the end of the day there's not much to be gained by nuclear war, but could a single person cause such a war if highly motivated to? Probably?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: