Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save zacharycarter/3f41b5da315df1d0e1d14036808ee25d to your computer and use it in GitHub Desktop.
Save zacharycarter/3f41b5da315df1d0e1d14036808ee25d to your computer and use it in GitHub Desktop.
Zach Carter [1:59 PM]
reading through this now - https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ - but the author starts out making a pretty bold assertion
```In this post, I want to convince you that nurseries aren't quirky or idiosyncratic at all, but rather a new control flow primitive that's just as fundamental as for loops or function calls. And furthermore, the other approaches we saw above – thread spawning and callback registration – should be removed entirely and replaced with nurseries.```
He's talking about two different modes of concurrency here - thread spawning and callbacks
and saying we should ditch both traditional methods in favor of this new construct
Cory Simpson [2:02 PM]
Yeah i read that article, you can’t get away from threads its in the cpu instruction, you can hide them and manage them but something has to spawn threads
Zach Carter [2:06 PM]
yeah - I haven't read through the entire thing yet and I mean I don't think you can just replace one computer primitive with another like you mentioned
Ian McLeod [2:06 PM]
* considered harmful in the article title
instant red flag
Zach Carter [2:06 PM]
but if he's offering some type of reusable pattern / way of managing these primitives that is logical and works out better than what we have currently
I'm all ears
multithreading is a bear
especially in C/C++
or really in any lower level language typically
it's even painful in higher level languages like Java
and I think multithreading should be a last resort anyway - only when you really have a problem that multithreading solves should you use it
otherwise it's just adding complexity
Cody Keeling [2:10 PM]
lol
Ian McLeod [2:10 PM]
hot take: multithreading should be low level
Zach Carter [2:10 PM]
well it has to be
but this article really isn't talking about multithreading it's talking about concurrency which inherently relies on mulitthreading
Jai Hirsch [2:11 PM]
https://wiki.theory.org/index.php/YourLanguageSucks
Zach Carter [2:11 PM]
thank goodness Nim isn't on that list
:stuck_out_tongue:
Sasha Vasko [2:12 PM]
I rarely use threads, my friend, but when I do I code it in Assembler
Ian McLeod [2:12 PM]
i prefer straight posix ipc
and writing custom allocators so i can use STL in shared memory
*has horrible flashbacks of high performance computing course*
Zach Carter [2:13 PM]
well - often times the STL allocators aren't suited for certain tasks
in C++
especially when you're writing simulations that need to be high performant
Jai Hirsch [2:14 PM]
LOLCODE is not on the sucky language list either https://en.wikipedia.org/wiki/LOLCODE
Wikipedia
LOLCODE
LOLCODE is an esoteric programming language inspired by lolspeak, the language expressed in examples of the lolcat Internet meme. The language was created in 2007 by Adam Lindsay, researcher at the Computing Department of Lancaster University.
The language is not clearly defined in terms of operator priorities and correct syntax, but several functioning interpreters and compilers exist. One interpretation of the language has been proven Turing-complete.
https://upload.wikimedia.org/wikipedia/commons/0/02/LOLCode_logo.png
Zach Carter [2:14 PM]
that's why when a lot of game companies write their own engine they re-define a lot of STL stuff
yeah but it's also an esoteric programming language
Sasha Vasko [2:14 PM]
garbadge collection sucks!
Zach Carter [2:14 PM]
brainfuck isn't on there either
well garbage collection can suck in certain scenarios
there's also all different types of garbage collection
and there are alternatives to garbage collection for memory management
that aren't manual
Joe Bradish [2:15 PM]
if your language isnt on the your language sucks list yet, your language is esoteric :kappa:
Zach Carter [2:15 PM]
no not really
Common Lisp isn't on there
or lisp at all
I don't think common lisp or lisps can be considered esoteric
or scheme
I think that list is just poorly defined
Joe Bradish [2:16 PM]
(it was a joke)
Zach Carter [2:16 PM]
meh
more like - if your language doesn't have corporate backing - it's not on that list :stuck_out_tongue:
Joe Bradish [2:16 PM]
forgot we cant joke about nim
its sacred
Zach Carter [2:16 PM]
you can - it just sounded like more of a dig than a joke
I don't think anyone in the Nim world can control it's popularity - or at least no one has any direct control of it unfortunately
Joe Bradish [2:17 PM]
sure, but theres some truth to the fact that nim has a small market share, like many of the other languages missing
Zach Carter [2:17 PM]
it does for sure
I don't know if Nims goal is to achieve a wide market share either - I was bringing this up the other night in the nim irc channel
saying like - if Nim wants to gain wider adoption - libraries need to be written for enterprise tech
tech that Nim users aren't traditionally using / have use cases for
and there was some push back that Nim is fine in its problem domains - it doesn't need to become a langauge that's used everywhere for everything - and that it really shines where it shines currently and will continue to develop
also it's apparently edging very close to a 1.0 candidate - apparently the release is imminent although that could still mean months to a year - I don't know - I'm not a core dev.
but like - if I wanted to write native code right now for the enterprise - I don't think Nim would be a viable choice
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment