Does anyone seriously think that the difficulty with parallelizing code is the amount of boilerplate? The real problem is synchronizing multiple threads; being too lenient means deadlocks; being too strict means under utilization. The map() function doesn't really help with either of those.
In addition, it looks like you are unfairly picking on Java. The producer consumer model presented isn't anywhere near what a competent programmer would do. Building your consumer from within a method called Producer? Calling isinstance (or instanceof) to check if the "poison pill" is put in the queue? These are the signs of a crappy programmer, not a crappy language.
If you do a lot of data munging, then boilerplate is definitely an annoying obstacle. Plenty of problems are "embarrassingly parallel", and the map function may be fine for those cases.
I wasn't trying to solve the problem of parallel processing, nor was I suggesting that its core problem is boilerplate. The point of the article was simply trying to show a part of the language that I think is neat and elegant to people who may not be familiar with it. As I mention in the opening paragraph, the top tutorial hits on Google make no mention of the map function.
Secondly, I wasn't really "picking" on Java. A one line comment about Java liking classes is pretty far from being "unfair," me thinks. Again, in the context of the article, I was simply (attempting (though may have failed)) to use it as a (hopefully mild-chuckle worthy) example of the different ways things can be done in a language.
Finally, I'm not entirely sure why your complaining about stripped down example code... It's example code, man.
What happens when you have to deal with a crazy pop star with a " in his (real, legal, you-are-the-unreasonable-one-for-demanding-something-else) name? (This is ignoring the myriad of issues that come with parameterizing names into "first name" and "last name" in the first place, but that's a separate thing.)
This is what binding variables is for, but to use them you're either writing for specific platforms (PSQL, Oracle SQL, etc), or you're using middleware that hides the raw SQL from you.
This is a problem with the string domain, not with SQL. You'd have it no matter what data persistence method you use. The answer is to put logic between that function and your form data puller.
If you were to say "programming languages today are deficient in X, Myrddin fixes that!", what would X be? From the looks of it, it appears to be nothing. The syntax looks palatable and I like the lack of header files. That said, why would I be better off investing the time to learn your new language? (amongst the myriad other languages)
Assuming that the creator meets his goal to reach C-level performance, C has exactly no item present on the list of Myrddin's major features. If you are programming in a higher-level language, you get performance (again, assuming it's actually fast), and "lightweight" static typing, if you don't have that already. If you're programming in Rust, switching to Myrddin is more debatable (I don't know about D or other languages competing in the same space).
If you're programming in Rust, and you care about things working, you probably want to stay with Rust at this point.
I'd love to get people actually playing with Myrddin, but remember the joke I made on the page about broken compilers, miniscule standard libraries, and debugging in assembly? That wasn't a joke.
Play, but unless you're sure of what you're doing, don't depend on it actually working. Not yet, at least, although it's getting there.
As far as performance goes -- I've put zero effort into optimizing, and depending on the style and features you use, you tend to get between 2x (for purely numerical code) and 8x (for heavily union-using code with value semantics) overhead compared to C right now. Some basic optimizations should bring that down really quickly.
The "I'm doing this and I don't give a damn about you" attitude I think has at least some merit. If the lead programmer is good, its better if he/she can say no. If there is a correlation between being an asshole and being successful I haven't seen it.
Cox does something similar but bypasses the the DNS records and just slipstreams in a response. I noticed Cox would redirect javascript requests to their own HTTP server and put in their own snippets, effectively doing mass javascript injection.
The snippet ended up being some sort of alert about upcoming maintenance, but using a malicious technique for a benign purpose is the path to the dark side. Use HTTPS!
100 and 120, at least in my brief experience. Coworkers start expecting 100% output from you, which means you are going to get a lesser review for putting out 80%. That they don't let you do 20% in the first 6 months there is what makes it so hard to start it back up.
This is hackable if you're strategic about it. The trick is to always make sure your coworkers are unblocked. If someone needs a code review, do it before your regular work. If someone's waiting on an e-mail response from you, send it first. If someone needs your CL to be in before they can proceed, make sure you get it in.
Then once everybody is unblocked, your time is yours. On a well-functioning team you still need to pick things up on your own initiative (eg. fix bugs, volunteer to take on new features), but in general you can do just enough to show activity, and don't need to worry about always being the best on the team. So that's your chance to do 20% work, or play with other technologies, or investigate other areas of Google.
Another tricky bit is making time for professional development and advancement, and the way to do this is to take advantage of the 6 month review cycle. Make sure you can demonstrate tangible accomplishments in the 1-2 months leading up to a review, then spend a couple months assimilating the big picture and learning the skills you need to get known as an expert on the team, and then use your newfound knowledge to improve the effectiveness of the team.
What people look for come perf time is "Does this person make my job easier, or harder?" As long as the answer for them is "easier", you'll get good reviews. That doesn't necessarily mean working flat out all the time, it means being mindful of the people around you and what they're hoping to accomplish and then making sure your actions are a help and not a hindrance.
I thought the segmented stack was the key to having hundreds of thousands of userland threads. It seems pretty farfetched (though not impossible) that realloc'ing the entire thread stack when it gets too big.
I think Go is primarily designed for servers and servers are overwhelmingly 64bit these days. In a 64bit virtual address space, you can have millions of contiguous stacks each of gigabytes size.
Not really. Assuming that page size is 4KB, and given that for most systems, the minimal amount of memory that can be committed is a page, you will exhaust all 4GB of your server's physical RAM with only 1 100 000 threads.
I don't think many real servers have 4 GB these days. The dev box under my desk has 32. Linux servers often have 1 TB of physical memory. So based on your calculation that's 256 million threads. Sounds enough :)
The whole point of a cheap concurrency like goroutines is the ability to avoid using callback based async IO (i.e. the go standard libraries perform select/epoll/... under the hood but your code behaves like if it was blocking on IO).
You might have better use of your memory (caching, in memory databases) than wasting it for even a fraction of a million of routines that are just waiting for something to happen.
Yes, but if I buy a server with e.g. 128 GB of RAM, I would preferably spend it to cache 100GB of live data and searchable indices, and not worry when I will spawn too many threads so that I will start trashing the swap.
That's true, but the majority of those 64-bit servers only have a 48-bit address space to millions of gigabyte-sized stacks would still be a tight fit.
Obviously it would be a "virtual" gigabyte-size stack. I.e. it would be mmapped, but all the threads would not actually be using all their stack. Physical memory is not allocated, but virtual addresses are.
Not entirely, as I understand it. Segmented stacks is just one solution. Another is to start with a very small stack, and grow it contiguously (copying to a new location if necessary) when an overflow is imminent. You still get the benefit of having small stacks, which lets you make those 100ks of userland threads, and as long as they don't blow up their stack usage (same requirement as for segmented stacks), they'll be fine.
True, but most of all we value working in the open so that we can both do user testing and find people who might want to contribute. In my book our mistake was not to prioritze issues 306 and 386 until we showed up on HN. Oh well!
Can I suggest not using alpha/beta - they are labels used to indicate the state of a proprietary project - how "polished" it is - whereas you are continuously exploring. if you must I suggest using a target audience - contributors, early adopters. etc etc
Its deeply troublesome when these kinds of comments come up for two reasons: first and lesser: its wrong; secondly: its inconspicuously wrong. Processor speeds double approximately every generation which we can estimate is once every two years.
What do we have to count to:
2^128 = 3.402823669209385e+38
How many times can we count in a year with a 3GHz core:
3e9 * 3600 * 24 * 365.24 = 9.4670208e+16
In two years, when processing speeds have doubled?
9.4670208e+16 * 2 = 1.89340416e+17
How many years until a core can complete count to 2^128 in a year?
log(3.4028e+38 / 9.467e+16) / log(2) * 2 = 143.21
So, in 143 years a single computer will be able to count to 2^128 in a single year. That's still a long time, but its WAY WAY less than the trillions of years people quote. Add in as many extra cores/machines/datacenters/planets of extra processors and you aren't really indefinitely secure. You are secure for a limited number of years and that's it.
The Landauer limit [1] is relevant here. Even if you could theoretically make a processor that does it, it would take about 30 gigawatts of power for 1 year [2] to just do 2^128 bit flips (this is obviously a lower bound since it disregards the additional energy required to actually do the calculation). This is more than 1/100th of the world's current energy production. So it's not something that is going to be a concern for most people, and certainly not in the near future!
If the world had access to that kind of energy, I'm sure it'd be used for far more interesting things than finding a single hash collision.
Edit: and while we're on the subject of inappropriately extrapolating Moore's law, if current performance-per-watt continues to double every 18 months I'd be interested in how long it'd take to even reach the Landauer limit. I can't seem to find out how much energy it takes to do a single bit flip in a modern processor online, so I can't do the calculation.
People just assume exponential growth goes on forever. You're giving a counter argument to moores law. Moore's law is not physical law, and physical law says otherwise here.
The amount of energy needed to update a counter 2^128 times on a non-reversible computer with the highest efficiency permitted by understood physics requires the energetic equivalent of something like 2 megatonns of TNT.
The additional state that brings security against brute force preimage attacks also tends to increase security against analytical attacks, as well as speculative QC attacks. So it's not worthless, at all— but your moore's law argument is not credible.
> Processor speeds double approximately every generation which we can estimate is once every two years.
Do you have any sources to back up this claim? Max processor speed has stalled to ~4GHz since 2005. If you're referring to Moore's law, it concerns the amount of transistors in ICs, and will eventually hit a limit (not before 10 years, but not after 140 years).
In addition, it looks like you are unfairly picking on Java. The producer consumer model presented isn't anywhere near what a competent programmer would do. Building your consumer from within a method called Producer? Calling isinstance (or instanceof) to check if the "poison pill" is put in the queue? These are the signs of a crappy programmer, not a crappy language.