Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
gary17the
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
12 ms
·
91.
▲
by
gary17the
4y ago
> Your intent was offense (...) you still play games (...) a typical strategy to win the crowd (...) But there is no crowd here (...) your real intent is just to piss me off (...) Your just a vile human being (...) it just shows off your
92.
▲
by
gary17the
4y ago
> First off types can't emmit values. Types don't exist at run time. Incorrect. Please have a look at OpenCombine sources, or, say, at the Typestate Pattern in Rust: http://cliffle.com/blog/rust-typestate&#
93.
▲
by
gary17the
4y ago
> It's next to impossible to type check UI Incorrect. Have a look at the Swift OpenCombine library. Multiple Publishers of a particular type that emits a single boolean value (e.g., an "Agree to Terms" UI checkmark and an
94.
▲
by
gary17the
4y ago
Thanks, glad you found the post useful. I'm sure C# and Java make excellent programming languages for many if not most financial applications, but I meant that in the context of high-volume Enterprise Application Integration (EAI). Bas
95.
▲
by
gary17the
4y ago
No contradiction, really, it's just that we are talking about two different programming goals: I emphasize the goal of producing well-behaved software (especially when it comes to large software systems), while you emphasize the goal o
96.
▲
by
gary17the
4y ago
> So basically compile time type checking just makes some of the errors get caught earlier which is a slight benefit but not a KEY differentiator. Unfortunately, I have to completely disagree here, at least based on my experience. Shifti
97.
▲
by
gary17the
4y ago
> The gains [introduced by a strong type system] grow superlineraly with the amount of code. That's a good way to put it.
98.
▲
by
gary17the
4y ago
This is, IMvHO, such old news that it feels... weird to still read about it in a year with the prefix of 20. Every programmer who has ever single-handedly written a 100,000+ LOC software system will tell you the same thing: shift as much re
99.
▲
by
gary17the
4y ago
Do not forget that being a programmer, you already have the ability to create electronic products people will pay for. Consider learning Swift/Kotlin and making a paid, subscription-based mobile app. Consider learning Go/Rust/
100.
▲
by
gary17the
4y ago
Read the official, free Rust Book[1]. Rust is easy to learn by reading (in order to understand programming concepts unique to the language, such as the borrow checker and lifetimes), but Rust is hard to learn by experimentation alone (tryin
101.
▲
by
gary17the
4y ago
> For someone new to systems programming, should I just start with Rust? Or should I learn C/C++ first and then learn Rust? IMHO, if your end-goal is Rust, learn Rust directly. The angle I am coming from: I've been doing C++ fo
102.
▲
by
gary17the
4y ago
You can approximate this already: forget Rust references (borrow checking + lifetimes; in other words, raw pointers) and start hacking with Rust using its shared ownership (reference-counted) smart pointers, immutable Rc<T>[1], mutabl
103.
▲
by
gary17the
4y ago
Being "explicit with code for memory safety [even for] simple operations" is the whole point of Rust. Otherwise, sooner or later, as a codebase grows, you make mistakes that your compiler cannot catch (e.g., you give an immutable
104.
▲
by
gary17the
4y ago
Yes, good point, a switch from a GC-based language to a memory ownership -based language is definitely non-trivial, but you can always just forget Rust references altogether for the time-being and start hacking with Rust with its reference-
105.
▲
by
gary17the
4y ago
The borrow checker and lifetime annotations. It's always the borrow checker and lifetime annotations - otherwise Rust is, IMHO, as readable as (the excellent) Golang.
106.
▲
by
gary17the
4y ago
Well, you will probably think I'm crazy, but for me personally, having a couple of decades of C++ experience, learning Rust turned out to be much easier than learning... Swift. Yes, that famed, ultra-modern, great-as-your-first-program
107.
▲
by
gary17the
4y ago
> I’ve been holding off learning Rust. Rust is quite an easy language to learn and a pleasurable language to use, due to its modern ergonomics and internal consistency. Give it a try. The only trick is that Rust newcomers actually need t
108.
▲
by
gary17the
4y ago
Perhaps bad phrasing on my part. I meant that in the are-they-still-even-maintaining-modern-optimizing-compilers-for-Pascal-and-Forth sense.
109.
▲
by
gary17the
4y ago
Wow. Swift, touted as "safe by design and (...) runs lightning-fast"[1] is more of a screw-up than I thought. Almost twice as slow as Lua and behind even Pascal and Forth. [1] https://developer.apple.com/swift/
110.
▲
by
gary17the
4y ago
I definitely see your point about the interconnection of references, mutability and lifetime in Rust, but I guess the issue of whether Rust has a problem with the classic O-O comes down to the question of what you are trying to implement. I
111.
▲
by
gary17the
4y ago
> they won’t reference each other directly with references/pointers I'm not sure if I understood your reply correctly, but there seems to be nothing in Rust stopping one dynamic trait (interface-based) object directly referenci
112.
▲
by
gary17the
4y ago
I agree that crypto indeed started out as a dumb, speculative, monetary technology, but it is currently moving toward smart-contract, non-speculative applications, such as guaranteed voting or transfer-of-ownership systems. Crypto indeed st
113.
▲
by
gary17the
4y ago
> there's no job in [Rust] As of today, indeed.com lists 1,500 remote jobs mentioning Rust vs. 4,018 jobs mentioning Golang. That's not so bad. (However, there's no way to tell how many of those listings are Rust-specific
114.
▲
by
gary17the
4y ago
I don't know OCaml, so I cannot compare the two, but, generally speaking, Rust does not require functional programming, or using only immutable data structures, or using cloning, or using copy-on-write semantics (which have to properly
115.
▲
by
gary17the
4y ago
Actually, I think Rust is a godsend to startups for the following reasons: 1.) startups rarely have time, expertise or budget for extensive unit tests, mock-up tests, UI-automation tests or paid third-party Q/A services, 2.) software p
116.
▲
by
gary17the
4y ago
I'm not sure what you mean - I mentioned Objective-C++ mobile development only as an example of how challenging multi-threaded/async programming can be. The problem is analogous on other platforms and can be simplified by Rust on
117.
▲
by
gary17the
4y ago
I see your point, but it all depends on whether the choice of a particular organizational infrastructure architecture is a priority for you or not. If infrastructure is a priority, (e.g., "we don't really want to hire anyone just
118.
▲
by
gary17the
4y ago
While the article is an absolutely excellent analysis of Rust from the low, PL-level ergonomics point of view, it seems to largely miss (or, intentionally, skip) the bird's eye point of view of complexity inherent to software developme
119.
▲
by
gary17the
4y ago
> It would be funny if the crypto bubble burst and took the rust bubble with it. It's probably not likely at all. While Rust's correctness guarantees through ownership checking can be approximated by other programming languages
120.
▲
by
gary17the
4y ago
> And even then [Swift] left me wondering why they could not tolerate a slightly more ugly syntax, in favor of readability. Well said. I've also been coding for a couple of decades (mostly in C++) and I also found advanced, real-wor
More ›