|
You pronounce your name like the hockey player, right?
|
#
?
Nov 8, 2013 19:05
|
|
|
|
| # ? Apr 28, 2024 18:33 |
|
|
Otto Skorzeny posted:You pronounce your name like the hockey player, right? Hay-Bear, more or less. No idea how announcers around your place pronounced Guy Hebert's name (I'm guessing that's the one you had in mind?) (eˈbɛʁ)
|
|
#
?
Nov 8, 2013 19:06
|
|
|
MononcQc posted:Yeah, I'm speaking there: http://www.erlang-factory.com/conference/Toronto2013/speakers/FredHebert I don't know how much I'd get out of it if I only mess around with erlang occasionally, but it's like $25 so whatever.
|
|
#
?
Nov 9, 2013 00:54
|
|
|
Yeah factory lites are cool to check out a bunch of projects, get a few basics here and there, meet other devs, and do so not too expensively if you don't live far (compared to complete Erlang Factories). If it's like the ones I've been to be fore, lunch should also be covered and there might be drinks after, but that depends on who organizes it.
|
|
#
?
Nov 9, 2013 01:00
|
|
|
Is there a reason so many functions are 1-based instead of 0-based (lists:nth/2, element/2 etc)?
|
|
#
?
Nov 12, 2013 22:37
|
|
|
more like dICK posted:Is there a reason so many functions are 1-based instead of 0-based (lists:nth/2, element/2 etc)? It's pretty much a difference between calculating an offset and a position. An offset would be 'how far from the start are you', offset 0 being the first position. This is used for binaries ({0,1} = binary:match(<<"abc">>, <<"a">>)), the array module (which does it for familiarity), and a few others (the re module uses offsets on some matches if you ask for them). lists:nth/2 and element/2 are about position (first, second, third), and so are 1-indexed. Anyway, that's the easiest way to think about it. Otherwise, I'm not exactly sure what the design decision was behind it back in the 80s, never thought to ask around. I can try next time I see Robert or Joe online and report back.
|
|
#
?
Nov 13, 2013 00:19
|
|
|
That makes sense. It just takes some getting used to coming from languages where I'd be calling some_list[0] to get the first element. Another silly question. Is there any reason to ever have a process that doesn't live in an OTP supervision tree? It seems like every process I write is either an OTP behaviour, or a worker at the leaf of a supervision tree; I don't end up using many of the concurrency primitives, since so much seems to go through OTP. Is this OK, or are there legitimate uses for raw Erlang?
|
|
#
?
Nov 14, 2013 21:13
|
|
|
more like dICK posted:That makes sense. It just takes some getting used to coming from languages where I'd be calling some_list[0] to get the first element. This is perfectly OK. This is a testament to how general OTP is as a framework and covers higher levels of concurrency. Erlang's base mechanisms are primitive (and they're good primitives). You will use them when you profile your code and find some specific hotspot where OTP might be too slow, or you'll find yourself needing a pattern not covered by OTP. Whenever you end up feeling you need raw Erlang, go take a look at the start functions from proc_lib, as they'll give you some of the base mechanisms to have them talk to supervisors in order for you to inject your own code inside a supervision tree. If you really want to fully have your code become compliant with OTP trees (you just wanted to have a lot of raw Erlang around it), there are functions in the sys module for that. In the last case, you may feel that raw Erlang is just better to express yourself in for a problem. In these cases, you'll want to add that bit of code to your supervision tree using supervisor_bridge, which lets you create a middle-man for your raw Erlang process. It's usually easier to use that one than reimplementing OTP with proc_lib and sys. There are other cases where you just want out of the supervision structure, but you'll probably be able to recognize them when it happens.
|
|
#
?
Nov 14, 2013 21:31
|
|
|
I use plain processes pretty often. Usually with spawn_monitor from a gen_server. Generally they are single task activities that would otherwise block the gen_server.
|
|
#
?
Nov 15, 2013 18:34
|
|
|
So the Toronto Erlang Factory Lite was pretty neat! There were four(!) goons there, including MononcQc who gave a talk. Tom from Basho's talk stood out as well. Unfortunately I couldn't hang around for drinks afterwards, but I got to meet a lot of interesting people. I hope there was enough interest that there'll be another one next year.
|
|
#
?
Nov 24, 2013 02:05
|
|
|
The main impression I got from the Erlang Factory was that there is a big world of distributed Erlang that's not easily accessible for the hobbyist.  Also I'm stealing lpgauth's L macro for proplists.
|
|
#
?
Nov 25, 2013 14:39
|
|
|
Erlang factories vary a lot. These places act like a junction point where academia and industry meets, so for Basho talks you'll get a mix of distributed systems theory (and let's be frank, Tom and Chris' talk had a lot of it, and it was rough to keep up even if I had read all the papers they mentioned beforehand) and practical implementation. There's a bunch of papers for distributed systems where I contacted the authors and a back and forth with Basho is what prompted new research (Dotted Version Vectors are part of that). Other conferences have a different makeup. The one in New York had a great talk by Mahesh Paolini-Subramanya (he's an awesome guy, if you meet him, go say hi) about how his former telecom company rewrote their call-center Java FSMs into simpler ones in Erlang using concurrency to better express the problem domain. He has plenty of great war stories. A year or so ago, the Erlang Factory in San Francisco had a keynote about type-checking Erlang, then two talks by unrelated teams about how to use the related type annotations to generate Quickcheck (or equivalent) tests. The year before in London had a track regarding how refactoring could be automated with Wrangler. This year they had at least 2-3 talks on real-time bidding and software developed with soft real time constraints (I had one of them), one from guys from Boundary about how to deal with high-throughput stuff and avoid anything that blocks in the VM. I haven't been to two of them that were very similar, although if you go to say, the London Erlang Factory and the San Francisco Erlang Factory in the same year, then there will be some overlap from bigger players that can ship their employees at conferences worldwide.
|
|
#
?
Nov 25, 2013 15:18
|
|
|
Oh and Erlang Solutions Ltd. decided to bring back the Erlang Handbook, which is a kind of informal spec about the language itself.
|
|
#
?
Nov 25, 2013 15:19
|
|
|
Posting Principle posted:The main impression I got from the Erlang Factory was that there is a big world of distributed Erlang that's not easily accessible for the hobbyist. I wasn't there, but I quite agree about the difficulty of keeping up with a lot of the cutting edge academic stuff that goes around. There's a feeling that if you can't keep up with academics that maybe you should sit back and let the people that have been doing it for a few years already solve the hard problems, but that's a little too "priesthood" for me. I'd like to find more time to make the subject more approachable, but there's the day job and other side work to keep me busy 
|
|
#
?
Nov 30, 2013 16:34
|
|
|
Are there good introductory resources? I have a copy of this book from school still (an older edition). Would that be enough to get back into distributed systems?
|
|
#
?
Dec 1, 2013 20:50
|
|
|
1. Get to know your CAP theorem. I'd start with http://www.julianbrowne.com/article/viewer/brewers-cap-theorem and then You Can't Sacrifice Partition Tolerance. I also made my own thing on it at http://learnyousomeerlang.com/distribunomicon#my-other-cap-is-a-theorem 2. Read and try to understand Amazon's Dynamo Paper(PDF). It's a very good read and behind a shitload of systems' architecture now. 3. Read on "The fallacies of distributed computing" (I've made a write up on them vs. Erlang). 4. Then, I’d direct people to try and understand vector clocks/Lamport clocks. I suggest reading Basho's Why Vector Clocks are Easy followed by their post titled Why Vector Clocks are Hard. I then explain them very simply in my project.log. Get to read the papers if you want, there's a shitload of them. 5. Check out PACELC. It's a very simple extension to CAP that basically says that PAC is “during a (P)artition, do you pick (A)vailability or (C)onsistency”, and “(E)lse, do you pick (L)atency or (C)onsistency”. For this one, http://www.slideshare.net/abadid/cap-pacelc-and-determinism and http://dbmsmusings.blogspot.ca/2010/04/problems-with-cap-and-yahoos-little.html are nice. 6. Take a look at Two-Phase Commits and Three-Phase Commit protocol. You could also look into other schemes for replication such as chain replication and whatnot. 7. Consensus algorithms. Three main ones here, in order of how easy they are to understand: Raft, ZAB, and Paxos (notoriously hard to understand). They guarantee consistency but with failed nodes. Oh and all around that, go read Aphyr's blog, particularly "The trouble with timestamps" and the "Call me maybe" series. MononcQc fucked around with this message at 21:11 on Dec 1, 2013 |
|
#
?
Dec 1, 2013 21:09
|
|
|
Oh yeah more texts! - End-to-end arguments in system design - Idempotence is not a medical condition
|
|
#
?
Dec 1, 2013 21:15
|
|
|
Posting Principle posted:Also I'm stealing lpgauth's L macro for proplists.
|
|
#
?
Dec 2, 2013 18:57
|
|
|
Rapsey posted:What is it? Val = ?L(Key, List), Val = ?L(Key, List, Default). IIRC I implemented something like that when I worked there -- I don't know if it's still the same meaning (mine was just called ?lookup or something), and the two arguments one would raise an exception when the value isn't found and no default is provided, so that you never need to visually do the {ok, Val} = Expression thing. The other sweet thing about it is that the implementation eventually got switched to lists:keyfind to be faster, and other formats could be supported (like looking within JSON structs) without altering the calling code due to macro goodness.
|
|
#
?
Dec 2, 2013 19:44
|
|
|
Yeah it's not super groundbreaking, just a really nice shorthand, especially for mochijson2 which decodes JSON as a {struct, proplist()} tuple.
|
|
#
?
Dec 2, 2013 20:45
|
|
|
MononcQc posted:1. Get to know your CAP theorem. I'd start with http://www.julianbrowne.com/article/viewer/brewers-cap-theorem and then You Can't Sacrifice Partition Tolerance. I also made my own thing on it at http://learnyousomeerlang.com/distribunomicon#my-other-cap-is-a-theorem (Sorry this isn't directly about Erlang, but I saw it pop on Twitter as I was reading this thread: http://www.infoq.com/presentations/raft)
|
|
#
?
Dec 5, 2013 05:31
|
|
|
Anyone going to the real-deal Erlang factory in SF? I may be able to con work into paying.
|
|
#
?
Dec 17, 2013 20:17
|
|
|
I'll be in there speaking, just no idea what about yet 
|
|
#
?
Dec 17, 2013 21:17
|
|
|
If you're interested in learning more about the internals of the Erlang Runtime System, the OTP team started publishing more documentation and proposals for improvements in the github repository: https://github.com/erlang/otp/tree/master/erts/emulator/internal_doc it's a pretty interesting read. Although the documents are written in the future tense, that stuff is all currently implemented -- most of it by R16B01-R16B02 -- the OTP team just published documents intended for the RELEASE project (EU research on parallelism) once they were done with them. MononcQc fucked around with this message at 14:48 on Jan 9, 2014 |
|
#
?
Jan 9, 2014 14:31
|
|
|
I'm going to roll in and ask a super-rookie question. I'm trying to follow this: http://egarson.blogspot.com.au/2008/03/real-erlang-hello-world.html I eventually resorted to just copy-pasting his code, I'm running it from erlide in eclipse. It compiles and runs without errors, but when you get to the point of going Pid ! hello. It does nothing. Nothing returns, the print statement doesn't fire, no crashes either. I'm stumped, what have I messed up? edit: MononcQc, if you wrote "learn you some erlang", that's fantastic, that's where I found out about erlang! Sir_Substance fucked around with this message at 12:05 on Feb 8, 2014 |
|
#
?
Feb 8, 2014 12:03
|
|
|
Sir_Substance posted:I eventually resorted to just copy-pasting his code, I'm running it from erlide in eclipse. Are you using erlide to do the interactive parts of the post, too? I'd recommend using 'erl' on the command-line. I have had lots of problems in the past with Eclipse's console not dealing with programs that want to do readline or curses style IO.
|
|
#
?
Feb 8, 2014 13:27
|
|
|
Hrm, seems you're right, it works fine when I run it from the command prompt. Well that's mighty infuriating, there's little point working in an IDE but compiling and running separately. Is there a known fix, or alternatively another IDE for erlang that offers similar conveniences?
|
|
#
?
Feb 8, 2014 14:05
|
|
|
Sir_Substance posted:Is there a known fix, or alternatively another IDE for erlang that offers similar conveniences? Use Emacs. Seriously, though, I haven't tried any IDEs with Erlang. How much is erlide getting you? I wouldn't write Java without an IDE to type 90% of the boilerplate for me, but Erlang's concise and the only editor help that seems useful is indentation and making sure I don't misspell variables. Edit: Also, going to the Erlang prompt to do 'c(module).' is not the typical way to compile your code. You'd normally use the 'erlc' program, called from a Makefile or (better) by Rebar. I have no idea how well Eclipse handles those, but they don't involve the buggy console. Mniot fucked around with this message at 14:19 on Feb 8, 2014 |
|
#
?
Feb 8, 2014 14:16
|
|
|
Erlang conveniently integrates with the windows shell, at least in the version I'm using. You can right click the .erl files and there's a compile option. I don't know how much erlide is getting me, I'm literally 5 minutes into my first time using erlang. In general, I start with the assumption that IDE's are better. If nothing else, the eclipse run button and project management are super-handy, and there's always the chance of a proper breakpoints based debugger and memory interrogation, as well. On the other hand, if the IDE is flat out broken and there are no alternatives... Sir_Substance fucked around with this message at 14:28 on Feb 8, 2014 |
|
#
?
Feb 8, 2014 14:25
|
|
|
I've only been doing Erlang for a few months, but I have not been missing any IDE because my Erlang workflow is very different from my Java workflow. In Java, I type a little then press "run" then type a little more then press "run" and so on. I might run my code as much as 6 times in a minute with little edits in between. When I'm debugging, I set some careful breakpoints to get me near the problem and then I step along until I find it. In Erlang, I spend a lot of time thinking then type a little then think some more. I typically only run my code after at least an hour of editing. When debugging, I put trace statements at the tops of my functions (I bet there's an automatic way to do this) and run. Each function is small and when you see the function inputs it's immediately apparent what the bug is.
|
|
#
?
Feb 8, 2014 15:25
|
|
|
Very few full time Erlang programmers use an IDE. There is simply no real need for it. There was a discussion about this very topic on the mailing list not too long ago. https://groups.google.com/forum/#!topic/erlang-programming/t3jbMyKPLdw
|
|
#
?
Feb 9, 2014 07:40
|
|
|
My workflow is to generally use vim and erl, and reload code by hand in there, or often use Common Test and either ct_run or rebar ct to run and re-run tests. I often end up automating some stuff, but I keep things very manual as a whole. If you want to automate a few things, there are a few auto-reloaders available, the two most common being: I've used them sometimes before, but I often find myself wanting to control how I reload code.
|
|
#
?
Feb 10, 2014 00:22
|
|
|
MononcQc posted:7. Consensus algorithms. Three main ones here, in order of how easy they are to understand: Raft, ZAB, and Paxos (notoriously hard to understand). They guarantee consistency but with failed nodes.
|
|
#
?
Feb 10, 2014 01:58
|
|
|
why doesn't this work (in 17.0rc)code:code:the talent deficit fucked around with this message at 06:20 on Feb 11, 2014 |
|
#
?
Feb 11, 2014 05:51
|
|
|
Plenty of bugs and missing features because this is 17.0-rc1, i.e. pre-alpha of what would have been R17A. The Maps implementation will not even be totally complete for 17.0 final, and the insertion times are still lovely for large maps. There's a lot of work to be done there and right now people have been busy adding support to the entire dependency chain (debugger, pretty printers, etc.) before making sure all the matching tricks can work -- some of them require rewriting large parts of the mechanisms and will have impacts in other areas like function heads and binaries, and are thus tricky to get right without breaking anything. You can try more of these operations using the 'maps' module similar to 'dict' for now.
|
|
#
?
Feb 11, 2014 14:07
|
|
|
MononcQc posted:Plenty of bugs and missing features because this is 17.0-rc1, i.e. pre-alpha of what would have been R17A. The Maps implementation will not even be totally complete for 17.0 final, and the insertion times are still lovely for large maps. Will maps get faster at insertion/retrieval eventually?
|
|
#
?
Feb 11, 2014 23:09
|
|
|
That should be the plan. Ideally, the wishlist had them faster than any data structure implemented in Erlang on all operations (otherwise just translate the Erlang stuff in C and add syntax). I don't know what the optimization plans are here, but they're extremely unlikely to be left slow forever. My gut feeling is that the sharing scheme they have used to make reads faster on similarly-structured maps is taking long to re-size/do whatever it is it does when inserting, and that the OTP team is more worried about getting the semantics right before the performance, and will optimize later.
|
|
#
?
Feb 11, 2014 23:18
|
|
|
This language is hilarious. I reserve judgment on useful until I know what the gently caress I'm doing, but it's funny as all hell to work with.
|
|
#
?
Feb 13, 2014 11:42
|
|
|
Sir_Substance posted:This language is hilarious. You should read the mailing list today.
|
|
#
?
Feb 13, 2014 21:17
|
|
|
|
| # ? Apr 28, 2024 18:33 |
|
|
more like dICK posted:You should read the mailing list today. It's giving mutt a run for its money: 
|
|
#
?
Feb 13, 2014 21:26
|
|