|
Gazpacho posted:slashdot was the angry computer forum bill gates in a borg costume is an example of inchoate rage that would later become gamergate
|
#
?
Dec 18, 2017 17:45
|
|
|
|
| # ? Apr 27, 2024 01:03 |
|
|
Poopernickel posted:rust, tho its starting to show up in a few small places at amazon, but no major tidal wave
|
|
#
?
Dec 18, 2017 18:23
|
|
|
ultravoices posted:bill gates in a borg costume is an example of inchoate rage that would later become yospos
|
|
#
?
Dec 18, 2017 19:08
|
|
|
eschaton posted:also I think Slashdot specifically kicked off something (even if they weren’t the first), they tried to be an aggregator for a whole area of nerd culture, not just one or another aspect of it i remember the appeal of slashdot being that its tech news was user-submitted and chosen by editors. k5 was the pepsi alternative whose front page articles were voted on by users. i think k5 also had user diaries before slashdot did (dailykos was built on k5's CMS). reddit was also kind of fun before it had subreddits, when it was just a minimalist slashdot alternative
|
|
#
?
Dec 18, 2017 19:58
|
|
|
Poopernickel posted:rust, tho it's slowly popping up in a handful of places, but it isn't exploding in too many Production instances yet. which makes sense, it only stabilized 2 years ago.
|
|
#
?
Dec 18, 2017 20:00
|
|
|
why would you use rust when you could use Swift
|
|
#
?
Dec 18, 2017 20:09
|
|
|
eschaton posted:why would you use rust when you could use Swift the same rust source compiles on both mac and linux
|
|
#
?
Dec 18, 2017 20:56
|
|
|
Cocoa Crispies posted:the same rust source compiles on both mac and linux and windows
|
|
#
?
Dec 18, 2017 21:28
|
|
|
this is true for Swift as well
|
|
#
?
Dec 18, 2017 23:51
|
|
|
eschaton posted:this is true for Swift as well last time I did Swift I had to do different includes and I think different functions to do stdio
|
|
#
?
Dec 19, 2017 00:50
|
|
|
Cocoa Crispies posted:last time I did Swift I had to do different includes and I think different functions to do stdio there's some very basic swift-native console io, but to use anything from libc you have to explicitly name which libc you want i assume this was supposed to be a very temporary thing while the swift foundation port was completed but it's pretty awkward
|
|
#
?
Dec 19, 2017 01:28
|
|
|
every time I’ve looked at go I’ve come away baffled that anyone would ever want to use it, so I guess it fits right in with everything else esr likes he’s right about c++ tho I’ll give him that
|
|
#
?
Dec 19, 2017 01:48
|
|
|
go is fine for small utilities that you want to be built statically and the ease of cross-compilation is pretty great tbh (modulo problem 5 below) there's a few things that go does wrong that you'll bang your head against constantly and it's pretty clear that go's authors are too stubborn to fix them: 1. the GOPATH bullshit is a travesty (yes i know they're just cargo culting google3/) sure, you can directly import an arbitrary repo url and thats fun the first time you try it, but with any non-trivial usage you run into... - bad decision 1: by default the only option is to pull HEAD of master. if you want to pin to a specific tag/commit then you gotta use "vendoring", aka grabbing a copy of all your dependencies, and checking that into your own source tree. there is no way to just specify a tag/commit in the import statement and let the build system deal with it. adding insult to injury is that this then cascades into... - bad decision 2: due to deficiencies in the go toolchain that the authors wont acknowledge are a problem, any use of vendoring invokes a requirement to place your code into a global GOPATH tree, and be within that tree when building your code, even if all your deps are fully contained in the repo's local vendor dir (as they pretty much have to be). go tooling will ignore your vendor dir unless you're building from what it thinks is your GOPATH. this is extremely obnoxious if you have e.g. a repo with go stuff alongside other non-go stuff, in which case it makes zero sense to force your developers to structure their workflow around fitting GOPATH and the tooling's snowflake needs. also AMA about hitting bizarre ongoing bugs around the go tool linking two copies of a library in the same binary, one via GOPATH and the other via the local vendor dir. 2. the verbosity of error handling is pretty hilarious given that in theory the language is meant to be used for relatively low-level io/networking, leading to frequent chains of 10 "if err != nil" checks all over the place whenever you're actually using it for that kind of thing. rust's Result type would at least make this a bit less obnoxious to deal with... 3. ...but something like rust's Result type isn't possible in go because go continues to ignore parameterized types, insisting that passing around void* any time you want any sort of polymorphism is reasonable. for example the stdlib json library returns a tree of void*s whenever you want to parse some json. hope you like reams of nested type assertions! 4. this is a relatively minor thing as it can be avoided by using a third-party library, although that triggers the need to start dealing with GOPATH: go's default approach to specifying assert statements in tests is just hilarious. instead of just providing a default set of utility functions for the common cases, they want you to manually DIY each assert as an if-statement which returns an error when the if-statement doesn't pass. this is pretty much go in a nutshell 5. this is just a specific bug but its another bizarre issue which hasn't been fixed in forever that taints otherwise great support for cross-compilation in go: the standard os/user library panics if you try to use it in a cross-compiled build. why would anyone want a common function for finding the user's home directory in a cross-compiled build? for all i know there could be other standard libraries that similarly fail but this one's particularly hilarious the sad thing is that these kinds of problems aren't even issues with the language proper and are totally fixable without even necessarily affecting compatibility, aside from the err return types thing, which is pretty well entrenched now. the problem is just that go's authors are too stubborn to acknowledge that they're problems. given that, i think the ideal outcome is if go went the short-lived fad route ala ruby, and then something else came along that just stole the good parts while cutting the bullshit, and being willing to admit when something doesn't work. from having messed around with rust a bit recently im hopeful that it could be this something else but that said, if you just want 'C except with garbage collection, a standard library, and a toolchain thats easy to install' then you could do worse
|
|
#
?
Dec 19, 2017 05:29
|
|
|
Plorkyeran posted:there's some very basic swift-native console io, but to use anything from libc you have to explicitly name which libc you want there’s that and also someone needs to migrate the common pieces into a POSIX module in general though you’ll want to prefer Foundation and the Swift standard library, regardless of what platform you’re targeting
|
|
#
?
Dec 19, 2017 06:32
|
|
|
Toady posted:i remember the appeal of slashdot being that its tech news was user-submitted and chosen by editors. k5 was the pepsi alternative whose front page articles were voted on by users. i think k5 also had user diaries before slashdot did (dailykos was built on k5's CMS). Reddit had /r/programming and /r/netsec, and a couple others I can't remember, since long before users could create subreddits.
|
|
#
?
Dec 21, 2017 08:16
|
|
|
it started with no subreddits until the nsfw "sub-section" was added in 2006. guess i can't avoid admitting i have an account from that era
|
|
#
?
Dec 21, 2017 19:13
|
|
|
finally i can lay down my crown as "most shamefully reddit yosposter" having created my account in 2007
|
|
#
?
Dec 21, 2017 23:19
|
|
|
|
| # ? Apr 27, 2024 01:03 |
|
|
king of poo poo mountain
|
|
#
?
Dec 21, 2017 23:42
|
|