>>1 Having a project with CoC written by SJW is a sign its run by spineless cucks and will be shut down easily. Its like a huge banner "We will sacrifice technical integrity for SJW compliance"
Name:
Anonymous2018-10-25 5:48
>>5 python is dying, people are switching to go instead
Name:
Anonymous2018-10-25 6:09
>>10 but go is a completely different language. statically typed, compiled, pedantic about formatting and imports, lol no generics, check my dubs
Name:
Anonymous2018-10-25 6:52
>>11 go is watered down python with multi-threading and static typing
Name:
Anonymous2018-10-25 6:53
>>12 it's also not as flexible, not as readable and far more boilerplatey
Name:
Anonymous2018-10-25 7:03
>>1 Why does a code of conduct preclude you from using a language? It has zero impact on development.
Name:
Anonymous2018-10-25 7:11
>>13 yes. intelligent prog rammers should use c# or d instead
>>15 I'd like c# (it's basically java done right) and f# (it's basically less french ocaml) if they weren't so tied to windows. is there even a decent IDE for them on *nixes?
>>21 d seems to have nice metaprogramming features (especially when compared to sepples templates, rust macros and #include <void.h>) but the ecosystem is confusing
Name:
Anonymous2018-10-25 7:43
>>23 aren't they always confusing? if you don't know some things about windows the c# ecosystem sometimes will seem strange as well.
Name:
Anonymous2018-10-25 7:50
>>24 c# ecosystem on windows is quite easy due to good tooling. d is a mess of incompatible compilers and language version, and it gets exponentially worse when you want to use it without garbage collector as even parts of the stdlib use it but it's not obvious which ones
Name:
Anonymous2018-10-25 7:56
>>25 didn't they solve that? i though that was only in the 2000s
>Garbage Collection >TypeInfo and ModuleInfo >Classes >Built-in threading (e.g. core.thread) >Dynamic arrays (though slices of static arrays work) and associative arrays >Exceptions >final switch >synchronized and core.sync >Static module constructors or destructors How is that confusing you brainlet?
Name:
Anonymous2018-10-25 8:14
>>30 These are D-level features. C++ classes, C asserts, RAII and most of C++ stuff works. Exceptions are not needed for most of it.
Name:
Anonymous2018-10-25 8:20
Retained Features
Nearly the full language remains available. Highlights include:
Unrestricted use of compile-time features Full metaprogramming facilities Nested functions, nested structs, delegates and lambdas Member functions, constructors, destructors, operating overloading, etc. The full module system Array slicing, and array bounds checking RAII (yes, it can work without exceptions) scope(exit) Memory safety protections Interfacing with C++ COM classes and C++ classes assert failures are directed to the C runtime library switch with strings unittest
Name:
Anonymous2018-10-25 8:28
>>31 It was more about how it is easily understandable which features can be used with or without gc, as they're all listed in >>29.
Name:
Anonymous2018-10-25 8:31
>>33 These (useless,except associative arrays) features are disabled. You would get a compile error.
Name:
Anonymous2018-10-25 8:39
>>34 They're not because we're using the gc because we're using d as a replacement for go Edited on 25/10/2018 08:40.
>>35
>>34
They're not because we're using the gc because we're using d as a replacement for go
using go cannot comprehend why gc is bad calling people brainlets
Name:
Anonymous2018-10-25 8:44
>>30 it's confusing because it requires knowing which parts of the stdlib use those features, which is not something a user should be required to know. which other languages require you to know stdlib implementation details?
>>38 Enlightened Go Experts who somehow became dissatisfied with their perfect language.
Name:
Anonymous2018-10-25 8:50
>>37 Each month the runtime and stdlib made more and more free of GC usage, not for betterC but because its plain faster and doesn't waste memory. Edited on 25/10/2018 08:51.
>>37
Each month the runtime is made more and more free of GC usage, not for betterC but because its plain faster and doesn't waste memory.
Each month the runtime and stdlib made more and more free of GC usage, not for betterC but because its plain faster and doesn't waste memory.
>>36 i don't use go and i've recommended better alternatives here >>15 i understand that for some use cases a gc is bad, but for glue scripts, ordinary apps and servers a gc is better as it allows for cleaner code
>>37 a programmer should understand the things he uses the unwashed masses should and will use languages like go, but my recommendations were for intelligent programmers
>>41 Development of D is like x100 slower than Rust, despite D being a far better at replacing C/C++(and literally providing same C++ interface e.g. -betterC). Plus new features with GC usage are added all the time. And many compiler bugs are still not fixed(except LDC which is fairly stable).
Name:
Anonymous2018-10-25 9:29
D has however one huge advantage over Rust. Rust-cucks have coded themselves into a corner because their only compiler is written in Rust(because they felt insecure in that it wasn't self-hosting). Rust is now far complex than they realize and now they're dealing with such layers of autism that improving even the tiniest part of Rust has numerous roadblocks and inter-dependencies that all have to be resolved in specific pedantic order or it won't compile. I guess its karma for borrow checker coming back to these masochist cucks.
Name:
Anonymous2018-10-25 10:02
D is shit. It has C-tier types like byte/short/int/etc instead of a generic n-bit integer while it also lacks dependent types.
You can has nbit integers with bitfields in C, but they require to access a member value. typedef struct{unsigned int v:10;} tenbittype; #include <stdio.h> int main(){tenbittype w11={0xffffffff}; printf("%u::%lu",(unsigned int)w11.v,sizeof(w11));}
>>51 Shit I'm illiterate. Yes the compiler is gigantic mess. Also the old borrow checker is getting replaced with something that isn't as bad.
Name:
Anonymous2018-10-25 12:11
>>51 Nice hobby project, but Rustc development is not going to use it. Also, since Rust is effectively a LLVM subproject they're dependent anyway on C++. so 1. They coded themselves into a corner 2.That corner is built on top of C++. 3.LLVM bugs and feature limits dictate the future direction. Don't have X supported in LLVM? no X in rustc.
>>53 LLVM is just the backend, it was the best option at the time. Writing a compiler for a complex language and a backend that produces highly performant asm is just too much work. Zig does the same. There is a future alternative backend here: https://github.com/CraneStation/cranelift