Exactly why IMHO the rust stdlib is so easy to understand. Ownership only when required as a design principle tends to make the design of the overall system more consistent / easier to approach.
I was involved with the London esports scene from 2010 to 2014, running events that would gather up to 500 people for blizzard and valve games.
I left the scene because I could not morally justify the exploitation of the majority of the talent. I hoped that the younger guys would be finding a way to make it work for the majority but it still irks me how many years have been wasted by young adults on a wild goose chase. Some very few were able to make a living out of it and deserve 100% what they pulled, but man, what a churn in that industry.
Devastated that TB / Odee didn't get to manifest a vision for player's union. That would have made a difference.
Hi, do you know if there's a recent hash benchmark I can look into? I am using `FnvHash` as my go-to non-crypto-secure hash for performance reason, didn't realise there could be faster contenders.
you might want to particularly look into murmur, spooky, and metrohash. I'm not exactly sure of what the tradeoffs involved are, or what your need is, but that site should serve as a good starting point at least.
I wholeheartedly agree - I am working on a very technical new build at the moment and cannot listen to music when coding for it, but when I switch to maintaining stuff, I reach-out for my headphones.
How would it be possible to allay your concerns? I think we've tried to be as clear as possible with our intentions - how could we rule out such possibilities with our license agreement?
Sadly, I’ve been bitten by this before, too, and even if I love the product, I stay away.
It isn’t that I don’t trust you or your intentions now, it’s that intentions (and requirements) change.
You asked about allaying fears. Personally for me this means actually take-to-the-bank licensing that I could get through a legal audit, even if hypothetical.
Talk of “secret sauce” and future closed source and IP licensing of future maybe-must-have magic... that’s way too much future risk for me.
An example of what I think is good licensing is JUCE (https://juce.com). Everything from “free” to “paid with support”, all open source… but the point is I always know exactly where I stand legally, what I can and cannot do... and what I can and cannot do in the FUTURE.
Well, as the person who also created JUCE and its license, I can't really argue with that. :)
We're very keen to make sure that the end-user developers are totally unencumbered and license-free, because we want lots of people to adopt it.
All our licensing is more aimed at device and driver builders - think of it like e.g. openGL - the industry making GL cards and drivers is legal complex, but none of that stuff affects the coders writing GL apps.
The license is pretty clear, you can do anything you like with the language and the software that has been open sourced. If you want to write your own renderer, that's great! If you want to write a decent interpreter, or a rubbish one for that matter, again, that's great, that's your business.
Disclaimer: *I'm not your target audience*; I don't plan to use your product even if you made it public domain.
I never want to agree to an EULA before starting to develop something outside of a professional setting. That's an immediate dealbreaker for me. But even if I did - I wouldn't be able to disassemble or reverse engineer your software (2.2)? Also - why are there so many clauses in the EULA telling me to obey really specific laws? Aren't these redundant to section 2?
- end-user developers. This is kind of like being a user of any other language, there's no EULA, nothing to sign, you just write SOUL code, test and debug it with whatever tools (which may themselves have a EULA, but probably nothing heavy)
- device and host developers: These are the people writing DAWs, plugins, hardware that can run SOUL code, audio device drivers etc. These are professionals, and licensing is a normal part of life when you're doing this kind of work.
sigh... The JIT engine in your graphics driver stack will contain millions of lines of heavily-licensed, patent-riddled code.
But that doesn't stop you as a developer from freely writing a 3D game that runs on it.
Same here. Think of it as a device driver. Ideally we'll open-source everything eventually, but anyone who's ever been involved in real-world commercial software development will understand that things aren't always quite that idyllic when you're building a business around it.
If there's no mechanism to bind those intentions to the intellectual property, what you're building is just another time bomb which will eventually detonate at the expense of your users.
Real answer: Mainly the JIT engine, and the very complex rewriting algorithms that turn multi-threaded soul code into a form that can actually be executed.
We're certainly keen to open-source everything when possible, just been advised by our lawyers not to do that yet. C'est la vie.
Hey some of us like the clicky-clack! I optimize around the most common use case, which is me, at home, in my home office. This predates the pandemic and I fully intend it to postdate it as well.
I don't mind a little Foley on a call; I'm either muted anyway, or it doesn't matter. There must be people out there who can type and talk at the same time, but I never got the hang of it.
Topre is indeed great. The HHKB Pro 2/3 makes an excellent office/WFH board because it's tactile while being relatively silent. Feels nice to use without making a ton of noise.
