|
we should all have gone ucs-2 and told a few people and their idiotic writing systems to go gently caress themselves
|
#
?
Oct 14, 2014 14:14
|
|
|
|
| # ? May 23, 2024 16:25 |
|
|
.NET doesn't have checked exceptions because, and this is either actually documented or straight from Herb Sutter's mouth, they preferred to emphasize unwinding as opposed to catching, hence IDisposable and C#'s using. myself I wonder how true it actually is, because e.g. Stream clearly didn't start as IDisposable, and IDisposable is a massive pain to implement requiring a lot of obscure boilerplate. RAII and GC don't mix well, and an interface may not be the best way to add RAII to .NET (you're supposed to propagate IDisposable to container objects, i.e. an object that contains IDisposables should be IDisposable itself) but vOv. At least FxCop will scream at you for getting the boilerplate wrong .NET doesn't have an equivalent of RuntimeException or even Error and that's extremely infortunate, because tools like FxCop then have to keep a hardcoded list of exceptions that you shouldn't catch
|
|
#
?
Oct 14, 2014 14:21
|
|
|
idisposable only helps w/ cleanup after an exception (assuming you implemented it right). it doesn't help you deal with the exception. but personally I think it works fine for what its intended for and is far better than relying on a destructor to do your cleanup.
|
|
#
?
Oct 14, 2014 14:28
|
|
|
Shaggar posted:also I love that the way you do exception handling in c# is: Here's a fun one:  those are how many crashes and exceptions were met in some of our product. The bars on the left are roughly 666 times (  ) higher than on the right. And I'm talking going from hundreds of thousands of exceptions a day to hundreds. All of these were uncaught (they'd still get automatically logged, they were just unhandled), none of them ever took down production. The reason for this? On some proxying logic somewhere, we had set a couple of assertions about the internal state a request could have. That state basically stored whether data was already sent on the wire, to make sure you never get in a scenario where you halfway push someone an HTTP response (say HTTP/1.1 200 OK \\ some-header: some-val \\ ...) and suddenly, due to an error (say the backend sends invalid gibberish), you don't start piping in a 502 Bad Gateway through the established request. In 99% of the cases, this was handled right, but it turned out we had a corner case where it wasn't. This was more or less an example case of "one in a million events, over billion of events". The exception made it so the connection was properly closed (it killed the process in charge, deallocated the sockets, etc. which would happen on most errors anyway), and was cleanly logged it. Whenever we had enough human bandwidth to take care of this minor bug, we did, and it went away (hence the mid-september drops). And you can see we still get a stable amount of exceptions every day. We know what they are, we know what triggers them, we know their importance, and we know the system lives fine without them (they mostly happen when people send random garbage on the line or get disconnected halfway through an HTTP request line, for example, nothing we can prevent except by not logging it). So our process is more or less: 1) wait for something to be logged 2) add handling for that specific exception 3) wait for the next thing to be logged 4) repeat The big point item I see there, though, is that in my environment, I'm fine and extremely comfortable leaving assertions there in running code. They let me ensure pre- and post-conditions for work are met, and if they are violated, something has gone terribly wrong and I should stop it ASAP. You don't keep going when you're on bad state, the same way that when you drink milk that has gone bad, your first reaction is to stop, not to keep chugging and go "but milk is supposed to be good for me!" I'm also entirely comfortable letting exceptions happen, log it, rollback to a stable state, and move on to the next tasks. We're able to grow our systems over months, even though they aren't perfect out of the box (they'll never be). In fact, eating up exceptions in a defensive manner is seen as a terrible practice in our team because they are a great way to mess up your state in subtle ways and make things worse. If we were smart enough in the first place, there would be no need for the exception to be raised. When we know how and why it gets raised (and how often!), then we can start handling it. We also have the huge benefit that we run the software we write, we don't ship it to remote places where we can't update it, and we don't do life-critical stuff either.
|
|
#
?
Oct 14, 2014 14:31
|
|
|
rust seems cool
|
|
#
?
Oct 14, 2014 15:25
|
|
|
vapid cutlery posted:rust seems cool ya, one of these days i'll give it a proper go. the syntax is just so bad coming from haskell though, it's so cluttered
|
|
#
?
Oct 14, 2014 15:26
|
|
|
seems more useful than haskell
|
|
#
?
Oct 14, 2014 15:28
|
|
|
i thought rust was basically "go except better" but come to think of it i kinda want to give go another look, just because it handles concurrency the correct way
|
|
#
?
Oct 14, 2014 17:00
|
|
|
i keep seeing people talk about go and rust and i just cant find myself giving a gently caress about them
|
|
#
?
Oct 14, 2014 17:03
|
|
|
^- (unit hole) =+ ^= cok ^- (list ,@t) =+ cok=(~(get by mah) 'cookie') ?~(cok ~ u.cok) |- ^- (unit hole) ?~ cok ~
|
|
#
?
Oct 14, 2014 17:25
|
|
|
AlsoD posted:ya, one of these days i'll give it a proper go. the syntax is just so bad coming from haskell though, it's so cluttered ya but haskell is so different it scares ppl syntactic redundancy is not bad, helps until it gets oppressive
|
|
#
?
Oct 14, 2014 17:29
|
|
|
fritz posted:i keep seeing people talk about go and rust and i just cant find myself giving a gently caress about them Go's syntax feels like a huge step backwards.
|
|
#
?
Oct 14, 2014 17:34
|
|
|
AlsoD posted:ya, one of these days i'll give it a proper go. the syntax is just so bad coming from haskell though, it's so cluttered If you're going to compare syntax you should compare the syntax for using arrays.
|
|
#
?
Oct 14, 2014 17:44
|
|
|
hackbunny posted:.NET doesn't have checked exceptions because, and this is either actually documented or straight from Herb Sutter's mouth, they preferred to emphasize unwinding as opposed to catching, hence IDisposable and C#'s using. myself I wonder how true it actually is, because e.g. Stream clearly didn't start as IDisposable, and IDisposable is a massive pain to implement requiring a lot of obscure boilerplate. RAII and GC don't mix well, and an interface may not be the best way to add RAII to .NET (you're supposed to propagate IDisposable to container objects, i.e. an object that contains IDisposables should be IDisposable itself) but vOv. At least FxCop will scream at you for getting the boilerplate wrong the number of people who need to use IDisposable >> the number of people who need to implement IDisposable, though (by "implement it" i mean the boilerplate version, not just propagating inner IDisposables)
|
|
#
?
Oct 14, 2014 17:46
|
|
|
Zombywuf posted:If you're going to compare syntax you should compare the syntax for using arrays. is use of lens a pro or a con?
|
|
#
?
Oct 14, 2014 17:52
|
|
|
triple sulk posted:Go's syntax feels like a huge step backwards. go has an incredibly terrible name
|
|
#
?
Oct 14, 2014 17:53
|
|
|
Malcolm XML posted:ya but haskell is so different it scares ppl >>= >> >> >> >> !%=
|
|
#
?
Oct 14, 2014 18:07
|
|
|
AlsoD posted:is use of lens a pro or a con? the fact that you'd even ask that speaks volumes
|
|
#
?
Oct 14, 2014 18:23
|
|
|
one thing I like w/ IDisposable/using is you can use it for transactions too
|
|
#
?
Oct 14, 2014 18:30
|
|
|
Zombywuf posted:the fact that you'd even ask that speaks volumes lol
|
|
#
?
Oct 14, 2014 19:33
|
|
|
listen if you're too dumb to come up with an algorithm that doesnt require random access then you deserve to eat the log n lookup
|
|
#
?
Oct 14, 2014 19:37
|
|
|
Mr Dog posted:i thought rust was basically "go except better" but come to think of it i kinda want to give go another look, just because it handles concurrency the correct way i thought go's channels were surprisingly bad for being one of the languages distinguishing features i actually think concurrent programming will be easier in Rust. channels being unidirectional is a nice improvement already
|
|
#
?
Oct 14, 2014 20:00
|
|
|
Gazpacho posted:^- (unit hole) what did you just say about my mah 
|
|
#
?
Oct 14, 2014 20:04
|
|
|
prefect posted:go has an incredibly terrible name rust isn't much better
|
|
#
?
Oct 14, 2014 20:10
|
|
|
FamDav posted:listen if you're too dumb to come up with an algorithm that doesnt require random access then you deserve to eat the log n lookup linked lists need random access
|
|
#
?
Oct 14, 2014 20:14
|
|
|
yeah rust's name is pretty crap let's choose a name for our technology and engineering thing that has negative connotations in technology and engineering
|
|
#
?
Oct 14, 2014 20:16
|
|
|
programming languages ought to be named after shock images. that'll show those kids looking for documentation
|
|
#
?
Oct 14, 2014 20:20
|
|
|
do you think goatse would be garbage collected or pointers + RAII
|
|
#
?
Oct 14, 2014 20:21
|
|
|
tubgirl would be a recursive language with garbage collection
|
|
#
?
Oct 14, 2014 20:24
|
|
|
MononcQc posted:tubgirl would be a recursive language with garbage collection 
|
|
#
?
Oct 14, 2014 20:25
|
|
|
MononcQc posted:tubgirl would be a recursive language with garbage collection
|
|
#
?
Oct 14, 2014 20:28
|
|
|
Gazpacho posted:^- (unit hole) i'm still trying to work out if this is haskell with lens or not. the ,@t and single quoted string means that i suspect the latter
|
|
#
?
Oct 14, 2014 20:47
|
|
|
AlsoD posted:i'm still trying to work out if this is haskell with lens or not. the ,@t and single quoted string means that i suspect the latter
|
|
#
?
Oct 14, 2014 20:57
|
|
|
suffix posted:i thought go's channels were surprisingly bad for being one of the languages distinguishing features at this point rust's concurrency lib is somewhere between an afterthought and a leftover from a couple releases ago it might still work out better than go
|
|
#
?
Oct 14, 2014 21:05
|
|
|
fun fact: google doesn't use any of the go builtin dependency resolution internally. they also believe always building from HEAD puts the onus on the library writers to have a stable API  not sure how i feel about cargo. on the one hand it does as much as i would expect from an open source build tool, on the other hand i want so much more  .
|
|
#
?
Oct 14, 2014 21:17
|
|
|
MononcQc posted:tubgirl would be a recursive language with garbage collection Nice!
|
|
#
?
Oct 14, 2014 21:34
|
|
|
Shaggar posted:one thing I like w/ IDisposable/using is you can use it for transactions too i enjoy the hell out of abusing idisposable to do stupid things with using blocks you've given me an RAII substitute and syntactic sugar for it, i'm going to come up with the dumbest things possible to do in my dispose methods
|
|
#
?
Oct 14, 2014 21:35
|
|
|
maybe i want to log something on function exit, let's just alloc a logger object with the method name so that when i leave this using block it spews out the exit text looks better than a finally block!!
|
|
#
?
Oct 14, 2014 21:39
|
|
|
the only downside is now all your methods have implicit finally blocks, you're always in one, and you can't unload appdomains if they're running code with a finally well, that's certainly not the only downside
|
|
#
?
Oct 14, 2014 21:40
|
|
|
|
| # ? May 23, 2024 16:25 |
|
|
i'm at cargo because they have a principled stance about not letting you pass compiler flags directly to rustc
|
|
#
?
Oct 14, 2014 21:42
|
|