Andrew Андрей Листочкин

less info
1,044 reputation
710
bio website
location Kiev, Ukraine
age
visits member for 3 years, 9 months
seen Jun 18 at 22:10

Me elsewhere:


Sep
21
awarded  Yearling
Jun
19
awarded  Nice Answer
Feb
20
awarded  Caucus
Sep
21
awarded  Yearling
Jun
26
awarded  Nice Answer
Jun
8
awarded  Constituent
Jun
8
awarded  Caucus
Jun
8
awarded  Caucus
May
11
answered How can I evaluate a candidate's knowledge of Html/CSS during an interview?
May
8
answered The Box Model: Internet Explorer vs. W3C
Dec
2
awarded  Necromancer
Oct
8
answered What are the pros and cons of Coffeescript?
Sep
22
awarded  Yearling
Sep
19
comment Why is the 'final' keyword used so little in the industry?
Yeah, I know that and I actually write some ML code from time to time - that's where I got my inspiration from :) It's not about the language that you use but rather about the principles and techniques you apply. One can go all imperative with Haskell and do notation :) Sure, Java isn't the best language for writing in functional style but at least it allows you to write robust code -and that's what I really care about.
Sep
15
answered Why is the 'final' keyword used so little in the industry?
Sep
13
awarded  Enlightened
Sep
13
awarded  Nice Answer
Jul
10
comment The Future of Golang. Multiple Language Support?
I don't think it will increase the cost. Like I said on the implementation level these per-goroutine heaps can be just regions of common heap. If that's the case heap allocations for goroutines are completely isolated form memory allocation from the OS by Go runtime. Thus they can be really-really cheap. Also, I doubt that goroutines as they are used today (i.e. small bits of code that are executed asynchronously and terminate really fast) would require large heaps allocated to them? at least initially. A small chunk of memory, say 1k or less, would work just fine.
Jul
10
comment The Future of Golang. Multiple Language Support?
@dan_waterworth I doubt I have any sources. Moreover, I'm pretty sure that that's not the case right now because Go has a very basic GC at the moment. Nevertheless, it's very likely that Go will get to heap-per-thread in future because that's the only way to have a GC without stop-the-world pauses. Unlike Java or .NET all communication between threads in Go happens through channels. They effectively isolate heap space into dedicated per-thread sections. It's only a matter of time when Go's GS will run for individual sections.
Jul
8
comment The Future of Golang. Multiple Language Support?
@Jörg Wow, that's pretty cool!